CVE-2026-6669 in PgBouncer
Summary
by MITRE • 09/23/2026
Missing upper bound on the key derivation iteration count accepted during SCRAM authentication to a backend server in PgBouncer through 1.25.2 allows a malicious or compromised PostgreSQL backend to cause uncontrolled CPU consumption in PgBouncer. The resulting key derivation cannot be interrupted in frontend builds such as PgBouncer. Because PgBouncer serves all clients from a single process, one backend can in this way stop it from serving traffic for every other database and client it is pooling, so the failure of a single backend is not contained.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified involves a critical flaw in the key derivation iteration count validation within PgBouncer versions through 1.25.2 during SCRAM authentication processes directed at backend PostgreSQL servers. This issue stems from the absence of an upper bound check on the number of iterations specified by the server for password hashing algorithms, specifically those used in the Salted Challenge Response Authentication Mechanism protocol. In a properly secured implementation, such iteration counts must be strictly bounded to prevent resource exhaustion attacks. Without this constraint, a malicious or compromised backend server can request an excessively high number of iterations during the authentication handshake. This allows the attacker to force PgBouncer into performing computationally expensive key derivation operations that consume significant CPU resources without any mechanism for interruption in standard frontend builds.
From a technical perspective, the core issue lies in how PgBouncer handles the parameters provided by the backend server during the SCRAM exchange. The authentication process requires both client and server to compute derived keys based on salted hashes. When the iteration count is left unbounded, an attacker can specify values that push the CPU into sustained high-load states. Because these computations are intensive and cannot be preemptively interrupted in many execution environments, they effectively block other operations within the same thread or process context. This behavior transforms a simple authentication step into a vector for denial of service, exploiting the computational asymmetry where the server dictates workload parameters that the client must blindly execute.
The operational impact of this vulnerability is severe due to the architectural design of PgBouncer as a connection pooler serving multiple clients from a single process or limited set of processes. Unlike standalone database servers which might isolate connections more granularly, PgBouncer relies on efficient multiplexing to handle high concurrency. When one backend exploits this flaw, it monopolizes CPU cycles across the entire proxy instance. Consequently, all other active and incoming client connections suffer from latency spikes or complete timeouts as they are starved of processing time. This means that a failure or compromise in just one database server can cascade into a total service outage for every application connected through PgBouncer, violating principles of fault isolation and containment.
This vulnerability aligns with CWE-400 Uncontrolled Resource Consumption, specifically where an attacker triggers excessive computational effort leading to resource exhaustion. It also maps closely to MITRE ATT&CK technique T1496 Resource Hijacking, wherein a compromised system is used for unintended purposes such as cryptocurrency mining or denial of service by consuming host resources. The attack vector leverages the trust relationship between PgBouncer and its backend servers, highlighting risks associated with internal network security assumptions where backends are often considered trusted entities despite potential compromise scenarios like insider threats or lateral movement by attackers who have breached a database server.
Mitigation strategies primarily involve upgrading to patched versions of PgBouncer that implement strict upper bounds on SCRAM iteration counts according to industry best practices and RFC standards for password storage. Administrators should also enforce configuration limits within PgBouncer itself where possible, restricting the maximum allowed iterations during authentication handshakes. Additionally, implementing network segmentation between application servers connecting via PgBouncer and backend database servers can limit exposure if a single server is compromised. Monitoring CPU usage patterns on proxy nodes may provide early detection indicators for such resource exhaustion attempts, allowing for rapid isolation of offending backends before widespread service degradation occurs.