CVE-2026-54291

What it actually does

The flaw affects pgJDBC versions 42.7.4 through 42.7.11 when applications configure PostgreSQL connections with channelBinding=require. Under specific TLS certificate conditions, the driver can accept a downgrade from SCRAM-SHA-256-PLUS, which provides channel binding, to ordinary SCRAM-SHA-256, which does not. This removes the intended cryptographic binding between the TLS session and the database authentication exchange. An attacker who can intercept and manipulate the TLS connection may therefore bypass the protection designed to prevent man-in-the-middle credential relay or session manipulation. The issue is fixed in pgJDBC 42.7.12.

Why it matters to the business

Applications may believe they are enforcing stronger PostgreSQL authentication protections while actually accepting weaker authentication during a network interception scenario. The most likely business risk is compromise or manipulation of database connections in environments where an attacker can position themselves between the application and PostgreSQL, such as hostile networks, compromised routing paths, misconfigured proxies, or malicious infrastructure. Although exploitation requires a privileged network position and specific certificate behavior, the affected driver is widely used in Java applications, so organizations should treat this as an important dependency update for systems relying on channel binding for database connection integrity.

How an attack unfolds

An attacker first obtains a position where they can intercept or influence TLS traffic between a Java application using pgJDBC and a PostgreSQL server. The application must be using an affected pgJDBC release and must be configured with channelBinding=require, expecting SCRAM-SHA-256-PLUS channel binding to prevent man-in-the-middle attacks. The attacker presents or causes use of a TLS certificate whose signature algorithm does not produce a tls-server-end-point channel-binding hash. Due to behavior in the bundled SCRAM client, an empty channel-binding value is returned instead of causing authentication failure. pgJDBC then incorrectly relies on the server advertising a PLUS mechanism rather than verifying that channel binding is actually negotiated and non-empty. As a result, the connection can proceed using SCRAM-SHA-256 without channel binding, silently removing the intended MITM protection. From there, the attacker may relay, tamper with, or observe authentication-related traffic depending on their network position and the surrounding TLS and certificate trust conditions.

How to fix it

Upgrade pgJDBC to version 42.7.12 or later wherever the PostgreSQL JDBC Driver is used. Review direct and transitive Java dependencies for org.postgresql:postgresql versions 42.7.4 through 42.7.11, including dependencies packaged inside application fat JARs, containers, build artifacts, and vendor-provided applications. If immediate upgrade is not possible, reduce exposure by preventing untrusted network paths between applications and PostgreSQL, enforcing strict server certificate validation, avoiding TLS interception on database connections, restricting database connectivity to trusted private networks, and monitoring for unexpected certificate or authentication mechanism changes. Do not rely on channelBinding=require as a complete mitigation until the driver is updated, because this vulnerability specifically undermines that setting in affected versions.

How to confirm the fix worked

Confirm that all deployed Java applications and packaged artifacts use pgJDBC 42.7.12 or later. Validate dependency manifests such as Maven pom.xml, Gradle lockfiles, SBOMs, container image inventories, and runtime classpaths for org.postgresql:postgresql. Test representative database connections with channelBinding=require and verify that connections fail closed when channel binding cannot be established. Where feasible, inspect driver debug output or controlled test traces to confirm SCRAM-SHA-256-PLUS is negotiated with valid channel binding rather than falling back to SCRAM-SHA-256. Also verify that PostgreSQL connections use trusted TLS certificates and are not traversing unauthorized TLS interception points.

Typical attack path

1. Identify a Java application using pgJDBC 42.7.4 through 42.7.11 to connect to PostgreSQL.
2. Confirm or infer that the application uses SCRAM authentication with channelBinding=require.
3. Gain a man-in-the-middle position between the application and the PostgreSQL server, such as through compromised network infrastructure, malicious proxying, DNS/routing manipulation, or control of an intermediate TLS termination path.
4. Trigger a TLS certificate condition where the certificate signature algorithm has no usable tls-server-end-point channel-binding hash.
5. Cause the pgJDBC authentication flow to proceed despite an empty channel-binding value.
6. Downgrade the effective authentication protection from SCRAM-SHA-256-PLUS to SCRAM-SHA-256 without channel binding.
7. Use the resulting loss of MITM protection to relay or interfere with the database authentication/session according to the attacker’s network capabilities.

How to detect it

There is unlikely to be a clear, product-specific exploitation artifact because the issue is a silent authentication downgrade in a client library. Investigations should focus on exposure plus network and authentication anomalies. Review application dependency inventories for pgJDBC 42.7.4 through 42.7.11 and application configuration for channelBinding=require. Examine application logs, JDBC debug logs, PostgreSQL connection logs, TLS inspection logs, proxy logs, DNS logs, and network packet captures around sensitive database connection windows. Look for unexpected use of SCRAM-SHA-256 where SCRAM-SHA-256-PLUS was expected, certificate chains or signature algorithms that changed unexpectedly, database connections routed through unusual hosts, TLS interception appliances, new proxies, or source addresses inconsistent with normal application-to-database paths. If packet capture or TLS metadata is available, compare historical and current certificate fingerprints, issuers, subject names, and negotiated authentication behavior. Treat evidence of unexplained certificate changes, routing changes, or authentication mechanism downgrade on affected pgJDBC versions as suspicious and investigate associated database activity for unauthorized reads, writes, or session anomalies.

• org.postgresql:postgresql:42.7.4
• org.postgresql:postgresql:42.7.5
• org.postgresql:postgresql:42.7.6
• org.postgresql:postgresql:42.7.7
• org.postgresql:postgresql:42.7.8
• org.postgresql:postgresql:42.7.9
• org.postgresql:postgresql:42.7.10
• org.postgresql:postgresql:42.7.11
• postgresql-42.7.4.jar
• postgresql-42.7.5.jar
• postgresql-42.7.6.jar
• postgresql-42.7.7.jar
• postgresql-42.7.8.jar
• postgresql-42.7.9.jar
• postgresql-42.7.10.jar
• postgresql-42.7.11.jar
• channelBinding=require
• SCRAM-SHA-256-PLUS
• SCRAM-SHA-256
• com.ongres.scram

What your security team should do

• Prioritize upgrading org.postgresql:postgresql to 42.7.12 or later in applications that connect to PostgreSQL using SCRAM authentication and channelBinding=require.
• Search software inventories, SBOMs, build systems, container images, and application packages for pgJDBC versions 42.7.4 through 42.7.11.
• Identify high-value applications where a database connection compromise could alter sensitive data, financial records, identity data, audit logs, or operational workflows, and remediate those first.
• Review network paths between application tiers and PostgreSQL servers for unauthorized proxies, TLS interception devices, DNS manipulation risk, or routing exposure.
• Enable or review PostgreSQL, application, and network telemetry for unexpected authentication mechanism changes, unusual TLS certificate attributes, and connection attempts from unexpected intermediaries.
• If using dependency management, pin or constrain pgJDBC to 42.7.12 or later and rebuild affected artifacts rather than only updating source repositories.
• Because this is not currently listed in CISA KEV and has low EPSS, balance urgency with exposure: prioritize internet-adjacent, shared-network, or high-trust database paths over isolated internal-only deployments.