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.
This vulnerability carries a HIGH severity rating with a CVSS v3.1 score of 7.1, indicating it can be exploited remotely over the network but requires specific conditions to be met though user interaction is required requiring only low-level privileges . The vulnerability impacts confidentiality (data exposure), integrity (unauthorized modifications), and availability (service disruption) for affected systems. Impacting 3 products from postgresql, from debian, from fedoraproject organizations running these solutions should prioritize assessment and patching.
Reported in 2022, this vulnerability emerged during an era marked by increased sophistication in supply chain attacks, cloud infrastructure vulnerabilities, and software-as-a-service (SaaS) security challenges. Security practices during this period emphasized zero-trust architectures, container security, and API protection.
2022-08-03T19:15:08.630
2025-11-03T22:15:58.603
Modified
CVSSv3.1: 7.1 (HIGH)
| Type | Vendor | Product | Version/Range | Vulnerable? |
|---|---|---|---|---|
| Application | postgresql | postgresql_jdbc_driver | < 42.2.26 | Yes |
| Application | postgresql | postgresql_jdbc_driver | < 42.3.7 | Yes |
| Application | postgresql | postgresql_jdbc_driver | 42.4.0 | Yes |
| Application | postgresql | postgresql_jdbc_driver | 42.4.0 | Yes |
| Application | postgresql | postgresql_jdbc_driver | 42.4.1 | Yes |
| Operating System | debian | debian_linux | 10.0 | Yes |
| Operating System | fedoraproject | fedora | 35 | Yes |
| Operating System | fedoraproject | fedora | 36 | Yes |
SecUtils normalizes and enriches National Vulnerability Database (NVD) records by standardizing vendor and product identifiers, aggregating vulnerability metadata from both NVD and MITRE sources, and providing structured context for security teams. For postgresql's affected products, we extract Common Platform Enumeration (CPE) data, Common Weakness Enumeration (CWE) classifications, CVSS severity metrics, and reference data to enable rapid vulnerability prioritization and asset correlation. This record contains no exploit code, proof-of-concept instructions, or attack methodologies—only defensive intelligence necessary for patch management, risk assessment, and security operations.