Postgresql Jdbc Driver
Approved changes feed: RSS · Atom
cpe:2.3:a:postgresql:postgresql_jdbc_driver:*:*:*:*:*:*:*:*
part: a version: * update: *
| Vendor | Postgresql (17ae1743-f0f5-50ae-b0e9-670248233cae) |
|---|---|
| Product | Postgresql Jdbc Driver (fb6c65cc-1f38-5b45-a8eb-8ea81a9737d8) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
| Notes | Imported from purl2cpe mapping |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
pkg:github/pgjdbc/pgjdbc |
purl2cpe | 2026-06-01 10:12:17.643576 |
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-42198 |
vulnerable | 2026-06-08 08:03:16.014899 |
pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
HIGH (7.5)
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.
Published: 2026-04-29T15:58:49.174Z
Updated: 2026-07-15T00:58:08.934Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2025-49146 |
vulnerable | 2026-06-08 07:29:12.632631 |
pgjdbc Client Allows Fallback to Insecure Authentication Despite channelBinding=require Configuration
HIGH (8.2)
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.
Published: 2025-06-11T14:32:39.348Z
Updated: 2025-06-11T14:46:17.286Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2024-1597 |
vulnerable | 2026-06-08 06:27:13.703532 |
pgjdbc SQL Injection via line comment generation
CRITICAL (10)
pgjdbc, the PostgreSQL JDBC Driver, allows attacker to inject SQL if using PreferQueryMode=SIMPLE. Note this is not the default. In the default mode there is no vulnerability. A placeholder for a numeric value must be immediately preceded by a minus. There must be a second placeholder for a string value after the first placeholder; both must be on the same line. By constructing a matching string payload, the attacker can inject SQL to alter the query,bypassing the protections that parameterized queries bring against SQL Injection attacks. Versions before 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, and 42.2.28 are affected.
Published: 2024-02-19T12:58:48.620Z
Updated: 2025-11-03T21:52:29.022Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2022-41946 |
vulnerable | 2026-06-08 05:49:28.944209 |
TemporaryFolder on unix-like systems does not limit access to created files in pgjdbc
MEDIUM (4.7)
pgjdbc is an open source postgresql JDBC Driver. In affected versions a prepared statement using either `PreparedStatement.setText(int, InputStream)` or `PreparedStatemet.setBytea(int, InputStream)` will create a temporary file if the InputStream is larger than 2k. This will create a temporary file which is readable by other users on Unix like systems, but not MacOS. 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. Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using. Java 1.7 and higher users: this vulnerability is fixed in 4.5.0. Java 1.6 and lower users: no patch is available. If you are unable to patch, or are stuck running on Java 1.6, specifying the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will mitigate this vulnerability.
Published: 2022-11-23T00:00:00.000Z
Updated: 2025-11-03T21:46:35.067Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2022-31197 |
vulnerable | 2026-06-08 05:43:40.367766 |
SQL Injection in ResultSet.refreshRow() with malicious column names in pgjdbc
HIGH (7.1)
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.
Published: 2022-08-03T00:00:00.000Z
Updated: 2025-11-03T21:46:18.502Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2022-26520 |
vulnerable | 2026-06-08 05:41:52.346210 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2022-21724 |
vulnerable | 2026-06-08 05:40:02.095313 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2020-13692 |
vulnerable | 2026-06-08 05:18:01.014293 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2018-10936 |
vulnerable | 2026-06-08 05:10:37.414125 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.