pgjdbc SCRAM flaw lets a malicious server exhaust client CPU

TL;DR - org.postgresql:postgresql blindly accepts the PBKDF2 iteration count the server advertises during SCRAM-SHA-256 auth. Send a huge number, pin a CPU core. Repeat across a connection pool and the application starves. Fixed in 42.7.11 via a new scramMaxIterations cap (default 100,000).

What happened

pgjdbc (org.postgresql:postgresql) is the PostgreSQL JDBC driver used by most Java services to talk to Postgres.

CVE-2026-42198 is a client-side availability bug. During SCRAM-SHA-256 authentication, the server sends a server-first-message that includes a PBKDF2 iteration count. Affected versions of the driver accept whatever number the server advertises - no cap, no validation. A malicious or compromised endpoint sends an enormous count. The driver then burns unbounded CPU on PBKDF2 before the handshake can even fail. One connection attempt can saturate a core. Concurrent attempts can exhaust client CPU entirely and wedge the connection pool.

There is an operational catch worth knowing: loginTimeout will unblock the calling thread, but the worker thread doing the actual connection attempt keeps computing PBKDF2 in the background. The timeout is not a real mitigation on unpatched versions.

The fix introduces a scramMaxIterations connection property (default 100,000) that caps what the server is allowed to advertise. Counts above the cap are rejected before the expensive computation begins.

Where this gets dangerous: any product that lets users or tenants supply JDBC URLs, database hostnames, or connection strings can have this triggered entirely from the outside. DNS poisoning, service-discovery hijacking, or a misconfigured proxy that redirects traffic to an attacker-controlled endpoint all create the same exposure. The client does the work; the attacker pays nothing.

Who is impacted

A deployment is vulnerable when all three are true:

• The application uses org.postgresql:postgresql in the affected version range.
• Connections use SCRAM-SHA-256 authentication.
• The client can be directed - legitimately or otherwise - to a malicious or attacker-controlled PostgreSQL endpoint.

Highest-risk patterns called out in the advisory:

• Platforms where users or tenants can supply JDBC URLs or connection details - BI tools, analytics platforms, ETL pipelines, low-code builders.
• Environments where DNS, service discovery, or proxies could redirect connections to an attacker-controlled endpoint.
• Connections that do not strongly verify server identity - TLS without hostname verification being the obvious case.

What to do now

• Upgrade to 42.7.11 or a newer patched version. This is the fix. Everything else is noise if you are in the affected range.
• If your product accepts tenant-supplied database connection details, treat this as an externally triggerable DoS surface and prioritise those services first.
• Enforce strong server identity verification on all database connections:

  "Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA."

• Do not rely on loginTimeout alone on unpatched versions:

  "Do not rely on loginTimeout as a complete mitigation on unpatched versions."

• After upgrading, check whether scramMaxIterations needs to be set explicitly. The default is 100,000 - adjust if your Postgres server is configured to advertise a higher count for legitimate reasons.
• Where you cannot patch immediately, reduce blast radius: limit parallel connection attempts, add retry backoff, and apply CPU limits to containers or threads responsible for connection establishment.