PostGREShell : une faille dans PostgreSQL a transformé des comptes de sauvegarde en portes dérobées

**Une faille présente depuis 2014 dans la réplication de PostgreSQL pouvait transformer un compte de sauvegarde ordinaire en exécution de code, accès superutilisateur et une porte dérobée persistante. Le problème a déjà été corrigé dans les branches affectées, mais l'ampleur de son utilisation oblige à revoir les identifiants, les configurations et les connexions réseau.

• La vulnérabilité CVE-2026-6471 affecte les versions antérieures à PostgreSQL 18.5, 17.11, 16.15, 15.19 et 14.24, selon les avis de sécurité disponibles.
• Un compte avec l'attribut REPLICATION pouvait charger une bibliothèque malveillante et exécuter du code dans le processus de la base de données.
• Cyera Research a trouvé 114 compléments malveillants de PostgreSQL en circulation, bien qu'ils ne les aient pas liés à l'exploitation de cette faille.

Une vulnérabilité qui est restée pendant plus d'une décennie dans PostgreSQL pouvait transformer un compte de sauvegarde ordinaire en un moyen de prendre le contrôle de la base de données et du serveur. Le défaut, identifié comme CVE-2026-6471 et baptisé PostGREShell par Cyera Research, affecte la fonctionnalité de réplication logique et permet de charger du code arbitraire avec un compte ayant l'attribut REPLICATION, sans exiger de privilèges de superutilisateur.

L'ampleur potentielle est large car PostgreSQL soutient des systèmes de sauvegarde, des répliques, des migrations, la capture de données modifiées et des analyses en temps réel pour des milliers d'organisations. La recherche a indiqué que plus de 39 000 entreprises vérifiées utilisent la base de données en production, y compris Netflix, Instagram, Spotify et Uber, ainsi que des services comme AWS RDS, Azure Database, Google Cloud SQL, Supabase et Neon.

Une faille cachée dans la réplication

Dans une installation de production, la base de données principale travaille généralement avec une ou plusieurs répliques qui maintiennent des copies synchronisées. Cette architecture permet de maintenir des sauvegardes, une récupération après sinistre et un scalabilité des lectures, de sorte que les comptes de réplication sont souvent considérés comme des composants opérationnels à faible risque, bien qu'ils maintiennent une connexion directe avec des fonctions sensibles du serveur.

PostgreSQL utilise un protocole spécifique pour synchroniser ces systèmes et exige l'attribut REPLICATION pour initier la réplication en streaming. Les mêmes identifiants apparaissent dans les outils de sauvegarde, les serveurs en attente, les canaux de capture de changements et les systèmes de surveillance qui lisent le journal d'écriture anticipée, de sorte qu'un compte apparemment limité peut être présent dans de nombreux environnements critiques.

Le problème se trouvait dans les compléments de sortie qui formatent les changements de la réplication logique. Lorsqu'un client crée un espace de réplication, il indique également le nom du complément, qui peut être une bibliothèque compilée avec des extensions telles que .so, .dll ou .dylib et que PostgreSQL charge dans le processus principal de la base de données.

Le système avait déjà une défense appelée check_restricted_library_name(), conçue pour empêcher que des utilisateurs non superutilisateurs chargent des bibliothèques depuis des chemins absolus ou par des techniques de traversée de répertoires. Cependant, le chemin utilisé par la réplication n'invoquait pas cette vérification, de sorte que le nom du complément arrivait directement au chargeur du système d'exploitation sans la validation appliquée à la commande SQL LOAD.

D'une bibliothèque malveillante au contrôle du serveur

Le parseur du protocole de réplication acceptait de nombreux caractères dans le nom du complément, y compris des barres, des points, des séquences comme ../ et des chemins UNC de Windows. Un attaquant qui parvenait à livrer un nom spécialement manipulé pouvait amener PostgreSQL à demander une bibliothèque située dans un chemin arbitraire, activant des fonctions telles que dlopen() sur Linux et macOS ou LoadLibrary() sur Windows.

Le chargement de la bibliothèque exécute immédiatement sa fonction d'initialisation dans le processus de PostgreSQL. Comme le plugin fonctionne dans le même espace d'adresses et qu'il n'existe pas d'isolation du code C, les protections normales du modèle de permissions SQL ne sont plus suffisantes une fois que la bibliothèque malveillante commence à s'exécuter.

Les conditions d'exploitation varient selon le système d'exploitation. Sous Windows, un compte avec REPLICATION, un serveur configuré avec wal_level = logical et un accès réseau au port SMB 445 pouvaient suffire pour que PostgreSQL charge une DLL hébergée sur un serveur distant via un chemin UNC, sans que l'attaquant ait besoin de copier au préalable le fichier sur la machine cible.

Sous Linux et macOS, l'enquête a décrit des scénarios basés sur des montages NFS automatiques, en particulier lorsque autofs était actif, ainsi que des cas où l'attaquant pouvait déjà écrire une bibliothèque sur le disque. Dans des environnements standards, des conteneurs Docker ou des clusters Kubernetes, l'exploitation nécessitait ce canal supplémentaire pour placer localement le fichier malveillant, tandis que Windows offrait un chemin complètement distant dans les conditions mentionnées.

L'escalade vers le superutilisateur et la persistance

L'accès initial en tant qu'utilisateur du système postgres ne constituait pas la fin de l'attaque, selon l'analyse divulguée. Le code chargé pouvait manipuler des structures internes de PostgreSQL, devenir le superutilisateur de la session et modifier directement pg_authid, le catalogue qui définit les privilèges des rôles.

En opérant en dehors de l'exécuteur SQL, cette modification ne traversait pas les vérifications habituelles des listes de contrôle d'accès ni les règles de permissions. L'attaquant pouvait activer les indicateurs de superutilisateur et ajouter un mécanisme pour que les vérifications ultérieures retournent une réponse favorable, tandis que le changement était enregistré de manière similaire à une altération normale du catalogue.

Avec des privilèges de superutilisateur, l'attaquant pouvait lire des tables de toutes les bases de données, y compris des données clients, des enregistrements financiers, des secrets d'applications et des identifiants stockés. Il pouvait également utiliser des fonctions comme COPY ... TO PROGRAM pour exécuter des commandes, lire des fichiers sensibles via pg_read_file() ou écrire dans des emplacements accessibles pour l'utilisateur du système avec des outils comme lo_export().

L'enquête a également décrit plusieurs mécanismes de persistance qui pouvaient survivre aux redémarrages et compliquer le nettoyage. Parmi eux figuraient des modifications dans pg_hba.conf pour permettre des connexions sans mot de passe, des copies du plugin dans un chemin stable et son enregistrement dans shared_preload_libraries, ainsi que la réapplication du privilège de superutilisateur si un administrateur tentait de le révoquer.

Correction, portée et mesures urgentes

L'équipe de sécurité de PostgreSQL a reçu le rapport en février 2026 et a confirmé la vulnérabilité le 27 février, avant de coordonner une correction pour une mise à jour mineure. CSO Online a rapporté que les correctifs ont été publiés le 13 août pour les versions 18.6, 17.11, 16.15, 15.19 et 14.24. Les avis de sécurité identifient comme affectées les versions antérieures à ces révisions, tandis que la faille remonte à des branches qui ont commencé avec PostgreSQL 9.4, lancée en 2014.

Bien que CVE-2026-6471 ait reçu un score CVSS de 7,2, l'impact décrit combine exécution de code, élévation de privilèges, accès à des informations et persistance. La gravité pratique dépend de l'exposition des comptes de réplication, de la configuration réseau et de la plateforme, mais la présence de ces identifiants dans des opérations essentielles rend insuffisante la confiance uniquement dans le fait qu'il ne s'agit pas de comptes administrateurs.

La révision des menaces de Cyera Research sur VirusTotal a identifié 114 plugins malveillants de PostgreSQL, y compris des chevaux de Troie, des mineurs de cryptomonnaies et des shells inverses. L'entreprise n'a pas lié ces fichiers à l'exploitation de la vulnérabilité CVE-2026-6471, de sorte que la découverte démontre que les plugins attirent déjà une activité malveillante, mais ne confirme pas que cette vulnérabilité a été utilisée par ces exemplaires.

Les administrateurs doivent d'abord installer la mise à jour correspondante et auditer tous les comptes avec l'attribut REPLICATION. Il est également conseillé de supprimer ce privilège lorsqu'il n'est pas strictement nécessaire, de limiter les connexions dans pg_hba.conf à des adresses connues et d'éviter les règles de réplication ouvertes à tout Internet, comme 0.0.0.0/0.

Le durcissement doit inclure le blocage des connexions sortantes inutiles vers SMB sur le port 445 et NFS sur le port 2049 depuis les serveurs de bases de données, en plus de désactiver autofs lorsqu'il n'est pas requis. Les équipes de sécurité devraient rechercher des commandes CREATE_REPLICATION_SLOT provenant d'adresses inattendues, des noms de plugins avec des barres ou des séquences de parcours et des espaces de réplication inhabituels.

Le cas expose également un problème récurrent dans les systèmes extensibles : le chemin de chargement des plugins peut être séparé du modèle de sécurité qui protège les opérations principales. PostgreSQL avait protégé une voie de chargement, mais le chemin de réplication n'a pas connecté cette défense avec le même contrôle, laissant pendant des années une entrée secondaire qui pouvait transformer une infrastructure routinière en un compromis total.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.