PostGREShell, une faille de PostgreSQL transforme les comptes de réplication en tremplin pour exécuter du code

Une vulnérabilité du système de réplication logique de PostgreSQL permet à un compte doté de l’attribut REPLICATION de charger du code arbitraire dans le processus de la base de données. La faille, identifiée sous le nom CVE-2026-6471 et baptisée PostGREShell par Cyera, a obtenu un score CVSS de 7.2.

L’attaque ne nécessite pas de disposer initialement des privilèges de superuser PostgreSQL. Elle requiert toutefois un compte autorisé à effectuer la réplication, un accès souvent accordé aux logiciels de sauvegarde, aux serveurs secondaires, aux pipelines et aux plateformes de supervision.

Une fois chargé, le code malveillant s’exécute avec les droits du compte du système d’exploitation qui gère PostgreSQL. Depuis cette position, il peut également manipuler les mécanismes internes de la base de données et aller jusqu’à attribuer durablement les privilèges de superuser.

Au 4 septembre 2026, aucune information ne permet de classer CVE-2026-6471 parmi les vulnérabilités figurant dans le catalogue Known Exploited Vulnerabilities de la CISA. Aucune échéance de correction imposée par la CISA n’est donc connue.

Le point faible se situe dans la sélection du plugin de décodage logique

La vulnérabilité concerne le décodage logique, une fonctionnalité utilisée par la réplication logique pour convertir les modifications enregistrées par la base de données en un flux interprétable par des applications externes.

Lorsqu’un client ouvre une session de réplication logique, il crée un slot et précise quel plugin de sortie doit traiter les événements. PostgreSQL doit alors identifier et charger la bibliothèque correspondante.

Le problème vient de l’absence d’un contrôle d’autorisation, classé CWE-862, Missing Authorization. Un utilisateur qui n’est pas superuser mais qui possède l’attribut REPLICATION peut fournir un fichier arbitraire à la place d’un plugin normalement autorisé.

Selon l’analyse technique de Cyera, l’analyseur du protocole accepte, dans le nom du plugin placé entre guillemets doubles, plusieurs caractères permettant de construire un chemin :

• slash et antislash ;
• points ;
• séquences de traversée de répertoires telles que ../ ;
• chemins UNC utilisés dans les environnements Windows.

Le nom est transmis au chargeur sans validation suffisante. L’attaquant peut ainsi fournir un chemin complet à dlopen(), au lieu de se limiter au nom d’une bibliothèque prévue par la configuration.

Le payload est chargé dans le même espace d’adressage que le processus PostgreSQL. Aucun sandbox dédié n’intervient et le code peut appeler les API internes de la base de données avec les privilèges du processus en cours d’exécution.

Il ne suffit donc pas de considérer un compte comme fiable au seul motif qu’il n’est pas superuser. Dans ce scénario, REPLICATION devient une capacité d’exécution de code.

De l’exécution dans le processus à la modification de pg_authid

Le premier impact concerne le compte du système d’exploitation qui exécute PostgreSQL. Une bibliothèque malveillante peut lire et modifier tout ce qui est accessible à ce processus, en plus d’interférer directement avec le fonctionnement de la base de données.

Cyera a également décrit une méthode permettant d’obtenir les privilèges de superuser PostgreSQL. Le plugin peut appeler des fonctions internes pour agir en tant que superuser bootstrap et modifier directement pg_authid, le catalogue qui contient les attributs sensibles des comptes.

En modifiant les indicateurs correspondants, l’attaquant peut transformer une identité existante en superuser permanent. La compromission ne reste donc pas limitée à la session de réplication utilisée pour lancer l’attaque.

Ces privilèges permettent notamment :

• d’accéder aux tables de toutes les bases de données hébergées ;
• de modifier les configurations, les rôles et les objets ;
• de lire les clés privées accessibles au processus PostgreSQL ;
• d’écrire des fichiers dans les chemins accessibles au compte de service ;
• d’exécuter des commandes sur le système d’exploitation ;
• d’installer des mécanismes de persistance.

La persistance peut inclure l’activation d’accès sans mot de passe, la copie du payload dans un emplacement durable et son enregistrement afin qu’il soit chargé par les nouveaux processus backend. Le code peut également réappliquer les modifications de privilèges après une tentative de restauration.

La simple révocation du rôle compromis est donc insuffisante. Si une bibliothèque a déjà été installée ou enregistrée, il faut également vérifier le système d’exploitation et les mécanismes de démarrage de PostgreSQL.

Les versions vulnérables et les versions à installer

La vulnérabilité concerne PostgreSQL. La description de la NVD indique comme vulnérables les versions antérieures aux versions correctives suivantes, chacune dans sa branche respective :

Branche PostgreSQL	Première version corrigée
18	18.6
17	17.11
16	16.15
15	15.19
14	14.24

SecurityWeek situe le périmètre concerné entre PostgreSQL 9.4 et 18 et indique que Cyera a également vérifié le problème sur la version 18.2. Il s’agit donc d’une faiblesse présente dans des versions distribuées depuis 2014.

Une ligne récapitulative associée à la fiche CVE reprend la formulation plus restrictive postgresql postgresql < 14.24. Cette indication contredit toutefois le détail de l’avis de sécurité, qui énumère explicitement des corrections pour les branches 15, 16, 17 et 18.

Pour la gestion opérationnelle, il faut donc considérer comme vulnérables :

• les versions 18 antérieures à la 18.6 ;
• les versions 17 antérieures à la 17.11 ;
• les versions 16 antérieures à la 16.15 ;
• les versions 15 antérieures à la 15.19 ;
• les versions 14 antérieures à la 14.24.

Pour les branches 9.4 à 13, aucune version corrective spécifique n’est indiquée. Les organisations qui les utilisent doivent en tenir compte dans leur plan de mise à niveau et ne pas interpréter l’absence d’une version corrigée répertoriée comme l’absence de vulnérabilité.

Pourquoi les comptes REPLICATION sont la principale cible

Le vecteur CVSS est CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. L’attaque est réalisable à distance, présente une faible complexité et ne nécessite aucune interaction de la part d’un utilisateur.

L’exigence PR:H indique que des privilèges élevés sont nécessaires. Dans le cas de PostGREShell, cela ne signifie toutefois pas que l’attaquant doit déjà être administrateur de la base de données : il doit contrôler un compte doté de l’attribut REPLICATION.

Ces identifiants peuvent se trouver dans les systèmes de sauvegarde, les secrets des pipelines, les serveurs secondaires ou les configurations des outils d’observabilité. Une organisation peut donc les avoir protégés de manière moins stricte que les comptes explicitement classés comme administratifs.

Les conséquences concernent aussi bien les installations sur site que les bases de données accessibles depuis les réseaux d’entreprise ou les infrastructures cloud. Pour exploiter la faille, il faut néanmoins disposer d’identifiants appropriés et pouvoir démarrer ou utiliser une session de réplication logique.

Aucun indicateur de compromission spécifique, tel qu’un hash, un nom de payload ou une adresse réseau, n’a été publié. On ignore également si la vulnérabilité est déjà exploitée dans le cadre d’attaques réelles.

Mise à jour, audit des rôles et recherche de chargements anormaux

La principale mesure consiste à installer PostgreSQL 18.6, 17.11, 16.15, 15.19 ou 14.24, selon la branche utilisée. Aucun contournement officiel de la mise à jour corrective n’a été indiqué.

Les administrateurs doivent ensuite recenser tous les comptes dotés de REPLICATION et vérifier que ce privilège est justifié par un besoin opérationnel documenté. Lorsqu’il n’est pas nécessaire, il doit être supprimé.

Les activités de détection peuvent notamment porter sur :

• la création ou l’utilisation inhabituelle de slots de réplication logique ;
• les sessions de réplication provenant d’adresses ou de systèmes inattendus ;
• les noms de plugins contenant des séparateurs de chemin, ../ ou des chemins UNC ;
• le chargement de bibliothèques depuis des répertoires non prévus ;
• les modifications anormales des rôles et des attributs conservés dans pg_authid ;
• les changements apportés aux règles d’authentification, notamment les connexions sans mot de passe ;
• les fichiers nouveaux ou modifiés dans les répertoires accessibles au processus PostgreSQL ;
• les configurations provoquant le chargement persistant de bibliothèques dans les nouveaux processus backend.

Si des signes d’exploitation sont détectés, la réponse ne doit pas se limiter à changer les mots de passe. Il faut considérer comme compromis la base de données, le compte de service PostgreSQL et tous les secrets lisibles par ce processus.

La rotation des identifiants doit s’accompagner d’une vérification des bibliothèques chargées, des fichiers modifiés, des rôles superuser et des paramètres d’authentification. Ce n’est qu’après cette remédiation que la mise à jour pourra fermer le vecteur d’attaque sans laisser actifs les mécanismes de persistance déjà installés.