CVE-2026-42198: pgjdbc Denial of Service Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-98qh-xjc8-98pq",
  "modified" : "2026-05-05T20:09:36Z",
  "published" : "2026-05-05T20:09:36Z",
  "aliases" : [ "CVE-2026-42198" ],
  "summary" : "pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS",
  "details" : "## Summary\npgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.\n\n### Impact\nA malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count.\nWith a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail.\nA single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools.\n\nIn affected versions, `loginTimeout` did not fully mitigate this problem. When `loginTimeout` expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation.\n\nThis issue affects availability. It does **not** provide authentication bypass, privilege escalation, or direct password disclosure.\n\nA user is vulnerable when **all** of the following are true:\n\n1. The connection uses **SCRAM-SHA-256** authentication.\n2. The client reaches a **malicious, compromised, or attacker-controlled PostgreSQL endpoint**.\n3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the `server-first-message`.\n\nIn practice, that can happen in these situations:\n\n- the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control\n- the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources\n- the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised\n- the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server\n- an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, `/etc/hosts`, environment variables, or similar indirection\n- an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, `sslmode` lower than `verify-full`, or trusting a CA that signs hosts outside the operator's control)\n\nThe issue is **more damaging** when the application uses connection retries, many parallel connection attempts, or `loginTimeout` and assumes the timeout fully stops the work.\n\n### Patches\nThe patch introduces a new connection property, `scramMaxIterations`, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.\n\n### Workarounds\n\nUntil a patched version of pgjdbc is deployed, the following measures reduce exposure:\n\n1. **Only connect to trusted PostgreSQL servers whose identity is verified.**  \n   Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.\n   TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.\n\n2. **Do not rely on `loginTimeout` as a complete mitigation on unpatched versions.**  \n   On affected versions, `loginTimeout` can stop the waiting caller while the worker thread continues spending CPU.\n\n3. **Avoid SCRAM on untrusted or interceptable connection paths.**  \n   For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.\n\n4. **Reduce blast radius operationally.**  \n   Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.\n\n5. **On trusted servers you control, keep SCRAM iteration counts at ordinary values.**  \n   This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Maven",
      "name" : "org.postgresql:postgresql"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "42.2.0"
      }, {
        "fixed" : "42.7.11"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/pgjdbc/pgjdbc/security/advisories/GHSA-98qh-xjc8-98pq"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-42198"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/pgjdbc/pgjdbc"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/pgjdbc/pgjdbc/releases/tag/REL42.7.11"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-770" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-05T20:09:36Z",
    "nvd_published_at" : "2026-04-29T16:16:25Z"
  }
}