Un compte Postgres peut exécuter du code. Corrigez-le.

Postgres a publié un correctif le 13 août pour un bug présent dans le code depuis 2014. CVE-2026-6471 permet à tout compte disposant de l'attribut REPLICATION — le type de compte à faibles privilèges qu'utilise votre outil de sauvegarde ou votre réplique en lecture — de charger une bibliothèque partagée arbitraire dans le processus de base de données et d'exécuter du code en tant qu'utilisateur du système d'exploitation propriétaire de Postgres. L'avis officiel le décrit clairement : le décodage logique peut effectuer un dlopen sur un fichier arbitraire, choisi par le client de réplication, sans aucune vérification d'autorisation. Cyera Research, qui l'a signalé avec Yu Kunpeng, l'appelle PostGREShell.

Les mécanismes valent la peine d'être compris, car ils expliquent la correction. Quand un client de réplication ouvre un slot de décodage logique, il nomme un plugin de sortie, et Postgres charge ce plugin en tant que code compilé dans son propre processus. Pour un LOAD SQL ordinaire, Postgres restreint les non-superutilisateurs à un répertoire de plugins contrôlé. Le chemin de réplication contournait cette vérification, si bien que le nom du plugin pouvait être n'importe quel chemin sur le disque. Sous Windows, c'est pire : le chargeur accepte un chemin UNC, permettant à un attaquant de le pointer vers une DLL sur son propre partage SMB sans jamais déposer de fichier sur la cible.

Voici ce qui s'est perdu dans certains articles. Le CVSS officiel est de 7,2 — élevé mais pas critique — et la raison est clairement dans le vecteur : PR:H. Il faut un compte qui dispose déjà de REPLICATION. Il ne s'agit pas d'une faille non authentifiée exposée sur Internet. Alors pourquoi s'en préoccuper ? Parce que dans les systèmes réels, ces comptes sont partout et personne ne les considère comme dangereux. Chaque réplique en streaming, chaque tâche de sauvegarde, chaque pipeline de capture de données de changement, chaque agent de surveillance qui suit le journal write-ahead s'exécute avec un rôle REPLICATION. Ce sont des tuyaux opérationnels, et les tuyaux ont tendance à porter des identifiants faibles, longue durée de vie et largement copiés.

Lors de nos audits de sécurité cloud, nous constatons régulièrement le même schéma : un utilisateur de réplication dont le mot de passe se trouve dans trois fichiers env et une variable Terraform, réutilisé entre staging et prod, accessible depuis plus de parties du réseau que prévu. En soi, cela ressemble à une découverte de faible gravité, un compte de service trop privilégié. Ce CVE transforme exactement ce compte en exécution de code à distance sur l'hôte de base de données. La leçon ne concerne pas vraiment Postgres. C'est que les identifiants de service « à faibles privilèges » le restent uniquement jusqu'à ce que quelqu'un trouve un primitif qui les élève.

La correction est un nouveau paramètre serveur, output_plugin_libraries, ajouté par Jacob Champion. C'est une liste blanche. Par défaut, elle n'autorise que les deux plugins fournis avec Postgres, pgoutput et test_decoding, de sorte qu'un client de réplication ne peut plus nommer une bibliothèque arbitraire. Si vous utilisez un décodeur tiers comme decoderbufs (utilisateurs de Debezium, cela vous concerne), vous devez le rajouter explicitement après la mise à niveau, sinon la réplication logique s'interrompt. À partir de la version 17, pg_upgrade --check refuse de continuer si la liste blanche du nouveau cluster ne couvre pas les plugins utilisés par vos slots existants. C'est un garde-fou utile et un piège de migration à anticiper.

Ce qu'il faut faire cette semaine

Mettez à jour vers 18.6, 17.11, 16.15, 15.19 ou 14.24. Les branches plus anciennes sont en fin de vie et ne recevront pas ce correctif ; si vous êtes sur la version 13 ou antérieure, considérez cela comme une raison supplémentaire de migrer.
Auditez qui détient REPLICATION. Faites un vrai inventaire, pas une estimation. Tout compte humain avec cet attribut devrait probablement le perdre, et chaque compte de service qui le conserve a besoin d'un secret unique et renouvelé.
Bloquez les connexions SMB et NFS sortantes de vos hôtes de base de données. Le chemin de DLL distante sous Windows dépend de la base de données atteignant le partage de fichiers d'un attaquant. Votre serveur Postgres n'a aucune raison d'ouvrir des connexions SMB sortantes, bloquez-les donc au pare-feu.
Si vous configurez output_plugin_libraries manuellement, listez exactement les décodeurs que vous utilisez et rien d'autre.

Une chose vaut la peine d'être vérifiée, une autre vaut la peine d'être ignorée. La chasse aux menaces de Cyera a révélé 114 plugins Postgres malveillants sur VirusTotal : chevaux de Troie, mineurs, reverse shells. C'est un rappel que le chargement de plugins est une cible populaire, mais aucun de ces échantillons n'a été lié à l'exploitation de ce CVE spécifique — ne le lisez donc pas comme la preuve que vous avez été touché. À ignorer : le cadrage « douze ans sans correctif ». La faille était réelle depuis longtemps, mais l'exploiter nécessite toujours un compte REPLICATION ; si vous les avez gardés verrouillés, vous n'étiez jamais aussi exposé que le titre le suggère.

Nous passons beaucoup de temps à la jonction entre le durcissement des bases de données et la politique réseau, des stacks PHP et Docker sur AWS aux règles Cloudflare et pare-feu qui décident de ce qu'une machine compromise peut atteindre. Le schéma qui piège les équipes est presque toujours un compte interne trop approuvé combiné à un trafic sortant que personne n'a verrouillé. Si un identifiant de réplication oublié avec un mot de passe partagé ressemble à quelque chose qui se trouve dans votre infrastructure, parlons-en.