Vulnerability details

## Summary pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. ### Impact A 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: 1. The connection uses **SCRAM-SHA-256** authentication. 2. The client reaches a **malicious, compromised, or attacker-controlled PostgreSQL endpoint**. 3. 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 control - the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources - the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised - the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server - an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, `/etc/hosts`, environment variables, or similar indirection - an 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. ### Patches The 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. ### Workarounds Until a patched version of pgjdbc is deployed, the following measures reduce exposure: 1. **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. 2. **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. 3. **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. 4. **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. 5. **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.