CVE-2026-42198: pgjdbc PostgreSQL Driver DoS Vulnerability

CVE-2026-42198 Overview

CVE-2026-42198 is a client-side denial of service vulnerability in pgjdbc, the open source PostgreSQL JDBC Driver. The vulnerability exists in versions 42.2.0 through 42.7.10 and allows a malicious server to exhaust client CPU resources during SCRAM-SHA-256 authentication by specifying an extremely large iteration count for the PBKDF2 key derivation function.

Critical Impact

A malicious PostgreSQL server can cause client applications to consume unbounded CPU time, potentially exhausting connection pools and rendering applications unresponsive. This attack requires no authentication and can be triggered remotely.

Affected Products

• pgjdbc versions 42.2.0 through 42.7.10
• Java applications using affected pgjdbc versions for PostgreSQL connectivity
• Connection pools utilizing vulnerable JDBC driver versions

Discovery Timeline

• 2026-04-29 - CVE CVE-2026-42198 published to NVD
• 2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-42198

Vulnerability Analysis

This vulnerability falls under CWE-770 (Allocation of Resources Without Limits or Throttling) and represents a resource exhaustion denial of service attack. The flaw resides in how pgjdbc handles SCRAM-SHA-256 authentication parameters received from the server during the connection establishment phase.

During SCRAM authentication, the server specifies an iteration count for the PBKDF2 (Password-Based Key Derivation Function 2) algorithm used to derive the authentication key. While legitimate PostgreSQL servers use reasonable iteration counts, a malicious server can specify an arbitrarily large value. The pgjdbc driver does not validate or limit this iteration count before executing the computationally expensive PBKDF2 operation.

The attack is particularly insidious because even when loginTimeout is configured, the mitigation is incomplete. When the timeout expires, the calling thread may stop waiting for the connection, but the underlying worker thread continues executing the PBKDF2 computation, consuming CPU resources until completion. This means repeated connection attempts can accumulate CPU-bound threads, eventually exhausting all available CPU cores.

Root Cause

The root cause is the absence of server-side iteration count validation in the SCRAM authentication implementation. The driver trusts the iteration count parameter provided by the server without enforcing a maximum threshold, allowing a malicious server to dictate arbitrarily expensive cryptographic operations on the client side.

Attack Vector

The attack is network-based and requires an attacker to either operate a malicious PostgreSQL server or perform a man-in-the-middle attack to intercept and modify the SCRAM authentication handshake. The attacker manipulates the iteration count parameter in the SCRAM server-first message to an extremely large value (e.g., billions of iterations). When the client receives this parameter, it begins executing the PBKDF2 function with the malicious iteration count, tying up CPU resources for an extended period.

The attack mechanism involves the following sequence:

1. Client initiates connection to what it believes is a legitimate PostgreSQL server
2. Server responds with SCRAM authentication parameters including an excessively large iteration count
3. Client begins PBKDF2 computation with the malicious parameters
4. CPU core becomes fully utilized for an extended period
5. Concurrent attack attempts multiply the resource exhaustion effect

For detailed technical information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-42198

Indicators of Compromise

• Abnormally high CPU utilization on application servers during database connection attempts
• Connection pool exhaustion events in application logs
• Extended thread blocking times in JDBC authentication code paths
• Sudden increase in connection timeout errors without corresponding database issues
• Worker threads stuck in PBKDF2 computation states visible in thread dumps

Detection Strategies

• Monitor for CPU usage spikes correlated with database connection establishment
• Implement thread dump analysis to identify threads blocked in SCRAM authentication
• Deploy network traffic analysis to detect anomalous SCRAM iteration counts in PostgreSQL protocol
• Configure application performance monitoring (APM) to alert on connection establishment latency anomalies

Monitoring Recommendations

• Establish baseline metrics for normal JDBC connection establishment times
• Alert on connection pool health degradation patterns
• Monitor thread pool utilization for unexpected growth in blocked threads
• Implement logging for authentication timeout events at the application layer

How to Mitigate CVE-2026-42198

Immediate Actions Required

• Upgrade pgjdbc to version 42.7.11 or later immediately
• Audit all Java applications for vulnerable pgjdbc dependency versions
• Review connection configurations to ensure connections are made only to trusted PostgreSQL servers
• Implement network-level controls to restrict database connectivity to known endpoints

Patch Information

The vulnerability has been patched in pgjdbc version 42.7.11. This release introduces proper validation of the SCRAM iteration count parameter, preventing malicious servers from triggering excessive CPU consumption. For complete release details, see the pgjdbc Release Notes.

Workarounds

• Use MD5 authentication instead of SCRAM-SHA-256 where security requirements permit (not recommended for production)
• Implement network segmentation to ensure JDBC drivers only connect to trusted PostgreSQL servers
• Deploy connection timeouts with circuit breaker patterns to limit impact of connection failures
• Consider using a WAF or network firewall to restrict outbound PostgreSQL connections to known servers

# Configuration example
# Update pgjdbc dependency in Maven pom.xml
# Change version from vulnerable to patched:
# <dependency>
#   <groupId>org.postgresql</groupId>
#   <artifactId>postgresql</artifactId>
#   <version>42.7.11</version>
# </dependency>

# For Gradle, update build.gradle:
# implementation 'org.postgresql:postgresql:42.7.11'