PostgreSQL JDBC Driver Files

Security

This release fixes two security vulnerabilities.

requireAuth is silently not enforced when the value excludes every authentication method (GHSA-rhp9-mr79-r74h, CVE-2026-107314)

Severity: Moderate (CVSS 5.9) | Affected versions: 42.7.11 – 42.7.13

If the requireAuth connection property excluded all six authentication methods the driver knows (for example requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none) or contained no method at all (for example requireAuth=,), the driver applied no restriction and accepted whatever method the server asked for, including cleartext password. An attacker positioned between the application and the server could use this to request cleartext password authentication and receive the database password.

Unset values, positive lists (such as requireAuth=scram-sha-256) and partial exclusions (such as requireAuth=!password,!md5) were not affected, and neither were deployments that do not set requireAuth.

Behavior after upgrading:

• A value that excludes every method now refuses the connection with SQLState 08004 and the message Authentication method is not allowed by requireAuth (or the channel binding error when channelBinding=require is also set).
• A value that names no method is rejected as an invalid requireAuth value.

Because affected deployments had this value by mistake, and connections worked normally on affected versions, connections with such a value will fail after upgrading. Replace it with a positive list of the methods your server uses, for example requireAuth=scram-sha-256.

Independently of this fix, use sslmode=verify-full with a trusted CA so that an attacker cannot present a substitute server.

Thanks to @manus-pi for finding and reporting this issue.

Driver stores bytes of earlier statements when it pads a value shorter than its declared length (GHSA-f64h-wr5q-3qf3, CVE-2026-107315)

Severity: Moderate (CVSS 5.3) | Affected versions: 42.7.4 – 42.7.13

When an application sent a value shorter than the length it declared, the driver padded the missing bytes with data from earlier messages on the same connection instead of zeros, and the server stored them. The stored value could contain SQL text and parameter values of earlier, unrelated statements (up to 8192 bytes, or 16320 with GSS encryption). On pooled connections, those statements could come from other requests. 42.7.3 and earlier padded with zeros.

This is reachable through the following public API when the declared length is larger than the data:

• PreparedStatement.setObject(int, ByteStreamWriter)
• CopyIn.writeToCopy(ByteStreamWriter) and CopyIn.writeToCopy(byte[], int, int)
• PGCopyOutputStream.write(byte[], int, int) (writes over 64 KiB)
• LargeObject.write(byte[], int, int)
• java.sql.Blob.setBytes(long, byte[], int, int)

Padding is now always zeros. Applications whose declared length always matches the data were not affected. Values stored by an affected version through such a call may already contain leaked data, so you may want to review affected columns. There is no connection property to disable the old behavior; the workaround on older versions is to make the declared length match the data.

Thanks to @vlsi for finding and reporting this issue.

Full Changelog: https://github.com/pgjdbc/pgjdbc/compare/REL42.7.13...REL42.7.14