Keeping PostgreSQL patched does not necessarily mean that PgBouncer, which accepts connections in front of it, is patched too. A separate process in the connection path needs its own maintenance plan.

Christophe Pettus raises this gap in “Nobody Patches the Pooler,” prompted by the security fixes in PgBouncer 1.26.0, released on September 23, 2026. The official release announcement confirms three CVE fixes, including two issues reachable before authentication.

The practical question is which work happens before credentials are verified, and which process needs replacing. Following that path explains the shared failure scope, the limits of temporary mitigations, and the restart procedures that need attention.

Pre-authentication work can stop an entire PgBouncer process

PgBouncer handles connections between applications and PostgreSQL. A crash or stall in this shared process can affect other connections it serves. These fixes concern PgBouncer; the PostgreSQL server version alone cannot establish whether they are installed.

The three issues differ in where the input originates and how processing stops.

All three concern versions before 1.26.0. The crash dates back to SCRAM support in 1.11.0; 1.26.0 also limits the server-supplied iteration count to one million. Changelog

The authentication setting needs careful interpretation. With auth_type = md5, PgBouncer automatically uses SCRAM when the user has a stored SCRAM secret. The absence of scram-sha-256 in that setting does not establish that a deployment is unaffected. Authentication configuration

Network restrictions and packet limits address different failure paths

Start by identifying the running PgBouncer instance and its configuration. Connect to the administrative database named pgbouncer with a user authorized for the console, then issue these read-only commands. Admin console documentation

-- Display the running PgBouncer version.
SHOW VERSION;
-- Display current configuration values.
SHOW CONFIG;

Establish whether the 1.26.0 fixes are installed, inspect auth_type and max_packet_size, and determine who can reach the listener. For distribution packages or managed services, also consult the provider about patch status.

If upgrading must wait, restrict network access to trusted clients to mitigate the crash. Invalid usernames are not a defense: PgBouncer performs a mock SCRAM exchange for nonexistent users too. CVE-2026-19888 conditions and workaround

For the infinite loop, the documented workaround is to set max_packet_size well below 1073741824. This setting does not resolve all three issues. CVE-2026-6668 workaround

The limit applies to individual PostgreSQL packets, such as a query or one result row, rather than the entire result set. Choose a lower limit with legitimate large queries and rows in mind. Packet-size configuration

Upgrading to 1.26.0 changes restart procedures and connection state

Replacing the binary also requires reviewing how it is started. Version 1.26.0 removes the deprecated -R online restart mechanism and its supporting SHOW FDS and SUSPEND commands. Deployment scripts that invoke them need changes. Version 1.26.0 changelog

Rolling restarts require multiple processes accepting connections while instances are replaced individually. With so_reuseport, verify OS support and provide separate Unix sockets and PID files. Peering also matters for forwarding query cancellations. Multiple-process configuration

SHUTDOWN WAIT_FOR_CLIENTS stops accepting new connections and waits for existing clients to disconnect. Applications that hold connections open need a reconnection plan as part of the rollout. Official rolling restart procedure

Version 1.26.0 also tracks parameters reported by PostgreSQL by default, including search_path on PostgreSQL 18 and later and default_transaction_read_only on 14 and later. Test connection reuse in transaction pooling mode for accidental reliance on settings left behind by another client. Parameter tracking changes

Probe through PgBouncer to test the application connection path

A process caught in an infinite loop can still exist without answering SQL. A successful direct connection to PostgreSQL does not establish that the application path works.

One operational check is to send a short query through PgBouncer to an application database and observe response time and failures. SELECT 1; is an example. This is a proposed availability probe, not a vulnerability reproduction test.

The practical outcome is to treat PgBouncer as an independent update target and verify the replacement through both the running process and the connection path. Network restrictions and packet limits can help while an upgrade is pending; assigning an update owner and maintaining a tested restart procedure makes pooler maintenance part of the database maintenance plan.

Source

• Title: Christophe Pettus: Nobody Patches the Pooler
• URL: https://postgr.es/p/9wU