veilletech.fr
5 sept. Feed du jour
#02 SÉCURITÉ Faille

Postgres : la mise à jour casse wal2json

La faille a douze ans. Le correctif, lui, casse ce soir.

PostgreSQL corrige CVE-2026-6471 (CVSS 7.2), baptisée PostGREShell par Cyera : un compte REPLICATION peut charger n'importe quelle bibliothèque comme plugin de décodage logique et exécuter du code comme utilisateur postgres. La faille date de la version 9.4 (2014). Le correctif introduit une liste blanche output_plugin_libraries limitée par défaut à pgoutput et test_decoding — toute installation utilisant wal2json ou decoderbufs verra le décodage logique refusé après la mise à jour.

3 min de lectureavancévidéo 1:21
Partager
Sommaire3 sections
  1. Ce qui se passe
  2. Le piège : le correctif casse des installations
  3. Comment s'y prendre

Ce qui se passe

CVE-2026-6471 (CVSS 7.2) permet à un compte portant l'attribut REPLICATION d'exécuter du code arbitraire en tant qu'utilisateur système du serveur, en général postgres. Elle est présente depuis l'introduction du décodage logique dans PostgreSQL 9.4, en 2014.

Le correctif a été livré le 13 août 2026. Les versions antérieures à 18.6, 17.11, 16.15, 15.19 et 14.24 sont vulnérables. Le projet crédite Vladimir Tokarev et Yu Kunpeng ; Tokarev l'a détaillée le 1er septembre pour Cyera Research, qui la nomme PostGREShell.

Le mécanisme est direct : le nom de plugin fourni dans une commande CREATE_REPLICATION_SLOT arrive tel quel à la fonction qui charge la bibliothèque. La restriction de chemin qui confine les non-superusers à un répertoire administré n'est jamais appelée sur le chemin de réplication, et l'analyseur du protocole accepte presque tout caractère entre guillemets doubles — séparateurs de chemin et ../ compris.

L'exploitation demande aussi un serveur en wal_level = logical. Sous Windows, la bibliothèque peut être récupérée par SMB depuis une machine de l'attaquant, sans rien écrire sur la cible ; sous Linux et macOS, il faut l'automontage NFS ou une écriture existante sur le disque.

Le piège : le correctif casse des installations

C'est l'information à retenir avant de lancer la mise à jour. Le correctif ajoute un paramètre serveur, output_plugin_libraries, qui liste les bibliothèques utilisables comme plugin de sortie. Sa valeur par défaut :

INI
output_plugin_libraries = 'pgoutput, test_decoding'

Toute installation reposant sur un autre plugin — wal2json, decoderbufs — verra le décodage logique refusé après la mise à jour, jusqu'à ce qu'un administrateur ajoute la bibliothèque à cette liste. L'échec apparaît dans le journal sous la forme :

TEXT
ERROR: library "..." may not be used as an output plugin

Jacob Champion, auteur du correctif, explique le choix : appliquer la restriction LOAD habituelle aurait rétroactivement imposé d'installer tous les plugins tiers sous $libdir/plugins. L'avis Debian mentionne le problème ; l'avis Ubuntu USN-8653-1 (22.04, 24.04 et 26.04 LTS, livré le 20 août) ne dit rien du paramètre et demande seulement un redémarrage.

Comment s'y prendre

  1. Avant la mise à jour, inventorier les plugins réellement utilisés :
    SQL
    SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;
  2. Passer en 18.6, 17.11, 16.15, 15.19 ou 14.24 (ou l'équivalent distribution).
  3. Ajouter les plugins non standard à output_plugin_libraries, puis recharger la configuration — aucun redémarrage n'est nécessaire :
    SQL
    SELECT pg_reload_conf();
  4. En migration depuis la 17 ou plus, renseigner le paramètre du nouveau cluster avant pg_upgrade --check, sinon la vérification échoue.

Deux réserves. pg_createsubscriber crée encore ses slots avec pgoutput sans consulter le paramètre : le --dry-run passe et la conversion échoue ensuite — un correctif était en revue au 4 septembre. Et PostgreSQL 14 cesse d'être maintenu le 12 novembre 2026.

En attendant de pouvoir mettre à jour, Cyera conseille de retirer l'attribut REPLICATION aux comptes qui n'en ont pas besoin, de restreindre les entrées de réplication dans pg_hba.conf, et de bloquer le trafic sortant SMB (445) et NFS (2049) depuis les serveurs de base de données.

Source : The Hacker News