PostgreSQL : 12 ans de porte dérobée derrière ton compte de sauvegarde

Le 1er septembre, les chercheurs de Cyera ont publié un rapport qui fait froid dans le dos. Dans PostgreSQL, la base de données open source la plus utilisée au monde, une faille dormait depuis 2014. Elle porte même un nom : PostGREShell. Un compte de sauvegarde tout ce qu'il y a de plus ordinaire, le genre de compte qu'on crée sans y penser sur chaque serveur, suffisait à exécuter du code sur la machine, à devenir superutilisateur, à lire toutes les données et à installer une porte dérobée qui survit aux redémarrages. Référencée CVE-2026-6471, avec un score CVSS de 7,2, elle est corrigée depuis la mi-août dans les versions 18.6, 17.11, 16.15, 15.19 et 14.24. Si tu héberges un PostgreSQL, sur un NAS, sur un VPS ou dans un conteneur, et que ta dernière mise à jour date d'avant, tu sais ce qu'il te reste à faire ce soir.

Le compte de sauvegarde que personne ne surveille

PostgreSQL repose sur un mécanisme simple : un serveur principal écrit, et des répliques se synchronisent en permanence pour la sauvegarde et la haute disponibilité. Pour se synchroniser, ces outils utilisent un compte doté de l'attribut REPLICATION. Et ce compte, tu en croises partout : chaque outil de sauvegarde, chaque serveur secondaire, chaque pipeline d'intégration continue qui lit les modifications en temps réel, chaque système de monitoring branché sur la base. Cyera résume le problème en une phrase : la documentation décrit ce privilège comme nécessaire pour lancer une réplication en continu, pas pour exécuter du code. Résultat, tout le monde le traite comme de la plomberie à risque faible et personne ne le verrouille.

Source : Cyera Research, la recherche PostGREShell qui décrit le rôle de ces comptes.

Un nom de plugin jamais vérifié

La réplication logique, le mode qui enregistre les modifications sous forme d'événements lisibles par des outils externes, repose sur un détail technique devenu la faille : le client qui vient lire le flux nomme un « plugin de sortie », un petit fichier de code que PostgreSQL charge pour formater les données. Le nom de ce plugin part tel quel vers le chargeur du système d'exploitation, la fonction C dlopen qui ouvre une bibliothèque en mémoire et exécute son code d'entrée. Sur le chemin SQL habituel, un garde-fou interdit aux comptes ordinaires de charger du code hors d'un répertoire contrôlé par l'administrateur. Sur le chemin de la réplication, ce garde-fou n'est tout simplement jamais appelé.

Conséquence : l'attaquant remplace le nom du plugin par un chemin de fichier, avec des slashes, des points ou des « ../ », et le chargeur avale tout. Son code s'exécute avec les droits du processus postgres. Sur Windows, c'est encore plus direct : un chemin réseau suffit, la base va chercher elle-même la bibliothèque sur le serveur de l'attaquant via SMB, le port 445, sans jamais rien écrire sur le disque de la victime. L'exploit tient en trois lignes de Python, une connexion avec le compte de réplication et une demande de slot logique dont le « plugin » pointe vers la machine de l'attaquant. Sur Linux et Docker, il faut déjà pouvoir déposer un fichier sur le disque, ou tirer parti d'un montage NFS automatique.

La correction tient en deux lignes de C : rejeter tout nom de plugin qui contient un séparateur de répertoire. Ces deux lignes ont manqué pendant douze ans.

Source : Cyera Research, le détail du chemin d'attaque côté chargeur.

Du compte de sauvegarde au superutilisateur

Une fois le code chargé, il tourne dans la mémoire même de PostgreSQL, sans bac à sable et sans vérification : toute la sécurité du moteur s'arrête au niveau SQL. Le plugin bascule alors les drapeaux de privilèges du compte à true, directement dans la table interne qui définit les rôles, en sautant toutes les vérifications d'accès habituelles. Le compte devient superutilisateur de façon permanente, le changement survit aux redémarrages, et il se camoufle en simple ALTER ROLE, indistinguable d'une modification légitime.

Avec ces droits, l'attaquant lit toutes les tables de toutes les bases, exécute des commandes système, lit des fichiers sensibles comme les clés privées ou les hachages de mots de passe, et écrit partout où le processus postgres peut écrire. Cyera décrit aussi une porte dérobée à trois étages : réécriture du fichier d'authentification pour se connecter sans mot de passe, inscription du plugin dans la liste des bibliothèques préchargées pour survivre aux redémarrages, et réapplication automatique des droits superuser si un administrateur les révoque. Tu en corriges un, il en reste deux.

Source : Cyera Research, la démonstration du franchissement de la frontière SQL.

La même histoire que Redis, en plus gros

Cyera a aussi passé au crible les échantillons partagés publiquement : 114 plugins PostgreSQL malveillants déjà en circulation, chevaux de Troie, mineurs de cryptomonnaies et shells inversés. Toutes les versions depuis la 9.4 sont concernées, et la réplication logique est devenue de la plomberie standard dans les déploiements en production. La base équipe Netflix, Instagram, Spotify et Uber, selon Cyera, ainsi que les offres gérées d'AWS, d'Azure, de Google Cloud et de Supabase. Autant dire que le chemin d'attaque existe presque partout où PostgreSQL tourne.

La classe de faille n’est pas nouvelle non plus. Redis a vécu le même scénario avec RediShell en 2025, environ treize ans d’exposition sur près de 330 000 instances accessibles, et la campagne HeadCrab avait infecté plus de 1 200 serveurs pour miner de la cryptomonnaie. Même mécanique à chaque fois : un serveur qui charge des extensions sans vérifier leur nom. Et le mois ne s’arrête pas là côté auto-hébergement : on t’a parlé il y a deux jours d’une faille critique dans KVM, le module de virtualisation du noyau Linux, et de la faille Keycloak de la semaine passée qui permettait de reprendre des comptes. La leçon se répète : les composants techniques de service, ceux qu’on installe une fois et qu’on n’audite jamais, sont les portes de derrière préférées des attaquants.

Les gestes à faire ce soir

Rien d'exotique ici, juste une liste courte dans le bon ordre. Elle tient en un quart d'heure sur un serveur auto-hébergé classique.

• Mettre à jour PostgreSQL vers la 18.6, 17.11, 16.15, 15.19 ou 14.24 selon ta version. Sous Debian ou Ubuntu, un apt upgrade suivi d'un redémarrage du service suffit. Sous Docker, repars d'une image à jour : tes données restent dans le volume.
• Auditer les comptes de réplication avec la requête SELECT rolname, rolsuper, rolreplication, rolcanlogin FROM pg_roles WHERE rolreplication = true; puis retirer l'attribut REPLICATION de tout compte qui n'en a pas strictement besoin.
• Verrouiller pg_hba.conf : les comptes de réplication ne doivent se connecter que depuis des adresses IP précises, avec l'authentification scram-sha-256. Jamais de 0.0.0.0/0.
• Bloquer en sortie les ports SMB (445) et NFS (2049) depuis tes serveurs de base de données. Cela coupe les chemins d'attaque à distance sur Windows et sur les Linux avec montage NFS automatique.
• Surveiller les anomalies : un CREATE_REPLICATION_SLOT venu d'une adresse inhabituelle, ou un nom de plugin qui contient des slashes ou des points de traversée, sont des signaux d'alarme.

Le correctif existe depuis la mi-août, la recherche publique depuis le 1er septembre. Il ne manque plus que les mises à jour effectives. Et si tu ne retiens qu'une habitude de cette histoire, prends celle-ci : un compte technique créé une fois et oublié pendant dix ans, c'est exactement là que ça se passe.

Sources

Source : Cyera Research, la recherche PostGREShell complète, avec le détail de l'exploit, les 114 plugins trouvés et la chronologie de la divulgation.

Source : PostgreSQL, l'annonce officielle des mises à jour 18.6, 17.11, 16.15, 15.19, 14.24 et de la bêta 3 de la version 19.

Source : PostgreSQL, l'avis de sécurité officiel de la CVE-2026-6471.

Source : SecurityWeek, l'analyse de la faille et de son impact pour les organisations.

—

Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.