PgBouncer 1.26.1: fix CVE-2026-107350 (SCRAM bypass)

On October 14, 2026, the PgBouncer project released version 1.26.1, which fixes three flaws. The most serious, CVE-2026-107350, is an authentication bypass: a client that knows the password of one SCRAM user can log in as any other SCRAM user, including PgBouncer administrators and PostgreSQL superusers. The mechanism is a second startup message, the StartupMessage, processed during SCRAM authentication when the connection targets a non-existent database. According to Mend's description, the SCRAM exchange is still verified against the keys of the first user, while the session opens under the identity of the second. The changelog states that the attack requires SCRAM for both users.

The other two flaws are denial-of-service issues, triggerable without authentication but only under certain configuration options: CVE-2026-107349 and CVE-2026-107348. Mend gives CVE-2026-107350 a CVSS v4 score of 8.7. The score matters less than a practical question: which version runs on your machines, and who can reach port 6432?

The objection is fair: a PgBouncer listening only on a private address cannot be reached from the Internet. But the attack needs no brute force. It is enough to know the password of one valid SCRAM user and to reach the port. An application password lives in a .env file, a CI variable, a developer workstation, sometimes a log. A compromised application provides both the password and the network position. From there, the flaw turns a limited application account into an administration account, or even a superuser on the PostgreSQL server behind it.

The deciding criterion is therefore not "Internet or not" but two questions: who can open a connection to port 6432, and how many valid passwords are in circulation. A vulnerable version behind a strict firewall is a reduced risk, not a removed one.

At the time of writing, the Debian security tracker lists bookworm (1.18.0-1+deb12u1) and trixie (1.24.1-1+deb13u2) as vulnerable to CVE-2026-107350, with only forky and sid carrying the fixed package 1.26.1-1. Until Debian publishes a fix for your release, apt upgrade alone does not protect you. Recheck the tracker on the day you act: the state may have changed.

Three routes exist. The first: the PGDG repository, apt.postgresql.org for Debian and Ubuntu, yum.postgresql.org for RHEL and derivatives, which the PgBouncer download page describes as builds that may be newer than those in distributions. The second: an up-to-date Docker image or tag, knowing that the project mentions no official image, so you are using a third-party one. The third: build the source archive of version 1.26.1. Before switching, confirm with apt-cache policy pgbouncer or dnf info pgbouncer that the repository really offers the fixed version.

For CVE-2026-107350, the announcement gives no configuration workaround: the upgrade is the only real answer. You can, however, reduce who gets to try. Limit port 6432 to the application network:
sudo ufw allow from <app_subnet> to any port 6432 proto tcp
sudo ufw status numbered
sudo ufw delete <n>
Here <n> is the number of a broader rule already present, for example one opening port 6432 to everyone, which you delete once the restricted rule is in place. On RHEL and derivatives, the same rule is set with firewalld. If listen_addr is *, replace it with the server's private address. Then audit the auth_file file: remove unused accounts, rotate passwords that have circulated, and shrink admin_users to the bare minimum.

For the two denial-of-service flaws, what follows is our reading of the changelog's conditions, not a vendor instruction. CVE-2026-107349 assumes ignore_startup_parameters is non-empty and lacks options: adding options to the list removes the condition; emptying the setting also removes it, but may cause clients that send startup parameters to be rejected (see the search_path case above). CVE-2026-107348 assumes a max_packet_size above 2147483648: keeping the default value, 2147483647, rules it out.

By default PgBouncer logs successful connections and disconnections, with their reason, thanks to log_connections and log_disconnections. Read the period that follows the publication of the fixes, and further back if your logs allow:
sudo journalctl -u pgbouncer --since "2026-10-14"
Look for attempts against database names that do not exist in your [databases] section, then a session opened just afterwards under a different user name from the same address. On the console, these two commands show the current state:
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;"
On the PostgreSQL side, list the roles and their recent changes with psql -c "\du".

We do not have an exact signature of this attack in the logs, and we do not invent one. An absence of traces does not prove an absence of intrusion, especially if log_connections was turned off or logs have rotated. If you have serious doubts, change the passwords of all SCRAM accounts and of the privileged roles on the PostgreSQL server.

A successful upgrade is proven, not assumed. For each server, record in a table the machine, the installation method, the version before and after, the firewall rule applied, and the date of the check. Verify that SHOW VERSION reports 1.26.1, that the process restarted after the installation, and that port 6432 is reachable only from the intended network. Also confirm that your two denial-of-service settings respect the conditions described above, or that they have become moot.

Finally, do not count on automatic updates: an unfixed distribution package does not update itself, and neither does a pinned Docker image. Add a reminder to recheck your distribution's security tracker, then switch to its package once it is fixed, or keep the PGDG repository deliberately.

Fixing PgBouncer takes three kinds of access: choosing the installed version, setting the firewall on port 6432 and reading the logs. On a VPS Cloud with root access, these three levers are yours, without depending on a shared host's schedule. The guides linked below this article detail the firewall and the PostgreSQL setup. This guide is provided without support: the upgrade remains your responsibility. If you would rather delegate server administration, the VPS administration option exists, to be assessed against your needs.

Announcement of version 1.26.1: https://www.postgresql.org/about/news/pgbouncer-1261-released-fixes-three-cves-3403/

PgBouncer changelog: https://www.pgbouncer.org/changelog.html

PgBouncer downloads: https://www.pgbouncer.org/downloads/

Usage and admin console: https://www.pgbouncer.org/usage.html

PgBouncer configuration: https://www.pgbouncer.org/config.html

Debian security tracker for CVE-2026-107350: https://security-tracker.debian.org/tracker/CVE-2026-107350

Mend entry for CVE-2026-107350: https://www.mend.io/vulnerability-database/CVE-2026-107350/

PostgreSQL apt repository: https://wiki.postgresql.org/wiki/Apt

PostgreSQL yum repository: https://yum.postgresql.org/

Docker and firewalls: https://docs.docker.com/engine/network/packet-filtering-firewalls/