if ( !emtpy($headline_subheadline ) ) : ?>
La faille, passée inaperçue depuis 2014, pourrait permettre à des attaquants disposant d’un accès de réplication peu privilégié d’exécuter du code, d’obtenir les privilèges de superutilisateur de la base de données et d’établir un accès persistant.
endif; ?>
Une vulnérabilité critique dans PostgreSQL était restée cachée pendant plus d’une décennie, transformant potentiellement un compte de sauvegarde de routine en une voie menant à une compromission complète de la base de données et du serveur.
Le problème, baptisé PostGREShell par Cyera Research, existe dans la fonctionnalité de réplication de la base de données et pourrait permettre à un attaquant disposant d’un compte à faible privilège portant l’attribut REPLICATION de charger et d’exécuter du code arbitraire.
« La faille permet à un compte de « sauvegarde » à faible privilège de charger et d’exécuter du code arbitraire sur le serveur de base de données, permettant ainsi l’exécution de code à distance sur Windows, Linux et macOS », a déclaré Vladimir Tokarev, chercheur à Cyera, dans un article de blog. « Cette présence s’étend jusqu’au superutilisateur PostgreSQL complet avec accès persistant par porte dérobée, transformant un compte de réplication de routine en une compromission totale de la base de données et du serveur. »
La vulnérabilité, identifiée comme CVE-2026-6471, affecte les versions de PostgreSQL remontant à 9.4, publiées en 2014, et a été corrigée dans toutes les versions de PostgreSQL prises en charge, y compris les versions 18.6, 17.11, 16.15, 15.19 et 14.24, publiées le 13 août.
Bien que les installations de PostgreSQL sur Windows, Linux et macOS aient été affectées, les conditions nécessaires à l’exécution du code varient selon la plate-forme, a noté Tokarev.
Les protections existantes n’étaient pas suffisantes
Le problème vient de la gestion par PostgreSQL des plugins de sortie utilisés par la réplication logique. Ces plugins sont du code compilé que PostgreSQL charge pour formater les modifications de la base de données pour les systèmes et outils externes.
PostgreSQL dispose déjà de protections conçues pour empêcher les non-superutilisateurs de charger des bibliothèques arbitraires à partir d’emplacements dangereux du système de fichiers. Son mécanisme « check_restricted_library_name() » restreint l’endroit où ces utilisateurs peuvent charger des plugins, empêchant ainsi la traversée de chemin et les chemins absolus.
Mais, selon Cyera, le chemin du code de réplication n’a jamais appelé ce contrôle de sécurité.
Un attaquant capable de créer un emplacement de réplication logique pourrait fournir un nom de plugin spécialement conçu contenant des chemins de système de fichiers, des séquences de traversée ou, sous Windows, des chemins UNC. PostgreSQL transmettrait ensuite ce nom directement aux fonctions de chargement de bibliothèque du système d’exploitation.
Lorsque la bibliothèque malveillante était chargée, son code d’initialisation s’exécutait dans le processus du serveur PostgreSQL.
L’exécution de code qui en résulte est grave, d’autant plus que les comptes REPLICATION sont couramment utilisés comme plomberie opérationnelle pour les sauvegardes, les répliques, les pipelines de capture de données modifiées, les migrations et la surveillance.
Cyera a déclaré que les systèmes Windows sont particulièrement exposés car un attaquant pourrait héberger une DLL malveillante sur un serveur SMB distant et pointer PostgreSQL dessus, ne nécessitant aucun placement préalable du fichier malveillant sur le système cible.
Comptes de sauvegarde transformés en superutilisateurs
Le problème ne s’arrête pas à l’exécution du code.
Étant donné qu’un plugin de sortie s’exécute dans le processus du serveur PostgreSQL, Cyera a déclaré que le code malveillant peut fonctionner en dehors du modèle d’autorisation SQL normal. Un plugin malveillant pourrait manipuler les composants internes de PostgreSQL pour élever les privilèges de l’attaquant au rang de superutilisateur et modifier les données d’authentification internes.
Avec un accès superutilisateur, un attaquant pourrait accéder à toutes les bases de données et à leur contenu, y compris les données client, les secrets d’application et les informations d’identification stockées. Les superutilisateurs de PostgreSQL peuvent également interagir avec le système d’exploitation sous-jacent, permettant potentiellement aux attaquants d’exécuter des commandes, de lire des fichiers sensibles et d’écrire des données sur le serveur.
Cyera a démontré plusieurs mécanismes de persistance, notamment des modifications de la configuration de l’authentification PostgreSQL et l’utilisation de bibliothèques préchargées qui pourraient survivre aux redémarrages de la base de données. Tokarev a déclaré qu’un tel accès pourrait également être utilisé pour obtenir un accès plus approfondi à l’environnement d’une organisation.
La société a signalé le problème à l’équipe de sécurité de PostgreSQL en février, qui a examiné les résultats, attribué à la faille un identifiant CVE et publié des correctifs en août.
Même si la faille n’a pas atteint la note critique CVSS de 7,2, Cyera a exhorté ses clients à appliquer immédiatement le correctif, notant que les plugins PostgreSQL sont une cible populaire pour les attaquants. Sa chasse aux menaces VirusTotal a trouvé 114 plugins PostgreSQL malveillants dans la nature, y compris des chevaux de Troie, des mineurs de cryptomonnaie et des shells inversés, bien que la divulgation n’ait lié aucun de ces plugins à l’exploitation de CVE-2026-6471.
En dehors des correctifs, il a été recommandé aux utilisateurs d’auditer les comptes avec l’attribut REPLICATION, de restreindre l’accès à la réplication et de bloquer les connexions SMB et NFS sortantes inutiles à partir des serveurs de base de données.
