Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact channelBinding=require connections can be silently downgraded from SCRAM-SHA-256-PLUS (with channel binding) to plain SCRAM-SHA-256 (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash. Examples are Ed25519, Ed448, and post-quantum algorithms. Two issues combine in releases 42.7.4 through 42.7.11: 1. The bundled com.ongres.scram:scram-client (3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as GHSA-p9jg-fcr6-3mhf. 2. pgJDBC does not enforce channelBinding=require where it matters. ScramAuthenticator checks only that the server advertised a -PLUS mechanism; it neither rejects the empty binding nor checks that the negotiated mechanism uses channel binding. The connection…
Recommended action: Upgrade to 42.7.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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,…
Recommended action: Upgrade to 42.7.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When the PostgreSQL JDBC driver is configured with channel binding set to required (default value is prefer), the driver would incorrectly allow connections to proceed with authentication methods that do not support channel binding (such as password, MD5, GSS, or SSPI authentication). This could allow a man-in-the-middle attacker to intercept connections that users believed were protected by channel binding requirements. Patches TBD Workarounds Configure sslMode=verify-full to prevent MITM attacks. References https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-SCRAM-SHA-256 https://datatracker.ietf.org/doc/html/rfc7677 https://datatracker.ietf.org/doc/html/rfc5802
Recommended action: Upgrade to 42.7.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
42.2.2842.5.542.7.242.6.142.4.442.3.9· Vendor fix available
Issue
Impact SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code that has a vulnerable SQL that negates a parameter value. There is no vulnerability in the driver when using the default query mode. Users that do not override the query mode are not impacted. Exploitation To exploit this behavior the following conditions must be met: 1. A placeholder for a numeric value must be immediately preceded by a minus (i.e. -) 1. There must be a second placeholder for a string value after the first placeholder on the same line. 1. Both parameters must be user controlled. The prior behavior of the driver when operating in simple query mode would inline the negative value of the first parameter and cause the resulting line to be treated as a -- SQL comment. That would extend to the beginning of the next parameter and cause the quoting of that parameter to be consumed by the comment line. If that string parameter includes a…
Recommended action: Upgrade to 42.7.2, 42.6.1, 42.5.5 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability PreparedStatement.setText(int, InputStream) and PreparedStatemet.setBytea(int, InputStream) will create a temporary file if the InputStream is larger than 51k Example of vulnerable code: This will create a temporary file which is readable by other users on Unix like systems, but not MacOS. Impact On Unix like systems, the system's temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system. This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability. When analyzing the impact of this vulnerability, here are the important questions to ask: Is the driver running in an environment where the OS has other untrusted users. If yes, and you answered 'yes' to question 1, this vulnerability impacts you. If no, this vulnerability does not…
Recommended action: Upgrade to 42.5.1, 42.4.3, 42.3.8 or 42.2.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? The PGJDBC implementation of the java.sql.ResultRow.refreshRow() method is not performing escaping of column names so a malicious column name that contains a statement terminator, e.g. ;, could lead to SQL injection. This could lead to executing additional SQL commands as the application's JDBC user. User applications that do not invoke the ResultSet.refreshRow() method are not impacted. User application that do invoke that method are impacted if the underlying database that they are querying via their JDBC application may be under the control of an attacker. The attack requires the attacker to trick the user into executing SQL against a table name who's column names would contain the malicious SQL and subsequently invoke the refreshRow() method on the ResultSet. For example: This example has a table with two columns. The name of the second column is crafted to contain a statement terminator followed by additional SQL.…
Recommended action: Upgrade to 42.4.1, 42.3.7 or 42.2.26 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Interaction error in the PostgreSQL JDBC driver before 8.2, when used with a PostgreSQL server with the "standardconformingstrings" option enabled, such as the default configuration of PostgreSQL 9.1, does not properly escape unspecified JDBC statement parameters, which allows remote attackers to perform SQL injection attacks. NOTE: as of 20120330, it was claimed that the upstream developer planned to dispute this issue, but an official dispute has not been posted as of 20121005.
Recommended action: Upgrade to 8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties.
Recommended action: Upgrade to 42.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control. It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system. While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection…
Recommended action: Upgrade to 42.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PostgreSQL JDBC Driver (aka PgJDBC) before 42.2.13 allows XXE.
Recommended action: Upgrade to 42.2.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties. However, the driver did not verify if the class implements the expected interface before instantiating the class. Here's an example attack using an out-of-the-box class from Spring Framework: The first impacted version is REL9.4.1208 (it introduced socketFactory connection property)
Recommended action: Upgrade to 42.3.2 or 42.2.25 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.