CVE-2026-107314 in pgjdbc
Summary
by MITRE • 10/08/2026
pgjdbc, the PostgreSQL JDBC Driver, versions 42.7.11 through 42.7.13 enforce no restriction when the requireAuth connection property excludes all six authentication methods the driver knows, for example requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none. The driver then accepts any method the server asks for, including cleartext password authentication. A value without a method in it, such as requireAuth=, (a single comma), is affected the same way. An attacker positioned between the application and its server can ask for cleartext password authentication and receive the database password. A positive list such as requireAuth=scram-sha-256, and a partial exclusion such as requireAuth=!password,!md5, are enforced correctly. The property has no default value, so a deployment that does not set it is not affected. 42.7.14 fixes the problem: such a connection is refused with SQLState 08004, and a value without a method in it is rejected as invalid.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The PostgreSQL JDBC Driver versions 42.7.11 through 42.7.13 contain a critical configuration validation flaw related to the requireAuth connection property. This property allows administrators to restrict which authentication methods are permitted during database connections, serving as an essential security control to prevent downgrade attacks and enforce modern cryptographic standards. However, when this property is configured with values that exclude all six known authentication methods or is left empty such as a single comma without any method identifiers the driver fails to apply the intended restrictions. Instead of rejecting the invalid configuration or falling back to secure defaults the driver erroneously accepts any authentication method requested by the PostgreSQL server including cleartext password authentication which transmits credentials in plain text over the network.
This vulnerability stems from an improper input validation logic within the connection negotiation phase. When a client specifies exclusions for all supported methods like md5,
sspi,
none or provides an empty list the internal state machine does not trigger a rejection mechanism. Consequently the driver enters a permissive mode where it defers entirely to server-side authentication requests without applying local policy checks. This behavior contradicts the principle of least privilege and secure defaults as the application effectively bypasses its own security configuration due to this logical error in handling negative constraints or empty sets.
The operational impact is severe for applications relying on this driver version with such configurations. An attacker positioned between the application and the database server can perform a man-in-the-middle attack by intercepting the authentication handshake and forcing the use of cleartext password authentication. Since the driver accepts any method offered by the server in this flawed state it will transmit the user's plaintext credentials to the malicious actor or even back to the legitimate server if manipulated correctly but with the risk that intermediate proxies could capture them. This exposes sensitive database passwords leading to potential unauthorized access data exfiltration and full compromise of the underlying information systems depending on the privileges associated with those accounts.
From a classification perspective this vulnerability aligns with CWE-20 Improper Input Validation as the driver fails to correctly validate the logical outcome of the requireAuth parameter configuration. It also relates to CWE-319 Cleartext Transmission of Sensitive Information because the flaw directly enables the transmission of passwords in an unencrypted format when stronger methods are available and intended by policy. In terms of adversary tactics this scenario facilitates MITM attacks consistent with ATT&CK technique T1557 Adversary-in-the-Middle where attackers intercept communications to steal credentials or manipulate data flows during authentication exchanges.
The vulnerability is not present in deployments that do not explicitly set the requireAuth property as it has no default value and thus does not trigger the flawed logic path involving exclusion lists or empty configurations. However any deployment attempting to harden security by restricting allowed methods via this specific configuration pattern remains at risk until an upgrade occurs. The issue was resolved in version 42.7.14 where the driver now refuses connections with such invalid configurations returning SQLState 08004 indicating connection failure and explicitly rejecting empty method lists as invalid input thereby enforcing strict adherence to defined security policies during authentication negotiation.
To mitigate this risk organizations must immediately upgrade their PostgreSQL JDBC drivers to version 42.7.14 or later if they utilize the requireAuth property for access control hardening. For environments unable to patch immediately it is advisable to audit connection strings and remove any configurations that exclude all methods or leave the list empty ensuring only positive allowlists such as scram-sha-256 are used which have been verified to function correctly in previous versions. Additionally implementing network-level protections like TLS encryption for database connections provides a compensating control by encrypting traffic regardless of the authentication method negotiated reducing the effectiveness of cleartext interception attacks even if the driver flaw were exploited.