CVE-2026-6471 laisse un compte de réplication PostgreSQL exécuter du code comme l’utilisateur système

2014. PostgreSQL 9.4 introduit le décodage logique — et, avec lui, le défaut qui sera référencé CVE-2026-6471 douze ans plus tard. 13 août 2026. Le projet PostgreSQL publie les correctifs 18.6, 17.11, 16.15, 15.19 et 14.24, avec un nouveau paramètre output_plugin_libraries. 1er septembre 2026. Cyera Research publie PostGREShell, le write-up détaillé qui donne son nom à la faille. Pourquoi c’est important : un compte REPLICATION — celui que détiennent les sauvegardes, les réplicas et les pipelines CDC — peut exécuter du code arbitraire comme l’utilisateur système du serveur.

Un chemin de chargement jamais contrôlé

CVE-2026-6471 relève du chargement d’une bibliothèque arbitraire via le décodage logique. Le nom de plugin fourni dans une commande CREATE_REPLICATION_SLOT est transmis directement à la fonction qui charge la bibliothèque — sans passer par la restriction de chemin qui confinerait un non-superutilisateur à un répertoire administré. Le parseur du protocole de réplication accepte presque n’importe quel caractère dans un nom de plugin entre guillemets, y compris les séparateurs de chemin et la traversée ../ : un chemin complet atteint donc le chargeur tel quel.

La conséquence est un dlopen de n’importe quel fichier visible par le compte système qui exécute le serveur. Le code chargé tourne dans le processus backend de la base, sous l’utilisateur postgres — c’est-à-dire avec les privilèges du système d’exploitation, pas ceux d’un simple rôle SQL.

La condition d’exploitation tient en deux prérequis : un compte portant l’attribut REPLICATION, et un serveur configuré avec wal_level = logical. Ce sont précisément les comptes que détiennent les outils de sauvegarde, les serveurs standby, les pipelines de change data capture (CDC) et les systèmes de supervision.

Qui est concerné : tous ceux qui répliquent

Le vecteur CVSS 3.1 évalue la faille à 7.2 (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H), avec un Privileges Required: High — un choix de notation que Cyera conteste en pointant que l’attribut REPLICATION est en pratique une crédential de sauvegarde à faible privilège, distribuée largement dans les organisations. SUSE reproduit d’ailleurs cette évaluation.

La faille est présente depuis l’introduction du décodage logique dans PostgreSQL 9.4, en 2014. Sont concernées toutes les versions antérieures à 18.6, 17.11, 16.15, 15.19 et 14.24. Les installations qui utilisent des plugins de sortie tiers — wal2json et decoderbufs notamment — subissent un effet de bord : après mise à jour, le décodage logique sera refusé tant que l’administrateur n’aura pas ajouté la bibliothèque à la liste autorisée. Le correctif ajoute le paramètre output_plugin_libraries, qui par défaut n’autorise que pgoutput, test_decoding.

La portée de l’exploitation

Sur Windows, le serveur résout un chemin réseau via SMB et récupère la bibliothèque depuis une machine contrôlée par l’attaquant, sans rien écrire sur la cible. Sur Linux et macOS, le même résultat suppose l’automontage NFS activé ; partout ailleurs, l’attaquant doit disposer d’un moyen d’écrire un fichier sur le disque du serveur. Dans tous les cas, la charge utile s’exécute comme l’utilisateur postgres.

Cyera a validé la gravité avec un plugin de test qui réécrit directement le catalogue des rôles pour transformer le compte de réplication en superutilisateur PostgreSQL, puis installe trois mécanismes de persistance qui survivent au redémarrage du serveur. Un simple droit de réplication devient ainsi un contrôle complet de l’instance, sans quitter le protocole de réplication. Les fournisseurs de bases managées — Amazon RDS, Cloud SQL, Azure Database — appliquent ces correctifs côté service, mais leurs clients restent responsables du paramétrage output_plugin_libraries et des comptes de réplication qu’ils ont eux-mêmes distribués. Le défaut n’épargne donc pas les architectures « sans serveur » : il se déplace vers la configuration.

Le projet a explicitement refusé d’appliquer la restriction LOAD existante au chemin de réplication : l’imposer rétroactivement aurait obligé tous les plugins tiers à être installés sous $libdir/plugins, cassant les déploiements existants. Le correctif privilégie donc une liste blanche explicite plutôt qu’un confinement de chemin.

Corriger et reconfigurer

La mise à jour ne suffit pas : elle durcit par défaut, et ce durcissement peut casser vos réplicas si vous n’avez pas anticipé. La marche à suivre est en trois temps.

-- 1. Lister les plugins réellement utilisés par vos slots de réplication
SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;

-- 2. Autoriser chaque plugin tiers dans postgresql.conf, puis recharger
--    output_plugin_libraries = 'pgoutput, test_decoding, wal2json'

# 3. Recharger la configuration du serveur
psql -c "SELECT pg_reload_conf();"

Après mise à jour, tout chargement refusé apparaît dans les journaux sous la forme ERROR: library "…" may not be used as an output plugin, avec un indice pointant vers le paramètre. Appliquez les correctifs 18.6, 17.11, 16.15, 15.19 ou 14.24 selon votre branche, puis vérifiez que chaque plugin tiers de décodage figure dans output_plugin_libraries — sinon vos pipelines de réplication s’arrêteront silencieusement au prochain redémarrage.

Vérifier si vous avez été compromis

Au-delà du correctif, il faut chercher les traces d’une exploitation déjà survenue. Cyera décrit un plugin de preuve de concept qui réécrit le catalogue des rôles pour promouvoir le compte de réplication en superutilisateur et installe trois mécanismes de persistance — un schéma que les DBA peuvent rechercher directement. Comparez la liste des superutilisateurs à votre inventaire, inspectez les rôles créés récemment et les entrées de pg_replication_slots qui ne correspondent pas à vos pipelines connus.

-- Rôles superutilisateurs : à comparer avec votre inventaire
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles WHERE rolsuper ORDER BY rolname;

-- Slots de réplication inattendus
SELECT slot_name, plugin, database, active FROM pg_replication_slots;

Toute bibliothèque chargée hors de la liste autorisée laisse en outre une trace explicite : ERROR: library "…" may not be used as an output plugin. Sur les instances déjà corrigées, un tel message dans les journaux est le signe d’une tentative — ou d’une exploitation réussie avant la mise à jour.

Le décodage logique, pièce maîtresse de la CDC

Pour comprendre pourquoi CVE-2026-6471 dépasse le cas des simples réplicas, il faut mesurer ce que le décodage logique alimente. Introduit dans PostgreSQL 9.4, il transforme les journaux de transactions (WAL) en un flux d’événements structurés — insertions, mises à jour, suppressions — consommés par des outils comme Debezium, pglogical ou wal2json pour alimenter des pipelines de change data capture, des index de recherche, des entrepôts de données ou des couches de cache.

La conséquence est opérationnelle : les comptes REPLICATION ne sont pas une exception réservée à quelques DBA, mais des crédentials de service déployés à l’échelle, souvent dans des fichiers de configuration, des gestionnaires de secrets ou des connecteurs. C’est précisément ce qui rend la notation CVSS trompeuse : un « privilège élevé » du point de vue du schéma PostgreSQL est, dans la pratique, un secret de bas niveau largement distribué. Chaque pipeline CDC est donc un chemin d’exploitation potentiel, et la mise à jour doit s’accompagner d’un inventaire complet de ces comptes.

Verdict

Si vous exploitez une réplication logique ou un pipeline CDC, mettez à jour vers la version corrigée de votre branche, puis autorisez explicitement vos plugins de sortie dans output_plugin_libraries avant de recharger — le défaut est présent depuis 2014 et l’exploitation ne demande qu’un compte REPLICATION déjà compromis.

Si vous n’utilisez pas le décodage logique, la mise à jour reste nécessaire : la faille est exploitable dès que wal_level = logical est activé, et ce paramètre peut être activé par un administrateur sans que vous l’ayez remarqué.

Dans tous les cas, traitez les comptes REPLICATION comme des secrets sensibles, pas comme des crédentials de bas niveau : c’est l’écart entre la notation CVSS et la réalité opérationnelle qui rend CVE-2026-6471 dangereuse.

Références

• NVD — CVE-2026-6471
• PostgreSQL — CVE-2026-6471 security page
• PostgreSQL — 18.6, 17.11, 16.15, 15.19, 14.24 release announcement
• Cyera Research — PostGREShell: the database powering much of the internet had an open door for 12 years
• The Hacker News — PostgreSQL Fixes 12-Year-Old Logical Decoding Flaw Enabling Replication-Role Code Execution