pgjdbc client-side CPU exhaustion (CVE-2026-42198)

Vendor-confirmed - CVE-2026-42198 is a high-severity denial of service in the pgjdbc PostgreSQL JDBC Driver versions 42.2.0 to before 42.7.11 that lets a malicious server exhaust client CPU resources by forcing an unbounded number of PBKDF2 iterations during SCRAM-SHA-256 authentication. Patched in version 42.7.11 - upgrade immediately.

Overview

CVE-2026-42198 affects the pgjdbc (PostgreSQL JDBC Driver) library, an open-source driver used to connect Java applications to PostgreSQL databases. The vulnerability lies in the SCRAM-SHA-256 authentication mechanism. When a client connects to a PostgreSQL server, the server can specify the iteration count used in the PBKDF2 key derivation function.

A malicious or compromised server can set this iteration count to an extremely high value. This forces the client to perform an unbounded amount of CPU-bound computation before the authentication attempt can fail or proceed. With a single connection attempt, an attacker can tie up a full CPU core on the client machine.

Because the driver processes connections in worker threads, repeated or concurrent attacks can exhaust client CPU resources and wedge connection pools, effectively causing a denial of service against the application.

Impact on Affected Systems

• Primary risk: Client-side denial of service. An attacker controlling a database server can cause high CPU usage on any client connecting to it, potentially crashing the application or making it unresponsive.
• Secondary risk: Connection pool exhaustion. If the application uses a connection pool, the attack can fill all available threads with blocked authentication attempts, preventing legitimate connections.

Affected Versions

• Affected: pgjdbc versions from 42.2.0 through 42.7.10
• Unaffected: pgjdbc version 42.7.11 and later
• Note: Earlier versions (before 42.2.0) may also be vulnerable but are out of maintenance

Remediation and Mitigation

Update

Upgrade to pgjdbc version 42.7.11 or later. This is the only complete fix.

Workarounds (not a full solution)

If immediate update is not possible, note that loginTimeout is not sufficient mitigation. While the timeout will stop the caller from waiting, the worker thread performing the SCRAM computation can continue running and burning CPU even after the timeout expires.

Consider implementing the following in addition to updating:

• Use network-level controls to only allow connections to trusted PostgreSQL servers
• Apply resource limits to the Java process (e.g., container CPU limits, process ulimit settings)
• Monitor for unusual CPU usage patterns from JVM processes

Security Insight

This vulnerability highlights a recurring class of issues in cryptographic protocol implementations: trusting server-specified parameters that control computational cost. Like similar flaws found in SSH (CVE-2023-48795, Terrapin variant) and earlier TLS implementations, CVE-2026-42198 shows that even well-established protocols like SCRAM-SHA-256 can become attack surfaces when clients blindly honor server-chosen iteration counts. Vendors should treat cryptographic parameter negotiation as a potential denial-of-service vector and enforce sensible upper bounds on iteration values in client libraries.

For the latest data breach reports and cybersecurity news, visit our security coverage.

Further Reading

• All High Vulnerabilities
• Recent Critical Vulnerabilities
• Top Critical CVEs