Skip to content

deps: Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#2278

Open
renovate-bot wants to merge 1 commit intoGoogleCloudPlatform:mainfrom
renovate-bot:renovate/maven-org.postgresql-postgresql-vulnerability
Open

deps: Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#2278
renovate-bot wants to merge 1 commit intoGoogleCloudPlatform:mainfrom
renovate-bot:renovate/maven-org.postgresql-postgresql-vulnerability

Conversation

@renovate-bot
Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
org.postgresql:postgresql (source) 42.7.1042.7.11 age confidence
org.postgresql:postgresql (source) 42.7.742.7.11 age confidence

pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS

CVE-2026-42198 / GHSA-98qh-xjc8-98pq

More information

Details

Summary

pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.

Impact

A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count.
With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail.
A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools.

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

This issue affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.

A user is vulnerable when all of the following are true:

  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.

In practice, that can happen in these situations:

  • 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
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • 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
  • 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)

The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.

Patches

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

Workarounds

Until a patched version of pgjdbc is deployed, the following measures reduce exposure:

  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.

  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.

  3. Avoid SCRAM on untrusted or interceptable connection paths.
    For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.

  4. Reduce blast radius operationally.
    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.

  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

pgjdbc/pgjdbc (org.postgresql:postgresql)

v42.7.11

Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    See the Security Advisory for more detail.
    The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • ""
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate-bot renovate-bot requested a review from a team as a code owner May 6, 2026 13:31
@dpebot
Copy link
Copy Markdown
Collaborator

dpebot commented May 6, 2026

/gcbrun

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants