When we talk about denial of service, we usually picture a server buckling under a flood of requests. This one works the other way around. The client is what hangs, and the thing hurting it is the very PostgreSQL server it tries to connect to. Red Hat has fixed it on RHEL 10 with RHSA-2026:24348, rated Important.
What actually breaks
The bug lives in pgjdbc, PostgreSQL’s official JDBC driver, and carries CVE-2026-42198. It shows up during SCRAM-SHA-256 authentication, the default method in modern PostgreSQL releases.
SCRAM uses PBKDF2 to derive the password, and the iteration count for that function comes from the server as part of the authentication exchange. The driver accepted it with no upper bound. An attacker-controlled server can advertise an enormous iteration count, and the client grinds through PBKDF2 until it finishes, before it even gets the chance to reject the connection.
A single such connection pins one CPU core at 100%. Fire several in parallel and you exhaust the available cores and leave the connection pool unusable. The loginTimeout parameter does not save you here: the worker thread keeps running the PBKDF2 computation after the timeout expires, so the CPU stays busy.
The weakness is CWE-770 (allocation of resources without limits or throttling). The score is CVSS 7.5 (vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H): availability impact only, with no loss of confidentiality or integrity.
Who it affects
Any Java application that connects to PostgreSQL with pgjdbc and uses SCRAM-SHA-256. Vulnerable versions run from 42.2.0 through 42.7.10, fixed upstream in 42.7.11.
The threat model matters. For this to hit you, the client has to connect to a server an attacker controls or has compromised, or be steered toward a server impersonated by a man in the middle. It is not something a random outsider triggers against you out of the blue; it needs your driver pointed at a hostile endpoint. Even so, in setups where connection strings come from external configuration, multitenancy, or third-party services, the risk is real.
How to protect yourself
On RHEL 10, applying the update is enough: Red Hat ships the fix in postgresql-jdbc 42.7.2-1.el10_2.2.
sudo dnf update postgresql-jdbcIf you manage the dependency directly in your Java project (Maven, Gradle), bump the driver to 42.7.11 or later. Restart your applications so the change takes effect, since the driver loads when the JVM starts.
As a deeper measure, audit where your connection strings point and treat PostgreSQL servers you do not control with suspicion. Until you can patch, restricting outbound connectivity to known database hosts cuts down the exposure.
If you run RHEL, this advisory is part of Red Hat’s early-June security batch; you can find the release context in our Red Hat Enterprise Linux 10.2 page.
Source
- Red Hat – RHSA-2026:24348
- NVD – CVE-2026-42198