The vulnerability is an unbounded SCRAM iteration count accepted during authentication to a backend server. The absence of an upper bound enables a malicious or compromised PostgreSQL backend to cause uncontrolled CPU consumption in PgBouncer. The key derivation cannot be interrupted and, because PgBouncer runs as a single process, the excessive workload from one backend can stall the entire service, preventing all connected clients from being served. The issue affects PgBouncer versions up through 1.25.2. The product is PgBouncer, a connection pooler for PostgreSQL. The vulnerability is reported for all builds that use the frontend process without a set limit, and it applies specifically to the SCRAM authentication mechanism. The CVSS score of 5.9 indicates moderate severity; the EPSS score is missing, so the exploitation probability is undetermined. The vulnerability is listed as not in the CISA KEV catalog. Attackers with control over a backend server can exploit the flaw by configuring an exceptionally high SCRAM iteration count in the authentication request; this would cause PgBouncer to consume excessive CPU resources until it becomes unresponsive to other clients.

The affected product is PgBouncer, the PostgreSQL connection pooler, in all releases up through version 1.25.2. Any deployment using the frontend build without an upper bound on the SCRAM iteration count during authentication is vulnerable.

The moderate severity CVSS score of 5.9 reflects the potential for a denial of service, yet the EPSS score is currently unavailable, meaning the likelihood of exploitation in the wild is unknown. The vulnerability is not listed in CISA’s KEV catalog. The likely exploitation scenario involves a malicious or compromised PostgreSQL backend that sets an unusually high SCRAM iteration count during the authentication handshake observed by PgBouncer. Because PgBouncer’s key derivation routine cannot be interrupted, this produces a sustained CPU drain that stalls the single-process service and deprives all connected clients of service. The primary attack vector is therefore an internal or compromised backend server; an external attacker would need to gain control of such a backend to trigger the effect.