PgBouncer 1.26.1 : corriger CVE-2026-107350 (SCRAM)

Le 14 octobre 2026, le projet PgBouncer a publié la version 1.26.1, qui corrige trois failles. La plus sérieuse, CVE-2026-107350, est un contournement d'authentification : un client qui connaît le mot de passe d'un utilisateur SCRAM peut se connecter comme n'importe quel autre utilisateur SCRAM, y compris les administrateurs de PgBouncer et les superutilisateurs de PostgreSQL. Le mécanisme tient à un deuxième message de démarrage, le StartupMessage, traité pendant l'authentification SCRAM lorsque la connexion vise une base inexistante. D'après la description de Mend, l'échange SCRAM reste vérifié avec les clés du premier utilisateur, tandis que la session s'ouvre sous l'identité du second. Le changelog précise que l'attaque exige SCRAM pour les deux utilisateurs.

Les deux autres failles sont des dénis de service, déclenchables sans authentification, mais seulement sous certaines options de configuration : CVE-2026-107349 et CVE-2026-107348. Mend attribue à CVE-2026-107350 un score CVSS v4 de 8,7. Le score compte moins qu'une question pratique : quelle version tourne chez vous, et qui peut atteindre le port 6432 ?

L'objection est légitime : un PgBouncer qui n'écoute que sur une adresse privée n'est pas joignable depuis Internet. Mais l'attaque ne demande pas de force brute. Il suffit de connaître le mot de passe d'un seul utilisateur SCRAM valide, et de pouvoir joindre le port. Or le mot de passe d'une application vit dans un fichier .env, une variable de CI, un poste de développement, parfois un journal. Une application compromise fournit à la fois le mot de passe et la position réseau. Depuis cette position, la faille transforme un compte applicatif limité en compte d'administration, voire en superutilisateur du serveur PostgreSQL derrière.

Le critère qui tranche n'est donc pas « Internet ou pas Internet », mais deux questions : qui peut ouvrir une connexion vers le port 6432, et combien de mots de passe valides circulent. Une version vulnérable derrière un pare-feu strict est un risque réduit, pas supprimé.

Au jour de la rédaction, le suivi de sécurité Debian liste bookworm (1.18.0-1+deb12u1) et trixie (1.24.1-1+deb13u2) comme vulnérables à CVE-2026-107350, seuls forky et sid disposant du paquet corrigé 1.26.1-1. Tant que Debian n'a pas publié de correctif pour votre version, apt upgrade seul ne protège donc pas. Revérifiez le suivi le jour où vous agissez : l'état peut avoir changé.

Trois voies existent. La première : le dépôt PGDG, apt.postgresql.org pour Debian et Ubuntu, yum.postgresql.org pour RHEL et dérivés, que la page de téléchargement de PgBouncer présente comme des constructions parfois plus récentes que celles des distributions. La deuxième : une image Docker ou un tag à jour, sachant que le projet ne mentionne aucune image officielle et que vous utilisez donc une image tierce. La troisième : compiler l'archive des sources de la version 1.26.1. Avant de basculer, confirmez par apt-cache policy pgbouncer ou dnf info pgbouncer que le dépôt propose bien la version corrigée.

Pour CVE-2026-107350, l'annonce ne donne aucune parade de configuration : la mise à jour est la seule vraie réponse. Vous pouvez en revanche réduire qui tente sa chance. Limitez le port 6432 au réseau applicatif :
sudo ufw allow from <app_subnet> to any port 6432 proto tcp
sudo ufw status numbered
sudo ufw delete <n>
Ici <n> est le numéro d'une règle plus large déjà présente, par exemple une ouverture du port 6432 à tous, que l'on supprime une fois la règle restreinte posée. Sur RHEL et dérivés, la même règle se pose avec firewalld. Si listen_addr vaut *, remplacez-le par l'adresse privée du serveur. Auditez ensuite le fichier auth_file : retirez les comptes inutilisés, faites tourner les mots de passe qui ont circulé, et réduisez admin_users au strict nécessaire.

Pour les deux dénis de service, voici notre lecture des conditions du changelog, pas une consigne de l'éditeur. CVE-2026-107349 suppose ignore_startup_parameters non vide et sans options : ajouter options à la liste lève la condition ; vider le paramètre la lève aussi, mais peut faire rejeter les clients qui envoient des paramètres de démarrage (voir le cas de search_path ci-dessus). CVE-2026-107348 suppose un max_packet_size supérieur à 2147483648 : garder la valeur par défaut, 2147483647, l'écarte.

PgBouncer journalise par défaut les connexions réussies et les déconnexions, avec leur motif, grâce à log_connections et log_disconnections. Lisez la période qui suit la publication des correctifs, et au-delà si vos journaux le permettent :
sudo journalctl -u pgbouncer --since "2026-10-14"
Cherchez des tentatives vers des noms de base qui n'existent pas dans votre section [databases], puis une session ouverte juste après sous un autre nom d'utilisateur depuis la même adresse. Sur la console, ces deux commandes montrent l'état courant :
psql -h 127.0.0.1 -p 6432 -U <admin_user> pgbouncer -c "SHOW DATABASES;"
psql -h 127.0.0.1 -p 6432 -U <admin_user> pgbouncer -c "SHOW CLIENTS;"
Côté PostgreSQL, listez les rôles et leurs changements récents avec psql -c "\du".

Nous n'avons pas de signature exacte de cette attaque dans les journaux, et nous n'en inventons pas. Une absence de trace ne prouve pas l'absence d'intrusion, surtout si log_connections était coupé ou si les journaux ont tourné. En cas de doute sérieux, changez les mots de passe de tous les comptes SCRAM et des rôles privilégiés du serveur PostgreSQL.

Une mise à jour réussie se prouve, elle ne se suppose pas. Pour chaque serveur, consignez dans un tableau la machine, le mode d'installation, la version avant et après, la règle de pare-feu posée, et la date du contrôle. Vérifiez que SHOW VERSION annonce 1.26.1, que le processus a redémarré après l'installation, et que le port 6432 n'est joignable que depuis le réseau prévu. Confirmez aussi que vos deux réglages de déni de service respectent les conditions décrites plus haut, ou qu'ils sont devenus sans objet.

Enfin, ne comptez pas sur les mises à jour automatiques : un paquet de distribution non corrigé ne se met pas à jour tout seul, et une image Docker épinglée non plus. Ajoutez un rappel pour revérifier le suivi de sécurité de votre distribution, puis basculez sur son paquet quand il sera corrigé, ou gardez le dépôt PGDG de façon délibérée.

Corriger PgBouncer demande trois accès : choisir la version installée, poser le pare-feu du port 6432 et lire les journaux. Sur un VPS Cloud avec accès root, ces trois leviers sont les vôtres, sans dépendre du calendrier d'un hébergeur mutualisé. Les guides liés sous cet article détaillent le pare-feu et la mise en place de PostgreSQL. Ce guide est fourni sans prise en charge : la mise à jour reste à votre charge. Si vous préférez déléguer l'administration du serveur, l'option d'administration VPS existe, à examiner selon votre besoin.

Annonce de la version 1.26.1 : https://www.postgresql.org/about/news/pgbouncer-1261-released-fixes-three-cves-3403/

Journal des modifications de PgBouncer : https://www.pgbouncer.org/changelog.html

Téléchargements de PgBouncer : https://www.pgbouncer.org/downloads/

Utilisation et console d'administration : https://www.pgbouncer.org/usage.html

Configuration de PgBouncer : https://www.pgbouncer.org/config.html

Suivi de sécurité Debian pour CVE-2026-107350 : https://security-tracker.debian.org/tracker/CVE-2026-107350

Fiche Mend de CVE-2026-107350 : https://www.mend.io/vulnerability-database/CVE-2026-107350/

Dépôt apt de PostgreSQL : https://wiki.postgresql.org/wiki/Apt

Dépôt yum de PostgreSQL : https://yum.postgresql.org/

Docker et pare-feu : https://docs.docker.com/engine/network/packet-filtering-firewalls/