PgBouncer EUVD-2026-85364

Requires PgBouncer configured to authenticate to backends via SCRAM, and the attacker must control or compromise a PostgreSQL backend server that the PgBouncer instance pools - the malicious iteration count is supplied by the backend during PgBouncer's own outbound SCRAM authentication, not by a frontend client. Exploitation is limited by this precondition (AC:H): an ordinary external client cannot trigger it, and it applies to frontend builds where the derivation cannot be interrupted. Impact is amplified because PgBouncer's single-process architecture means one affected backend denies service to all pooled databases and clients. No fix beyond upgrading past 1.25.2 mitigates the missing iteration-count upper bound.

This is a genuine but bounded availability risk, not a high-priority mass-exploitation issue. The CVSS 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) correctly captures a pure denial-of-service with no confidentiality or integrity impact. The critical nuance the raw vector understates is the threat model: the 'attacker' is a malicious or compromised PostgreSQL BACKEND that PgBouncer authenticates to via SCRAM - not an ordinary external client. PR:N is technically defensible (no authentication to PgBouncer's frontend is bypassed) but AC:H reflects the real precondition that an adversary must already control a backend database server in the pool. No EPSS score, KEV listing, or public POC was provided, and the sole reference is the vendor changelog - so there is no evidence of active exploitation: no public exploit identified at time of analysis. The severity multiplier is architectural: because PgBouncer serves all pooled databases and clients from a single process and the key-derivation loop cannot be interrupted in frontend builds, one poisoned backend can stall the entire pooler, so the blast radius extends to every unrelated tenant. Verify the exact fixed version against the vendor changelog, which was not directly retrievable during analysis.

An attacker who compromises (or maliciously operates) a PostgreSQL backend that a shared PgBouncer instance pools returns an extremely large SCRAM key-derivation iteration count during PgBouncer's authentication to that backend. PgBouncer performs the uninterruptible derivation in its single process, pinning CPU and blocking connection servicing for every other database and client in the pool. No public exploit code is identified; exploitation requires the high-complexity precondition of controlling a backend server.