GHSA-98qh-xjc8-98pq pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
Summarypgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.ImpactA malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count.
With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail.
A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools.In affected versions, `loginTimeout` did not fully mitigate this problem. When `loginTimeout` expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation.This issue affects availability. It does **not** provide authentication bypass, privilege escalation, or direct password disclosure.A user is vulnerable when **all** of the following are true:The connection uses **SCRAM-SHA-256** authentication.The client reaches a **malicious, compromised, or attacker-controlled PostgreSQL endpoint**.That endpoint sends a very large SCRAM PBKDF2 iteration count in the `server-first-message`.In practice, that can happen in these situations:the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they controlthe application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sourcesthe application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromisedthe application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL serveran attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, `/etc/hosts`, environment variables, or similar indirectionan active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, `sslmode` lower than `verify-full`, or trusting a CA that signs hosts outside the operator's control)The issue is **more damaging** when the application uses connection retries, many parallel connection attempts, or `loginTimeout` and assumes the timeout fully stops the work.PatchesThe patch introduces a new connection property, `scramMaxIterations`, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.WorkaroundsUntil a patched version of pgjdbc is deployed, the following measures reduce exposure:**Only connect to trusted PostgreSQL servers whose identity is verified.**  
Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.**Do not rely on `loginTimeout` as a complete mitigation on unpatched versions.**  
On affected versions, `loginTimeout` can stop the waiting caller while the worker thread continues spending CPU.**Avoid SCRAM on untrusted or interceptable connection paths.**  
For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.**Reduce blast radius operationally.**  
Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.**On trusted servers you control, keep SCRAM iteration counts at ordinary values.**  
This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.
CVSS v3.1 score: 7.5