pgjdbc vulnerabilities

The PostgreSQL JDBC Driver (pgjdbc) versions 42.7.4 through 42.7.13 pads a value shorter than its declared length with bytes left in its send buffer instead of zeros, and the server stores those bytes as part of the value. These bytes are messages the driver sent earlier on the same connection: SQL text and parameter values of recent statements, which on a pooled connection can come from other requests. Each padded value can carry up to 8192 bytes of this traffic, or 16320 bytes with GSS encryption. The padding occurs when an application declares a length larger than the data it supplies through certain APIs. An attacker who can make the application store such a value and read it back can collect earlier traffic. Applications whose declared lengths always match their data are not affected. Versions 42.7.3 and earlier pad with zeros.

In pgjdbc (PostgreSQL JDBC Driver) versions 42.7.11 through 42.7.13, the requireAuth property does not enforce restrictions when it excludes all known authentication methods (e.g., requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none). The driver then accepts any method the server asks for, including cleartext password authentication. An attacker in a man-in-the-middle position can capture the database password. Version 42.7.14 fixes the issue.

The pgjdbc PostgreSQL JDBC driver versions 42.7.4 through 42.7.11 allow silent downgrade of SCRAM-SHA-256-PLUS with channel binding to plain SCRAM-SHA-256. A man-in-the-middle attacker can exploit a certificate lacking the proper channel binding hash to trigger the downgrade and bypass protection.

The pgjdbc PostgreSQL JDBC driver versions 42.2.0 through 42.7.10 is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. A malicious server can force the driver to perform PBKDF2 with an extremely large iteration count, causing excessive CPU consumption and potentially wedging connection pools. The loginTimeout parameter did not fully mitigate the issue, as the worker thread continued computation even after the timeout expired.