CVE-2026-42198: 
Java vulnerability analysis and mitigation

CVE-2026-42198 is a client-side denial-of-service vulnerability in pgjdbc (the open-source PostgreSQL JDBC Driver) affecting versions 42.2.0 through before 42.7.11. A malicious PostgreSQL server can instruct the driver to perform SCRAM-SHA-256 authentication with an arbitrarily large PBKDF2 iteration count, causing the client to consume unbounded CPU time before authentication can fail. The vulnerability was published on April 29, 2026, and patched in version 42.7.11 released April 28, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Feedly).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the driver accepts the PBKDF2 iteration count advertised by the server in the SCRAM server-first-message without imposing any upper bound, then begins the computationally expensive PBKDF2 derivation before it can reject the authentication. An attacker controlling a PostgreSQL endpoint sends a crafted server-first-message with an extremely large i= (iteration count) parameter. Because PBKDF2 is intentionally CPU-intensive, even a single connection attempt can saturate a CPU core; concurrent or retried attempts can exhaust all available cores and wedge connection pools. A critical aggravating factor is that loginTimeout does not fully mitigate the issue: when the timeout expires the calling thread is released, but the worker thread continues burning CPU inside the PBKDF2 loop until it completes (GitHub Advisory, pgjdbc Release).

Successful exploitation causes a client-side denial of service: the JDBC client's CPU cores are consumed by unbounded PBKDF2 computation, degrading or completely halting application performance. Connection pools can become wedged, preventing the application from establishing any new database connections and effectively taking the application offline. There is no confidentiality or integrity impact — the vulnerability does not provide authentication bypass, privilege escalation, or password disclosure (GitHub Advisory). Applications most at risk include BI/reporting platforms, ETL tools, and low-code platforms that allow users to supply their own database connection strings, as well as any application connecting through untrusted proxies or subject to DNS/service-discovery manipulation (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The EPSS score is approximately 0.024% (0.000240), indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires the attacker to control or impersonate a PostgreSQL server endpoint reachable by the victim client, which limits opportunistic exploitation but is realistic in multi-tenant SaaS, misconfigured TLS (sslmode below verify-full), or DNS/network-path manipulation scenarios (GitHub Advisory).

1. Set up a malicious PostgreSQL server: Deploy a custom or modified PostgreSQL server (or a TCP proxy) that responds to the SCRAM-SHA-256 authentication handshake with a crafted server-first-message containing an extremely large iteration count (e.g., r=<nonce>,s=<salt>,i=2147483647).
2. Redirect the victim client: Position the malicious server so the target pgjdbc client connects to it. This can be achieved by: supplying a malicious JDBC URL in a multi-tenant application, DNS spoofing/poisoning, manipulating Kubernetes service discovery, or exploiting a misconfigured sslmode (below verify-full) to perform a man-in-the-middle attack.
3. Trigger the connection attempt: Cause the victim application to initiate a database connection — this may happen automatically on startup, on connection pool initialization, or by submitting a query through the application's UI.
4. Exhaust client CPU: The pgjdbc driver receives the oversized iteration count and begins PBKDF2 computation without checking the value against any cap. Each connection attempt ties up one CPU core indefinitely. Repeated or concurrent attempts (e.g., via connection pool retries) exhaust all available CPU cores.
5. Sustain the DoS: Even if loginTimeout is configured, worker threads continue the PBKDF2 computation after the timeout expires, maintaining CPU exhaustion. The connection pool becomes wedged, and the application is unable to serve requests (GitHub Advisory).

• Process/CPU: Sustained near-100% CPU utilization on application server JVM processes, particularly on threads involved in database connection establishment, with no corresponding increase in query throughput.
• Logs: Application logs showing repeated connection timeout errors or SCRAM authentication failures against a database host, especially if the host is unexpected or newly introduced; Java thread dumps showing multiple threads stuck inside PBKDF2/SCRAM computation.
• Network: Outbound TCP connections from the application server to an unexpected or unauthorized PostgreSQL endpoint (port 5432 or custom) that does not match configured database hosts; connections that remain open for an unusually long time without completing authentication.
• Connection Pool: Connection pool exhaustion alerts or errors (e.g., HikariPool timeout, c3p0 pool exhausted) coinciding with the CPU spike, without a corresponding database-side load increase (GitHub Advisory).

Primary fix: Upgrade pgjdbc to version 42.7.11 or later. The patch introduces a new connection property scramMaxIterations (default: 100,000) that causes the driver to reject SCRAM server-first-message values advertising more PBKDF2 iterations than the configured cap before computation begins (pgjdbc Release). IBM Enterprise Build of Quarkus users should apply the IBM security bulletin update (IBM Advisory). Red Hat and SUSE have also issued errata (RHSA-2026:19098, RHSA-2026:22304, RHSA-2026:24348, RHSA-2026:25030, SUSE-SU-2026:2028-1). Workarounds for unpatched versions: (1) Only connect to trusted PostgreSQL servers with TLS using sslmode=verify-full and a trusted CA to prevent server impersonation. (2) Do not rely on loginTimeout as a complete mitigation. (3) Limit parallel connection attempts and add retry backoff. (4) Apply CPU or container limits to isolate blast radius. (5) Avoid SCRAM on untrusted or interceptable connection paths (GitHub Advisory).

The vulnerability was discovered and reported by sehrope, a pgjdbc contributor, who also authored the patch. The fix was released proactively alongside the advisory on April 28, 2026. Multiple Linux distributions (Red Hat, SUSE, AlmaLinux, Rocky Linux, openSUSE) and downstream vendors (IBM, Atlassian) issued security updates within weeks of disclosure, indicating broad ecosystem awareness. Coverage appeared on security aggregators including Tenable (multiple Nessus plugins), pro-linux.de, and HeroDevs, reflecting standard industry response to a library-level DoS vulnerability (GitHub Advisory, IBM Advisory, Atlassian Bulletin).