WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕Product postgresql jdbc driver✕
Overview 7 matches · 5 in Waratek scope · 2 protected · 1 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
7matches 5in Waratek scope71.4% 2protected28.6% 1exploited14.3% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 2 28.6% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 3 42.9% Outside Waratek scope 2 28.6% Not applicable 0 0.0% Withdrawn CVE 0 0.0%
Critical 0 0.0% High 7 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 2 28.6% partly blocked 0 0.0% not blocked 5 71.4% not established 0 0.0% unrecorded 0 0.0%
Exploited 1 14.3% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 6 85.7%
7 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-54291 High 2026-07-06 No exploit published No public exploit pgjdbc is an open source postgresql JDBC Driver. In releases 42.7.4 through 42.7.11, 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 can trigger the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash, because the bundled com.ongres.scram:scram-client returns an empty byte array instead of failing and pgJDBC ScramAuthenticator checks only that the server advertised a PLUS mechanism, without rejecting the empty binding or checking that the negotiated mechanism uses channel binding. This issue is fixed in version 42.7.12.
CVE-2026-42198 High 2026-04-29 No exploit published No public exploit pgjdbc is an open source postgresql JDBC Driver. From version 42.2.0 to before version 42.7.11, pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. 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 has been patched in version 42.7.11.
CVE-2025-49146 High 2025-06-11 No exploit published No public exploit pgjdbc is an open source postgresql JDBC Driver. From 42.7.4 and until 42.7.7, 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. This vulnerability is fixed in 42.7.7.
CVE-2022-31197 High 2022-08-03 Protected by Waratek Exploited PostgreSQL JDBC Driver (PgJDBC for short) allows Java programs to connect to a PostgreSQL database using standard, database independent Java code. 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. Note that the application's JDBC user and the schema owner need not be the same. A JDBC application that executes as a privileged user querying database schemas owned by potentially malicious less-privileged users would be vulnerable. In that situation it may be possible for the malicious user to craft a schema that causes the application to execute commands as the privileged user. Patched versions will be released as `42.2.26` and `42.4.1`. Users are advised to upgrade. There are no known workarounds for this issue.
CVE-2020-13692 High 2020-06-04 Outside Waratek scope No public exploit PostgreSQL JDBC Driver (aka PgJDBC) before 42.2.13 allows XXE.
CVE-2018-10936 High 2018-08-30 Outside Waratek scope No public exploit A weakness was found in postgresql-jdbc before version 42.2.5. It was possible to provide an SSL Factory and not check the host name if a host name verifier was not provided to the driver. This could lead to a condition where a man-in-the-middle attacker could masquerade as a trusted server by providing a certificate for the wrong host, as long as it was signed by a trusted CA.
CVE-2012-1618 High 2012-10-06 Protected by Waratek No public exploit Interaction error in the PostgreSQL JDBC driver before 8.2, when used with a PostgreSQL server with the "standard_conforming_strings" 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.