PgBouncer 1.25.2 shipped on May 8 with four new CVEs. The one you actually need to care about is CVE-2026-6664: an integer overflow in the SCRAM authentication packet parser. It is reachable before authentication. A malformed packet crashes the process.
Anything that can open a TCP connection to PgBouncer can take PgBouncer down.
The Other Three
The rest are not nothing, but they are not the day’s emergency.
CVE-2026-6665 is a stack overflow triggerable by a malicious backend sending an oversized SCRAM server-final-message nonce. This matters less, because you presumably trust your own Postgres. If you do not trust your own Postgres, you have a different problem.
CVE-2026-6666 is a null dereference when a backend sends an error response with a missing SQLSTATE field. Same posture — malicious or broken backend required.
CVE-2026-6667 is a missing authorization check on the KILL_CLIENT admin command. Bad in a multi-tenant control-plane situation. Unlikely to be how your day gets ruined this week.
The release also folds in CVE-2025-12819, the SQL-execution-during-StartupMessage search_path issue from last year, in case you somehow had not picked that one up yet. If your patch cadence on PgBouncer is “when something breaks,” now you know.
Why 6664 Deserves Its Own Paragraph
“PgBouncer is on the internet” is more common than people admit. Not deliberately — almost no one wakes up and decides to expose their connection pooler to the open internet. But security groups drift. Load balancer terminations leak. Internal-only assumptions stop being true after a network reorganization. The result is the same: a port 6432 listener reachable from places it should not be.
If you have any PgBouncer instance whose network exposure you have not audited in the last six months, today is the day to audit it.
What To Do
Patch this week. The 1.25.2 upgrade is in-place; the binary is wire-compatible with itself and with the Postgres side. There is no good reason to delay.
If you cannot patch this week, the workaround is the boring one: tighten the security group, terminate at a load balancer with a sane WAF in front, and verify that nothing outside your VPC can speak the Postgres wire protocol to the pooler. None of that is a substitute for upgrading. It buys you a few days, not a few months.
A Secondary Observation
This is the second SCRAM-handling bug class in PgBouncer in the last year. SCRAM is a small, well-specified protocol, and the PgBouncer implementation has been audited several times. That a second pre-auth bug surfaced in the same code path suggests the state machine in and around client_login() has accumulated more conditional handling than the code can reasonably hold. I would not be shocked to see a third before this is done.
Subscribe to pgbouncer-general, watch the changelog, and keep your patch cadence tight. The pooler is the most exposed piece of your Postgres deployment. Treat it accordingly.