# PostgreSQL JDBC: a malicious server can hang the client over SCRAM (CVE-2026-42198)

- **Published on:** 2026-06-08
- **Category:** Security
- **Original page:** https://linuxgratis.com/en/articles/rhsa-2026-24348-postgresql-jdbc-scram-dos-cliente-rhel

Red Hat fixes a denial of service in the PostgreSQL JDBC driver on RHEL 10. A hostile server forces a runaway PBKDF2 computation during SCRAM-SHA-256 authentication. CVSS 7.5.

---

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**.

```bash
sudo dnf update postgresql-jdbc
```

If 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](/en/rhel-10-2) page.

## Source

- Red Hat – [RHSA-2026:24348](https://access.redhat.com/errata/RHSA-2026:24348)
- NVD – [CVE-2026-42198](https://nvd.nist.gov/vuln/detail/CVE-2026-42198)