PostgreSQL, une faille du logical decoding permet d’exécuter du code en tant qu’utilisateur `postgres`

PostgreSQL a corrigé CVE-2026-6471, une vulnérabilité du système de logical decoding qui permet de charger des bibliothèques partagées arbitraires sur le serveur de bases de données.

Il n’est pas nécessaire d’être superuser pour l’exploiter. L’attaquant doit toutefois disposer d’un compte PostgreSQL doté de l’attribut REPLICATION, tandis que le serveur doit être configuré avec wal_level = logical.

Une fois la bibliothèque chargée, le code s’exécute au sein du processus backend avec l’identité du compte système qui gère PostgreSQL, généralement postgres. Les conséquences peuvent donc inclure le vol ou la modification de données, l’indisponibilité du service, l’escalade de privilèges et la persistance sur le système.

La vulnérabilité, baptisée PostGREShell par les chercheurs de Cyera, obtient un score CVSS 3.1 de 7,2 et est classée comme une absence de contrôle d’autorisation (CWE-862). Vladimir Tokarev et Yu Kunpeng ont été crédités par le PostgreSQL Global Development Group pour le signalement. Tokarev a publié une analyse technique le 1er septembre.

Quelles versions de PostgreSQL doivent être mises à jour

Les releases upstream qui corrigent CVE-2026-6471, publiées le 13 août, sont les suivantes :

• PostgreSQL 18.6
• PostgreSQL 17.11
• PostgreSQL 16.15
• PostgreSQL 15.19
• PostgreSQL 14.24

Les versions antérieures de chacune de ces cinq branches sont vulnérables. L’advisory du projet concerne en effet les séries encore prises en charge, de la 14 à la 18.

La faille remonte toutefois à l’introduction du logical decoding dans PostgreSQL 9.4, en 2014. Les séries antérieures à la 14 ne sont pas couvertes par l’avis upstream actuel : leurs utilisateurs devraient donc planifier une migration vers une version prise en charge, plutôt que de considérer leur absence de la liste comme une preuve de sécurité.

Des paquets corrigés sont également disponibles pour Amazon RDS, Debian, SUSE et Ubuntu. L’avis Ubuntu USN-8653-1, publié le 20 août 2026, fournit les versions suivantes :

Ubuntu	Paquet corrigé
26.04 LTS	postgresql-18 18.6-0ubuntu0.26.04.1
24.04 LTS	postgresql-16 16.15-0ubuntu0.24.04.1
22.04 LTS	postgresql-14 14.24-0ubuntu0.22.04.1

Ubuntu requiert le redémarrage de PostgreSQL après la mise à jour de sécurité classique. Le paquet corrige également plusieurs autres vulnérabilités, et pas uniquement celle du logical decoding.

Par ailleurs, PostgreSQL 14 ne recevra plus de correctifs à partir du 12 novembre 2026. Les organisations qui utilisent encore cette branche devraient donc également inclure la migration vers une release ultérieure dans leur plan opérationnel.

Du nom du plugin à dlopen() : déroulement de l’attaque

Le logical decoding convertit les modifications enregistrées dans le write-ahead log en un format exploitable par des systèmes externes. Il est notamment utilisé dans les pipelines de change data capture et par des outils qui transfèrent les modifications vers d’autres plateformes.

Lors de la création d’un slot de réplication, notamment au moyen de CREATE_REPLICATION_SLOT, le client peut indiquer le plugin de sortie à utiliser. Avant le correctif, PostgreSQL ne vérifiait pas suffisamment qu’un utilisateur doté de REPLICATION était autorisé à charger la bibliothèque demandée.

Le nom du plugin était ainsi transmis à la fonction de chargement dynamique. Le parseur du protocole de réplication acceptait, dans les noms placés entre guillemets, les séparateurs de répertoire, les chemins absolus et les séquences de traversée telles que ../.

Le résultat était l’appel de dlopen() sur un fichier choisi par l’attaquant, à condition que celui-ci soit accessible au compte du système d’exploitation exécutant PostgreSQL. La bibliothèque était chargée dans l’espace du processus backend et son code héritait des privilèges de l’utilisateur postgres.

Les restrictions normalement appliquées par la commande SQL LOAD aux utilisateurs qui ne sont pas superusers ne couvraient pas ce chemin. Il était donc possible de contourner une protection existante en passant par le protocole de réplication.

La disponibilité de la bibliothèque malveillante dépend de la plateforme :

• sous Windows, le chemin peut pointer vers un partage SMB contrôlé par l’attaquant, sans qu’il soit nécessaire de copier d’abord le fichier sur le serveur ;
• sous Linux et macOS, un chargement similaire depuis le réseau nécessite que l’automount NFS soit actif ;
• dans les autres scénarios, l’attaquant doit déjà disposer d’un moyen d’écrire la bibliothèque sur le disque du serveur.

Lors des tests de Cyera, le code chargé a directement modifié le catalogue des rôles, transformant le compte de réplication en superuser PostgreSQL. Les chercheurs ont également créé trois formes de persistance capables de survivre à un redémarrage.

Le privilège requis n’est pas celui de superuser, mais il reste sensible

Le vecteur complet attribué à la faille est CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. Il indique une attaque réalisable à distance, de faible complexité et sans interaction de l’utilisateur, mais nécessitant des privilèges élevés.

La classification PR:H peut sembler contradictoire avec le fait que le compte ne doive pas être administrateur. Elle décrit en réalité une condition préalable précise : l’attribut REPLICATION doit avoir été accordé au préalable.

Ce privilège est souvent attribué à des comptes techniques utilisés par des serveurs standby, des solutions de sauvegarde, des plateformes CDC et des systèmes de supervision. La compromission de l’un de ces identifiants peut donc se transformer en exécution de code sur le système d’exploitation.

Aucun proof-of-concept public n’avait été identifié dans les dépôts examinés au 4 septembre. À la même date, CVE-2026-6471 ne figurait pas dans le catalogue CISA Known Exploited Vulnerabilities et aucune échéance KEV ne lui était associée.

Aucun élément public ne permet donc d’attester une exploitation active. L’impact reste néanmoins important, en particulier lorsque les comptes de service sont partagés, peu surveillés ou autorisés à se connecter depuis des réseaux étendus.

Le correctif introduit une whitelist pour les plugins de sortie

Le correctif ajoute le paramètre serveur suivant :

output_plugin_libraries

La valeur par défaut autorise deux bibliothèques :

pgoutput, test_decoding

Après la mise à jour, les plugins tiers tels que wal2json et decoderbufs doivent être ajoutés explicitement à la whitelist. Dans le cas contraire, les slots qui les utilisent ne pourront pas démarrer correctement le logical decoding.

Avant d’installer le correctif, les administrateurs peuvent identifier les plugins déjà associés aux slots à l’aide de la requête suivante :

SELECT DISTINCT plugin
FROM pg_replication_slots
WHERE plugin IS NOT NULL;

La requête renvoie les plugins utilisés avec succès au moins une fois. Elle ne détecte pas nécessairement toutes les intégrations configurées mais pas encore activées.

Après la mise à jour de PostgreSQL, chaque plugin légitime qui ne figure pas dans la valeur par défaut doit être ajouté à output_plugin_libraries. La configuration peut ensuite être rechargée avec :

pg_ctl reload

ou :

SELECT pg_reload_conf();

La modification du paramètre ne nécessite pas de redémarrage. Les éventuelles consignes plus restrictives de la distribution restent applicables, comme le redémarrage prévu par la mise à jour Ubuntu.

PostgreSQL a privilégié une whitelist plutôt qu’un simple élargissement des règles de LOAD. Cette dernière solution aurait obligé à installer tous les plugins externes sous $libdir/plugins, interrompant ainsi de nombreuses configurations existantes.

Une limite opérationnelle reste également en suspens. pg_createsubscriber crée des slots avec pgoutput sans vérifier le nouveau paramètre : --dry-run peut réussir, tandis que l’opération réelle peut échouer si la whitelist exclut le plugin. Au 4 septembre, un correctif signalé par Hayato Kuroda de Fujitsu était encore en cours d’examen.

Lors des migrations depuis PostgreSQL 17 ou une release ultérieure, la whitelist du nouveau cluster doit en outre être configurée avant d’exécuter :

pg_upgrade --check

Dans le cas contraire, le contrôle peut échouer lorsque les slots existants dépendent de plugins non autorisés.

Vérifications immédiates, mesures d’atténuation et signes à rechercher

Si le correctif ne peut pas être appliqué immédiatement, les administrateurs devraient retirer l’attribut REPLICATION aux comptes qui n’ont pas de besoin documenté et restreindre, dans pg_hba.conf, les adresses autorisées à établir des connexions de réplication.

Il est également recommandé de bloquer depuis les serveurs de bases de données le trafic SMB sortant sur le port 445 et le trafic NFS sur le port 2049 lorsqu’ils ne sont pas nécessaires. autofs devrait être désactivé sur les systèmes qui ne l’utilisent pas.

Après la mise à jour, les tentatives de chargement de plugins exclus de la whitelist génèrent dans les journaux une erreur contenant :

may not be used as an output plugin

La présence de ce message peut signaler une configuration légitime qui n’a pas encore été adaptée, mais aussi une tentative de chargement d’une bibliothèque non autorisée. Il convient donc de la corréler avec le compte, l’adresse source et le nom du fichier demandé.

L’analyse devrait également porter sur :

• les comptes dotés de l’attribut REPLICATION ;
• les slots répertoriés dans pg_replication_slots ;
• les plugins associés aux slots ;
• les modifications inattendues du catalogue des rôles ;
• les nouvelles formes de persistance créées par l’utilisateur opérationnel de la base de données ;
• les connexions SMB ou NFS anormales établies depuis le serveur PostgreSQL.

La priorité reste l’installation d’une release corrigée. La whitelist réduit l’exposition sans imposer une réorganisation complète des plugins, mais elle nécessite un inventaire précis afin d’éviter les interruptions dans les pipelines de réplication et de change data capture.