CVE-2026-42198
Denial of Service in pgjdbc via SCRAM-SHA-256 Authentication
Publication date: 2026-04-29
Last updated on: 2026-05-01
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| postgresql | postgresql_jdbc_driver | From 42.2.0 (inc) to 42.7.11 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability affects the pgjdbc PostgreSQL JDBC Driver versions from 42.2.0 up to but not including 42.7.11. It is a client-side denial of service issue that occurs during SCRAM-SHA-256 authentication. A malicious server can cause the client to perform SCRAM authentication with an extremely large iteration count, which forces the client to spend an unbounded amount of CPU time computing PBKDF2 before the authentication fails.
Because of this, a single authentication attempt can tie up a CPU core, and repeated or concurrent attempts can exhaust the client's CPU resources and cause connection pools to become unresponsive. The loginTimeout setting does not fully mitigate this issue because even after the timeout expires, the worker thread performing the authentication continues to consume CPU.
This vulnerability was fixed in version 42.7.11 of the pgjdbc driver.
How can this vulnerability impact me? :
This vulnerability can cause a denial of service on the client side by exhausting CPU resources during the authentication process. Specifically, a malicious PostgreSQL server can force the client to perform expensive computations that consume a CPU core indefinitely.
As a result, your application or service using the affected pgjdbc driver may experience degraded performance, unresponsive connection pools, or complete inability to establish new database connections.
This can lead to service disruptions, increased latency, and potential downtime until the issue is resolved or the driver is updated to a patched version.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, upgrade the pgjdbc PostgreSQL JDBC Driver to version 42.7.11 or later, where the issue has been patched.
Note that the loginTimeout setting does not fully mitigate the problem, as the worker thread performing the connection attempt may continue consuming CPU even after timeout.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in pgjdbc allows a malicious server to cause a client-side denial of service by forcing excessive CPU usage during SCRAM-SHA-256 authentication. This results in availability issues due to CPU exhaustion and potential connection pool wedging.
While this impacts the availability aspect of systems using the affected driver versions, there is no direct information indicating an impact on confidentiality or integrity of data.
Therefore, this vulnerability could affect compliance with standards and regulations that require maintaining system availability, such as HIPAA's availability requirements or GDPR's requirement to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems. However, no explicit linkage to compliance impact is provided.
Can you explain this vulnerability to me?
CVE-2026-42198 is a client-side denial of service vulnerability in the PostgreSQL JDBC driver (pgjdbc) affecting versions from 42.2.0 to before 42.7.11.
A malicious or compromised PostgreSQL server can exploit this vulnerability by instructing the client to perform SCRAM-SHA-256 authentication with an extremely large PBKDF2 iteration count.
This causes the client to consume excessive CPU resources during the authentication process, potentially tying up a CPU core indefinitely and exhausting connection pools.
The default loginTimeout setting does not fully mitigate the issue because the worker thread performing the authentication can continue consuming CPU even after the timeout expires.
The vulnerability was fixed in version 42.7.11 by introducing a new connection property, scramMaxIterations, which limits the maximum iteration count to prevent unbounded CPU usage.
How can this vulnerability impact me? :
This vulnerability can cause a denial of service on the client side by exhausting CPU resources during the SCRAM-SHA-256 authentication process.
- A single authentication attempt with a very large iteration count can tie up a CPU core indefinitely.
- Repeated or concurrent attempts can exhaust CPU capacity and wedge connection pools, leading to system unavailability.
- The issue affects system availability but does not allow authentication bypass, privilege escalation, or password disclosure.
This means your applications relying on pgjdbc could become unresponsive or unable to establish new database connections if exposed to a malicious or compromised PostgreSQL server.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as excessive CPU usage on the client side during SCRAM-SHA-256 authentication with PostgreSQL servers. Detection involves monitoring CPU usage spikes on systems running affected pgjdbc versions when connecting to PostgreSQL servers.
Since the vulnerability is triggered by a malicious server specifying a very large PBKDF2 iteration count, you can detect suspicious authentication attempts by analyzing connection logs or network traffic for unusual SCRAM authentication parameters.
There are no specific commands provided in the resources to detect this vulnerability directly, but general approaches include:
- Monitor CPU usage on clients running pgjdbc versions between 42.2.0 and before 42.7.11 during database connection attempts.
- Inspect PostgreSQL server logs or network captures for SCRAM-SHA-256 authentication exchanges with unusually high iteration counts.
- Use system monitoring tools (e.g., top, htop on Linux) to identify processes consuming excessive CPU during authentication.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade the pgjdbc driver to version 42.7.11 or later, where the vulnerability is patched.
This patched version introduces a new connection property called scramMaxIterations, which limits the PBKDF2 iteration count to 100,000 by default, preventing unbounded CPU consumption.
Until you can upgrade, recommended immediate mitigations include:
- Connect only to trusted PostgreSQL servers with verified identities to avoid malicious servers.
- Avoid using SCRAM authentication over untrusted networks or proxies where server impersonation is possible.
- Implement operational limits on connection attempts to reduce the risk of repeated CPU exhaustion.