⚠️ Alerte sécurité : patchez PostgreSQL maintenant
Le 14 mai 2026, une vulnérabilité critique a été publiée concernant l'extension refint de PostgreSQL. Référencée sous CVE-2026-6637 avec un score CVSS de 8.8, elle permet à n'importe quel utilisateur non privilégié de la base de données d'exécuter du code arbitraire sous l'identité système (OS user) du processus PostgreSQL. Concrètement : un utilisateur lambda avec un simple accès en lecture peut potentiellement prendre le contrôle du serveur.
La réponse immédiate est claire : appliquez les mises à jour mineures du 14 mai correspondant à votre version :
- PostgreSQL 18.4
- PostgreSQL 17.10
- PostgreSQL 16.14
- PostgreSQL 15.18
- PostgreSQL 14.23
Et si refint est installée dans l'une de vos bases, supprimez-la immédiatement :
DROP EXTENSION IF EXISTS refint;
Qu'est-ce que refint, et pourquoi est-elle encore là ?
refint est une extension du répertoire contrib de PostgreSQL. Elle a été committée le 10 septembre 1997 comme contournement pour l'intégrité référentielle, à une époque où PostgreSQL ne supportait pas encore les clés étrangères natives. Ce support est arrivé avec PostgreSQL 7.3, il y a plus de vingt ans. Depuis, refint n'a plus aucune utilité fonctionnelle.
Pourtant, elle est toujours présente dans l'arbre contrib. Pourquoi ? Parce que personne ne voulait être celui qui supprime le code de quelqu'un d'autre. C'est une réalité bien connue dans les projets open source de longue durée : le code vieillit sur place, et les modules historiques s'accumulent sans que personne ne remette vraiment en question leur présence.
Ce cas illustre un principe fondamental en sécurité : la surface d'attaque inclut tout ce qui est installé, qu'on s'en souvienne ou non.
Le vrai problème : savez-vous ce qui tourne en production ?
Au-delà du patch d'urgence, cette CVE soulève une question de fond que Christophe Pettus formule très bien dans son article original : combien d'équipes peuvent répondre immédiatement à « quelles extensions sont installées dans vos bases de production » ?
D'après son expérience, très peu — sans aller vérifier au préalable.
Ce phénomène s'explique par la mécanique même des upgrades PostgreSQL. L'outil pg_upgrade préserve par défaut les extensions installées lors d'une migration majeure. C'est le comportement correct : il ne faut pas casser des bases qui fonctionnent. Mais la conséquence directe, c'est qu'une base créée en 2014, upgradée continuellement jusqu'en 2026, peut embarquer des modules que personne dans l'équipe actuelle ne connaît.
Le répertoire contrib de PostgreSQL contient des extensions à tous les stades de maturité et d'utilité :
- Essentielles :
pg_stat_statements, pgcrypto, btree_gin
- Occasionnellement utiles :
pg_buffercache, pageinspect, pg_visibility
- Curiosités historiques :
refint, tsm_system_rows, intarray — des reliques pré-clés-étrangères qui survivent parce qu'elles n'ont jamais été explicitement retirées
Chaque extension installée est un vecteur potentiel. La CVE-2026-6637 en est la démonstration directe.
Actions concrètes : auditez vos extensions PostgreSQL
Patcher est nécessaire, mais insuffisant. Voici une démarche pratique pour reprendre le contrôle.
1. Inventoriez toutes vos extensions installées
Connectez-vous à chacune de vos bases et exécutez :
SELECT
e.extname AS extension,
e.extversion AS version,
n.nspname AS schema,
e.extrelocatable
FROM pg_extension e
JOIN pg_namespace n ON n.oid = e.extnamespace
ORDER BY e.extname;
Si vous gérez plusieurs bases sur un même cluster :
-- À exécuter sur chaque base du cluster
SELECT current_database(), extname, extversion
FROM pg_extension
ORDER BY extname;
2. Questionnez chaque extension présente
Pour chaque entrée dans cette liste, posez-vous les questions suivantes :
- Qui l'a installée, et pourquoi ?
- Est-elle encore utilisée activement ?
- Une fonctionnalité native de PostgreSQL la rend-elle obsolète ?
- Est-elle maintenue activement dans
contrib ou par un tiers ?
Si vous ne pouvez pas répondre à ces questions, c'est un signal d'alerte.
3. Supprimez ce qui n'est pas justifié
Le principe est simple : tout ce qui n'est pas explicitement nécessaire doit être retiré. Une extension non utilisée n'apporte aucune valeur, mais représente un risque réel — comme vient de le démontrer refint.
-- Vérifier les dépendances avant suppression
SELECT classid, objid, deptype
FROM pg_depend
WHERE refobjid = (SELECT oid FROM pg_extension WHERE extname = 'nom_extension');
-- Supprimer si aucune dépendance critique
DROP EXTENSION IF EXISTS nom_extension;
4. Documentez et automatisez la surveillance
Intégrez l'audit des extensions dans vos processus :
- Documentation : maintenez une liste explicite des extensions autorisées par environnement
- CI/CD : vérifiez que les migrations ne créent pas d'extensions non approuvées
- Monitoring : alertez si une nouvelle extension apparaît en production sans être référencée
Conclusion : la dette technique a un coût sécuritaire
La CVE-2026-6637 est un excellent exemple de ce que la dette technique peut coûter en termes de sécurité. Une extension vieille de presque trente ans, devenue inutile depuis 2003, reste installée sur des milliers de serveurs en production — et livre aujourd'hui une faille critique.
Le patch est obligatoire. Mais l'audit est tout aussi urgent. Prenez le temps, ce lundi matin, de lister ce qui tourne réellement dans vos bases PostgreSQL. Vous serez peut-être surpris de ce que vous y trouverez.
📖 Source originale : Christophe Pettus — "What Else Is In There?", publié le 26 mai 2026.
