PgBouncer 1.26.1 fixes an auth bypass: one SCRAM password can log in as any user

The release is dated 14 October 2026. If PgBouncer sits in front of your Postgres, here is the sentence to read twice. CVE-2026-107350 allows, in the project’s words, “a client that knows the password of one SCRAM user to log in as any other SCRAM user, including admins and backend superusers”.

That turns a low-value credential into a high-value one. A read-only reporting user, a leaked CI password, an old contractor login: any of them becomes a way in as someone else, provided the pooler is on a version before 1.26.1 and uses SCRAM authentication.

What the notes say, and what they leave out

The release notes give the root cause in one clause: a second StartupMessage processed during SCRAM authentication when connecting to a non-existent database. I will not describe the exploit beyond that. It is not in the notes, and I have not tested it.

Two other CVEs ship in the same release, both denial of service by an infinite loop that an unauthenticated client can trigger. CVE-2026-107349 needs ignore_startup_parameters to be set without options in it. CVE-2026-107348 needs max_packet_size raised above the default. If you run defaults, neither applies. If you copied a tuning guide from a blog, check.

Things the notes do not provide: CVSS scores, a list of the earliest affected versions, or a workaround. Some summaries online quote scores and version ranges. I could not find them in the primary notes, so I have left them out.

A ten-minute check

-- connect to the pgbouncer admin console (the special "pgbouncer" database)
SHOW VERSION;
SHOW CONFIG;   -- look for auth_type, ignore_startup_parameters, max_packet_size

Then read your pgbouncer.ini. These are the lines to look at:

[pgbouncer]
auth_type = scram-sha-256        ; the bypass is about SCRAM users
ignore_startup_parameters = extra_float_digits   ; DoS if set and "options" is missing
;max_packet_size = 2147483647    ; only a problem if raised above the default

I would not “fix” the second line by adding options to the ignore list as a shortcut. That changes what clients can set, and the notes only describe upgrading. Patch first, tune afterwards.

Who should worry most

• Anyone whose PgBouncer is reachable from networks you do not fully control, including a shared VPC or a bastion.
• Setups where application users hold superuser or admin-level roles in the backend. Fix that separately; this bug just makes it worse.
• Teams with many low-privilege SCRAM credentials spread across services and CI.

My position: patch this one now. It is a small upgrade with a clear fix, and an auth bypass in the component that sits in front of your data is exactly the kind of bug you do not want to carry into a quiet weekend. Then spend ten minutes asking why any pooled application user can become an admin at all.

The one change that is not a security fix

The release notes list a single non-security change, and it matters if you upgrade without reading further. In 1.26.1, ignore_startup_parameters now takes precedence over tracked parameters. If your clients rely on PgBouncer ignoring search_path the way 1.25 did, the notes say setting ignore_startup_parameters = search_path restores that behaviour.

[pgbouncer]
; 1.26.1: ignore_startup_parameters wins over tracked parameters.
; To keep the 1.25 behaviour of ignoring search_path (from the release notes):
ignore_startup_parameters = search_path

I have not run this against 1.26.1. It is the notes’ own example, and it is why I would upgrade a staging pooler first and run one real application against it before the production one.

What the page does not contain

• No credit to a reporter or fixer. The notes name nobody.
• No upgrade steps beyond the parameter change above. The notes point to the project changelog for the full list of changes.
• The tarball is published with a SHA-256 checksum file next to it. Verify the download against that file, and if you use a distribution package, check when your distribution ships 1.26.1 instead of assuming it already has.

All three CVEs are fixed in the same release, so there is nothing to choose between. The order of urgency is still not equal: the bypass lets one stolen password become another user’s access, while the two loops need specific settings (ignore_startup_parameters without options, or a raised max_packet_size) before they can be reached.

Sources & Credits

• PgBouncer project, “PgBouncer 1.26.1” release notes, October 2026: pgbouncer.org

The checks, response plan and graphics are our own work. Vulnerability details come only from the project’s release notes; none of the bugs was reproduced here. Last verified 2026-10-30. Spotted a mistake? Tell us and we will correct it here with the date.