CVE-2026-42198

What it actually does

CVE-2026-42198 is a client-side denial-of-service vulnerability in pgjdbc, the PostgreSQL JDBC driver, affecting versions 42.2.0 through versions before 42.7.11. During SCRAM-SHA-256 authentication, a malicious or attacker-controlled PostgreSQL-compatible server can advertise an excessively large SCRAM iteration count. The vulnerable driver accepts that value and enters an expensive PBKDF2 computation before authentication completes or fails. With a sufficiently large iteration count, one connection attempt can consume a CPU core for an extended period. Multiple concurrent attempts can exhaust application CPU and connection-pool worker threads. The issue is aggravated because, in affected versions, loginTimeout may return control to the caller while the underlying worker thread continues performing PBKDF2 and consuming CPU.

Why it matters to the business

Applications that use affected pgjdbc versions can become slow, unavailable, or unable to obtain database connections if they are tricked into connecting to a malicious PostgreSQL-compatible endpoint. The primary operational risk is application outage or severe performance degradation, especially for services with automatic reconnect logic, health checks, background jobs, or large connection pools. Although current public exploit maturity is listed as none, EPSS is low and flat, and the issue is not in CISA KEV, the CVSS availability impact is high because exploitation requires no authentication against the client and can be triggered over the network when an application connects to an attacker-controlled database endpoint.

How an attack unfolds

An attacker first needs a way to cause an application using vulnerable pgjdbc to initiate a PostgreSQL connection to a server the attacker controls or can influence. This may occur through compromised configuration, malicious service discovery or DNS routing, poisoned connection strings, SSRF-style connection features, testing tools pointed at untrusted hosts, or a man-in-the-middle position where database server identity is not strongly verified. The attacker’s server behaves enough like PostgreSQL to negotiate startup and request SCRAM-SHA-256 authentication. During the SCRAM exchange, it advertises an extremely large iteration count. The affected driver uses that count in PBKDF2, causing the client thread to spend unbounded CPU time computing authentication material. If the application retries, opens multiple pooled connections, or has several instances connecting concurrently, CPU cores and connection worker threads can be saturated. The attack does not disclose or modify data directly, but it can prevent the application from serving requests or maintaining database connectivity.

How to fix it

Upgrade pgjdbc to version 42.7.11 or later wherever the PostgreSQL JDBC driver is used. Inventory direct and transitive dependencies, including application-bundled JARs, container images, build artifacts, and vendor-shaded copies of the driver. If immediate upgrade is not possible, reduce exposure by ensuring applications only connect to trusted PostgreSQL endpoints, enforcing strict configuration controls for JDBC URLs, restricting outbound network access to approved database hosts, enabling TLS with server certificate validation where supported, and limiting automatic retries or connection-pool growth. Treat loginTimeout as insufficient mitigation for affected versions because the worker thread may continue consuming CPU after the caller stops waiting.

How to confirm the fix worked

Confirm that all deployed applications use pgjdbc 42.7.11 or later by inspecting dependency manifests, software composition analysis results, application build files, container layers, and runtime classpaths. For Maven or Gradle projects, verify that org.postgresql:postgresql resolves to 42.7.11 or newer and that no older driver JAR remains packaged in the application. Validate egress controls by confirming application hosts can only initiate PostgreSQL connections to approved database endpoints. In a controlled test environment only, attempt a connection to a benign test server that advertises an abnormal SCRAM iteration count and confirm the upgraded driver rejects or bounds the computation without sustained CPU consumption. Monitor after rollout for reduced authentication-related CPU spikes and absence of lingering connection-attempt worker threads after login timeouts.

Typical attack path

1. Identify an application or service that uses pgjdbc versions 42.2.0 through before 42.7.11.
2. Find a way to make the application connect to an attacker-controlled or attacker-influenced PostgreSQL-compatible endpoint.
3. Operate a malicious PostgreSQL-like server that initiates SCRAM-SHA-256 authentication.
4. Return a SCRAM server-first message with an excessively large iteration count.
5. Cause the vulnerable client to enter prolonged PBKDF2 computation during authentication.
6. Repeat or parallelize connection attempts to consume CPU cores and connection-pool worker threads.
7. Maintain pressure through retries, failed health checks, or connection pool replenishment until the application becomes degraded or unavailable.

How to detect it

To determine whether exploitation may have occurred, focus on evidence that applications attempted PostgreSQL SCRAM authentication against unexpected database endpoints and then experienced sustained CPU consumption or connection-pool exhaustion. Review application logs, JDBC connection-pool logs, service discovery changes, DNS logs, proxy/firewall egress logs, and endpoint telemetry. Look for repeated PostgreSQL connection attempts to unfamiliar hosts or IPs, authentication failures involving SCRAM-SHA-256, login timeout messages followed by continued high CPU usage, thread dumps showing pgjdbc authentication code executing PBKDF2, and connection pools stuck creating or validating connections. Network telemetry may show outbound traffic to TCP/5432 or PostgreSQL-like services outside approved database ranges. Process telemetry may show Java processes consuming full cores without proportional request volume. If thread dumps are available from the suspected window, search for Java threads in PBKDF2, SCRAM, or pgjdbc authentication routines. No public actor-specific or ransomware-specific exploitation is indicated by the provided intelligence.

• org.postgresql:postgresql versions 42.2.0 through 42.7.10
• postgresql-42.2.
• postgresql-42.3.
• postgresql-42.4.
• postgresql-42.5.
• postgresql-42.6.
• postgresql-42.7.0.jar
• postgresql-42.7.1.jar
• postgresql-42.7.2.jar
• postgresql-42.7.3.jar
• postgresql-42.7.4.jar
• postgresql-42.7.5.jar
• postgresql-42.7.6.jar
• postgresql-42.7.7.jar
• postgresql-42.7.8.jar
• postgresql-42.7.9.jar
• postgresql-42.7.10.jar
• SCRAM-SHA-256
• PBKDF2
• loginTimeout
• org.postgresql.core.v3.ConnectionFactoryImpl
• org.postgresql.core.v3.AuthenticationPluginManager
• org.postgresql.core.v3.ScramAuthenticator
• com.ongres.scram
• connection attempt timed out
• Connection attempt timed out
• The connection attempt failed
• FATAL: password authentication failed
• tcp/5432 outbound to unapproved destination

What your security team should do

• Prioritize upgrading all instances of org.postgresql:postgresql / pgjdbc to 42.7.11 or later, especially internet-facing services, multi-tenant platforms, CI/CD systems, and applications with user-influenced connection settings.
• Use software composition analysis and artifact scanning to find affected pgjdbc versions 42.2.0 through 42.7.10 in source repositories, build outputs, containers, and deployed runtimes.
• Restrict outbound database connectivity so application workloads can only reach approved PostgreSQL hosts and ports.
• Review application features, admin tools, import connectors, test-connection functions, and configuration workflows that allow users or operators to supply JDBC URLs or database hostnames.
• Require TLS server identity validation for PostgreSQL connections where feasible to reduce malicious-server and interception scenarios.
• Tune connection pools to avoid unbounded connection creation and aggressive retry storms during authentication failures.
• Create monitoring for abnormal CPU saturation correlated with PostgreSQL authentication failures, connection timeouts, or repeated database reconnect attempts.
• Because this CVE is not currently in KEV, has no known mature public exploit, and has low stable EPSS, handle through expedited dependency management rather than emergency incident response unless exposure to untrusted database endpoints exists.