What changed
On 14 October 2026, PgBouncer maintainers released version 1.26.1 with fixes for CVE-2026-107350, CVE-2026-107349 and CVE-2026-107348. The most consequential issue is a SCRAM authentication state-machine error: if a client knows the password of one SCRAM user, it can under specific circumstances present a second StartupMessage during authentication to a nonexistent database and be accepted as another SCRAM user, potentially including PgBouncer administrators and backend PostgreSQL superusers. The other two bugs can make PgBouncer loop indefinitely on malformed client startup data without authentication. The release also changes how ignored startup parameters take precedence.
Why it matters
PgBouncer is often placed directly between applications and PostgreSQL to pool connections. Its authentication boundary is therefore more sensitive than an ordinary application dependency: an incorrect identity handoff can compromise database role isolation, while an unauthenticated infinite loop can exhaust service capacity. Operators of multi-tenant apps, SaaS backends and shared PostgreSQL clusters should check the PgBouncer binary actually running in front of each database and upgrade rather than relying on the backend's own patch status.
A known SCRAM password could become a different identity
CVE-2026-107350 does not mean any unauthenticated visitor can immediately become a database superuser. The documented prerequisite is knowledge of at least one SCRAM user's password. A second StartupMessage arriving during SCRAM authentication to a nonexistent database could then cause PgBouncer to authenticate that client as a different SCRAM user, including administrators and backend superusers. The distinction matters for assessing exposure: pooled environments with multiple database roles or credentials of differing privilege levels face an identity-boundary failure.
Two denial-of-service paths need no login
CVE-2026-107349 is an infinite loop when the startup options parameter contains an empty option name and ignore_startup_parameters is nonempty without listing options. CVE-2026-107348 is another infinite loop in packet-buffer growth caused by an integer overflow; this one requires max_packet_size to be configured above its default. Both can be triggered by unauthenticated clients, but the configuration preconditions differ. Administrators should not assume every installation has the same exposure to both issues.
The security release also changes parameter precedence
In 1.26.1, ignore_startup_parameters takes precedence over tracked parameters. Setting ignore_startup_parameters = search_path again ignores search_path, matching PgBouncer 1.25 behaviour. That compatibility detail matters for teams relying on startup-session settings and can change how a connection pool handles application-supplied search paths. Test relevant client configuration after the security update.
Patch the connection pooler, not just PostgreSQL
The release and PostgreSQL project's news notice both recommend 1.26.1. Operators should inventory self-hosted and provider-managed PgBouncer instances, determine whether any are externally reachable, test connection/authentication flows, and update the pooler. This is a different product and advisory from the Pgpool-II security release already covered by BTN; the two should not be confused. The official notice does not establish widespread exploitation, so exploit prevalence should not be inferred.