pgvector 0.8.7 corrige une faille dans les index IVFFlat : mise à jour conseillée

pgvector est l'extension qui permet à PostgreSQL de stocker des vecteurs et de chercher par similarité. C'est la brique la plus courante pour ajouter une recherche sémantique ou un assistant documentaire à une application qui tourne déjà sur PostgreSQL. Sa version 0.8.7, datée du 1er octobre 2026, corrige une faille de sécurité qui mérite qu'on s'y arrête.

Ce que dit l'avis

Le mainteneur du projet a publié le même jour une note courte dans le dépôt GitHub :

• un utilisateur de la base qui a le droit de créer un index IVFFlat peut écrire des données en dehors de la zone mémoire prévue ;
• selon l'avis, cela peut conduire à l'exécution de code arbitraire sur le serveur ;
• les versions 0.8.6 et antérieures sont touchées ;
• la faille porte l'identifiant CVE-2026-103484 ;
• elle a été signalée par quatre chercheurs de la société Compass Security.

L'avis ne donne pas plus de détails techniques, et la discussion est fermée aux commentaires. La recommandation tient en une phrase : mettre à jour dès que possible.

La 0.8.7 corrige aussi un bogue sans rapport avec la sécurité : la fonction d'agrégation avg renvoyait une erreur quand aucune ligne ne correspondait.

Qui est réellement exposé

La faille suppose un compte capable de créer un index. Le risque dépend donc de qui peut se connecter à votre base, et avec quels droits :

• Une application classique, où seul votre code parle à la base avec un compte dédié : l'exposition est limitée, sauf si une autre faille permet déjà d'injecter du SQL.
• Une base partagée entre plusieurs clients, équipes ou prestataires, chacun avec ses identifiants : c'est le cas le plus sensible.
• Un agent IA branché sur la base avec le droit d'exécuter du SQL libre : il entre dans la même catégorie qu'un utilisateur à part entière.

À noter : IVFFlat est l'un des deux types d'index de pgvector, l'autre étant HNSW. Mais ne pas utiliser IVFFlat ne protège pas. Ce qui compte, c'est que quelqu'un puisse en créer un.

Vérifier et mettre à jour

Pour connaître la version installée dans une base :

SELECT extversion FROM pg_extension WHERE extname = 'vector';

La mise à jour se fait en deux temps, d'après le README. D'abord installer la nouvelle version par la même méthode que l'installation d'origine (paquet système, image Docker, compilation). Pour une compilation depuis les sources, le dépôt indique désormais :

git clone --branch v0.8.7 https://github.com/pgvector/pgvector.git

Puis, dans chaque base qui utilise l'extension :

ALTER EXTENSION vector UPDATE;

Cette seconde étape est souvent oubliée. Sans elle, la requête de vérification continue d'afficher l'ancien numéro.

Le cas des bases hébergées

Si votre PostgreSQL est géré par un fournisseur (Neon, Supabase, un service cloud ou un hébergeur français), vous ne pouvez pas installer l'extension vous-même. La version disponible dépend du calendrier du fournisseur, et les sources que nous avons lues ne disent rien de ces calendriers. Lancez la requête de vérification, puis consultez la documentation ou le support de votre hébergeur.

Un précédent récent

Le journal des changements montre que ce n'est pas la première correction de ce type cette année. La 0.8.6, fin juillet, corrigeait déjà un dépassement de tampon lors de la construction d'un index IVFFlat, limité alors aux systèmes 32 bits. Le même journal annonce pour la future 0.9.0 l'abandon de PostgreSQL 13 et 14.

Notre lecture

Pour une petite entreprise, trois gestes suffisent. Vérifier le numéro de version dans chaque base. Mettre à jour, ou demander la date de mise à jour à l'hébergeur. Et profiter de l'occasion pour relire les droits des comptes : un compte applicatif ou un agent IA n'a généralement aucune raison de pouvoir créer des index en production. Retirer ce droit réduit le risque pour cette faille comme pour les suivantes.