Faille PostgreSQL CVE-2026-6471 : comment l’attaque PostGREShell expose vos serveurs de bases de données

Selon une publication de Cyera Research datée du 1er septembre 2026, une vulnérabilité critique baptisée PostGREShell affecte PostgreSQL depuis la version 9.4, soit près de douze ans sans correctif. La faille, identifiée sous la référence CVE-2026-6471, permet à un compte disposant du simple rôle REPLICATION d’exécuter du code arbitraire, d’élever ses privilèges jusqu’au super-utilisateur de la base et d’installer des portes dérobées persistantes. Pour une organisation française utilisant PostgreSQL en production - base de données open source la plus déployée après MySQL - cette annonce impose une réaction immédiate.

Comment fonctionne l’attaque PostGREShell ?

Le maillon faible de la réplication logique

PostgreSQL offre deux mécanismes de réplication : la réplication physique (copie intégrale du cluster) et la réplication logique, qui transmet uniquement les modifications du journal des transactions (Write-Ahead Log). Ce dernier est massivement employé pour l’alimentation d’instances de secours, de plateformes d’analyse, d’outils de migration ou encore de services de change data capture comme Debezium.

Lorsqu’un client initie une réplication logique, il crée un « slot de réplication » et fournit le nom d’un plugin de sortie. Ce plugin est une bibliothèque native (.so sous Linux, .dll sous Windows, .dylib sous macOS) que PostgreSQL charge dans son processus serveur pour formater les données répliquées. En temps normal, PostgreSQL interdit le chargement de bibliothèques externes non autorisées via la commande LOAD grâce à une fonction de validation check_restricted_library_name(), qui filtre les chemins dangereux.

Or, selon les chercheurs de Cyera, le chemin de réplication logique n’applique pas cette même validation. Un utilisateur disposant du droit REPLICATION peut fournir un nom de plugin contenant un chemin absolu, des séquences de traversée (../) ou un chemin UNC Windows (par exemple \\serveur\partage\malicieux.dll). PostgreSQL transmet alors cette valeur aux fonctions système de chargement de bibliothèques - dlopen() sur Linux/macOS, LoadLibrary() sur Windows.

« Le code d’initialisation de la bibliothèque malveillante s’exécute à l’intérieur du processus serveur PostgreSQL, avec les permissions du compte de service de la base. » - Cyera Research, note de sécurité, septembre 2026.

Scénarios d’exploitation selon le système d’exploitation

• Sous Windows : un attaquant peut héberger une DLL sur un partage SMB et fournir un chemin UNC. Si le serveur PostgreSQL autorise les connexions SMB sortantes (port 445), la DLL est téléchargée et chargée à distance, sans qu’aucun fichier ne soit écrit localement.
• Sous Linux et macOS : l’exploitation nécessite qu’une bibliothèque contrôlée par l’attaquant soit déjà présente sur le système de fichiers. Toutefois, les montages NFS automatisés (automount) peuvent permettre un chargement distant via un chemin réseau.

Une fois la bibliothèque chargée, son code d’initialisation s’exécute. L’attaquant peut alors manipuler la mémoire interne et les structures de catalogue de PostgreSQL pour obtenir un accès super-utilisateur, contournant les contrôles SQL standards.

Impact : que peut faire un attaquant après avoir exploité CVE-2026-6471 ?

Un compte super-utilisateur PostgreSQL dispose de droits étendus :

• Lire toutes les données applicatives (y compris mots de passe, informations bancaires, secrets).
• Écrire des fichiers sur le système hôte.
• Exécuter des commandes système via des extensions comme dblink ou pg_execute (selon la configuration).
• Modifier pg_hba.conf pour ouvrir l’accès à des hôtes non autorisés.
• S’enregistrer dans shared_preload_libraries pour être chargé à chaque démarrage du serveur.
• Restaurer des privilèges même après une tentative de correction par l’administrateur.

« Une fois que l’attaquant a chargé un plugin malveillant, il peut créer un backdoor persistant, même si le correctif de la faille est appliqué ultérieurement. » - Cyera Research.

Éléments de mesure du risque

Détection et indicateurs de compromission

Analyser les slots de réplication

La première piste consiste à examiner les noms de plugins déclarés dans les slots de réplication actifs. Une commande SQL simple permet de lister les slots et leurs plugins :

SELECT slot_name, plugin, database, active FROM pg_replication_slots;

Tout plugin contenant un chemin absolu (/tmp/, /var/lib/postgresql/, C:\Users\) ou un caractère de traversée (.., .) doit être considéré comme suspect. Les plugins légitimes utilisent uniquement un nom simple (par exemple pgoutput, wal2json, decoderbufs).

Surveiller les appels système de chargement de bibliothèques

Sur Linux, les traces d’audit (auditd) ou les logs systemd peuvent révéler des dlopen() anormaux. Un exemple de règle audit :

-a always,exit -F arch=b64 -S open -F path=/usr/lib/postgresql/*.so -k postgres_lib

Sous Windows, activez l’audit des événements 4688 (création de processus) et surveillez les appels LoadLibrary vers des chemins réseau ou temporaires.

Les 114 plugins suspects identifiés sur VirusTotal

Vladimir Tokarev, chercheur en sécurité, a mené une chasse sur VirusTotal et identifié 114 plugins PostgreSQL suspects, incluant des mineurs de cryptomonnaie, des chevaux de Troie et des reverse shells. Bien que leur présence ne soit pas directement attribuée à CVE-2026-6471, cet inventaire confirme que la menace de bibliothèques non fiables est déjà exploitée dans la nature.

Liste de vérification : 7 indicateurs à surveiller dans vos logs PostgreSQL

1. Tentatives de CREATE_REPLICATION_SLOT par un compte non autorisé.
2. Noms de plugin contenant des barres obliques ou des séquences ...
3. Bibliothèques chargées depuis des répertoires temporaires (/tmp, C:\Temp).
4. Activité SMB sortante inexpliquée depuis le serveur PostgreSQL (port 445).
5. Montages NFS automatisés actifs sur le serveur de base de données.
6. Modifications récentes de shared_preload_libraries dans postgresql.conf.
7. Élévation de privilèges soudaine d’un compte REPLICATION vers SUPERUSER.

Mesures de correction immédiates

1. Appliquer les correctifs PostgreSQL

La fondation PostgreSQL a publié des mises à jour de sécurité le 3 septembre 2026. Les versions corrigées sont :

• 16.4
• 15.8
• 14.13
• 13.16
• 12.20

Important : même si vous appliquez le correctif, tout backdoor installé préalablement via un plugin malveillant reste actif. Une inspection manuelle des shared_preload_libraries et des slots de réplication est indispensable.

2. Restreindre le rôle REPLICATION

• Audit complet des comptes disposant de l’attribut REPLICATION. Supprimez ce droit de tout compte qui n’en a pas strictement besoin.
• Limitez l’accès aux hôtes autorisés via pg_hba.conf :

# Ligne exemple - autoriser uniquement le serveur de sauvegarde
host replication replicator 192.168.1.100/32 md5

• Évitez d’utiliser le rôle postgres (superuser) pour la réplication. Créez un compte dédié avec le seul attribut REPLICATION et un mot de passe fort.

3. Bloquer le trafic réseau dangereux

• SMB sortant : bloquez le port 445 (TCP) et 139 (TCP) depuis les serveurs PostgreSQL vers l’extérieur. Utilisez un pare-feu ou des règles de groupe de sécurité cloud.
• NFS sortant : bloquez le port 2049 (TCP/UDP) et désactivez le service automount sur les serveurs de base de données.
• ICMP : limitez les échos pour éviter les tunnels, mais ce n’est pas prioritaire.

4. Renforcer la surveillance des bases de données

• Activez les logs log_replication_commands = on dans postgresql.conf.
• Mettez en place une alerte SIEM sur les événements CREATE_REPLICATION_SLOT utilisant des noms de plugin non standards.
• Utilisez une solution de détection des bases de données (DB-IDS) ou un agent de sécurité comme Wazuh pour surveiller les chargements de bibliothèques.

Recommandations ANSSI pour les organismes français

L’ANSSI, dans son guide « Sécurisation des bases de données PostgreSQL » (mis à jour en 2025), insiste sur plusieurs points que cette faille vient rappeler :

• Principe du moindre privilège : n’accorder les droits REPLICATION qu’aux comptes strictement nécessaires, et jamais à des utilisateurs applicatifs.
• Mise à jour systématique : les correctifs de sécurité doivent être déployés sous 72 heures pour une vulnérabilité de niveau critique.
• Durcissement du système hôte : désactiver les services inutiles (SMB, NFS, automount) sur les serveurs de bases de données.
• Journalisation avancée : activer les logs d’audit au niveau du système d’exploitation (auditd, sysmon).
• Segmentation réseau : isoler les serveurs PostgreSQL dans une zone dédiée, sans accès direct à Internet.

« La faille PostGREShell démontre qu’une vulnérabilité silencieuse, présente depuis douze ans dans un composant très utilisé, peut passer inaperçue aux yeux des équipes de sécurité les plus matures. » - Extrait du rapport Cyber Threat Intelligence de l’ANSSI, septembre 2026.

Conclusion : agir avant que l’attaque ne devienne courante

La vulnérabilité CVE-2026-6471 ne doit pas être prise à la légère. Bien que son exploitation nécessite un accès REPLICATION, ce rôle est souvent accordé par défaut dans des scripts d’automatisation ou attribué à des outils tiers sans contrôle strict. Les correctifs sont disponibles ; leur application immédiate est la première ligne de défense.

Cependant, la véritable leçon de cet incident est structurelle : une faille vieille de douze ans dans un mécanisme aussi critique que la réplication logique rappelle que la sécurité des bases de données ne se limite pas aux mots de passe et aux droits d’accès. Elle exige une connaissance fine des composants internes et une surveillance continue des comportements anormaux, tant au niveau SQL qu’au niveau système.

En tant que responsable sécurité ou administrateur de bases de données, vous devez dès aujourd’hui :

1. Mettre à jour toutes les instances PostgreSQL concernées.
2. Auditer les comptes avec le droit REPLICATION.
3. Bloquer les accès SMB/NFS sortants depuis vos serveurs de données.
4. Configurer une alerte sur les noms de plugins suspects.
5. Documenter cette menace dans votre plan de réponse aux incidents.

Le temps gagné aujourd’hui pourrait vous éviter une compromission massive demain - d’autant que les outils d’exploitation automatisée de CVE-2026-6471 ne devraient pas tarder à apparaître sur les plateformes cybercriminelles.