CVE-2022-31197
SQL Injection in ResultSet.refreshRow() with malicious column names in pgjdbc
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- Low
- User interaction
- Required
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Exploit likelihood
What each source reports
CVE List Score used
7.1
SQL Injection in ResultSet.refreshRow() with malicious column names in pgjdbc
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.
- Record
CVE-2022-31197- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - Weakness
- CWE-89
- Updated
- 2026-11-02
EUVDEUVD-2022-6614
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.
- Record
EUVD-2022-6614- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-r38f-c4h4-hqq2
7.1
PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names
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:
CREATE TABLE refresh_row_example (
id int PRIMARY KEY,
"1 FROM refresh_row_example; SELECT pg_sleep(10); SELECT * " int
);
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. Invoking the ResultSet.refreshRow() on a ResultSet that queried this table, e.g. SELECT * FROM refresh_row, would cause the additional SQL commands such as the SELECT pg_sleep(10) invocation to be executed.
As the multi statement command would contain multiple results, it would not be possible for the attacker to get data directly out of this approach as the ResultSet.refreshRow() method would throw an exception. However, the attacker could execute any arbitrary SQL including inserting the data into another table that could then be read or any other DML / DDL statement.
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.
Patches
Has the problem been patched? What versions should users upgrade to?
Yes, versions 42.2.26, 42.3.7, and 42.4.1 have been released with a fix.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Check that you are not using the ResultSet.refreshRow() method.
If you are, ensure that the code that executes that method does not connect to a database that is controlled by an unauthenticated or malicious user. If your application only connects to its own database with a fixed schema with no DDL permissions, then you will not be affected by this vulnerability as it requires a maliciously crafted schema.
- Record
GHSA-r38f-c4h4-hqq2- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - Weakness
- CWE-89
- Updated
- 2026-11-02
NVD
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.
- Record
CVE-2022-31197- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - CVSS 3.1
- 8.0 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H - Weakness
- CWE-89
- Updated
- 2026-11-02
OSVALPINE-CVE-2022-31197
8.0
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.
- Record
ALPINE-CVE-2022-31197- CVSS 3.1
- 8.0 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H - Updated
- 2026-11-03
OSV
7.1
SQL Injection in ResultSet.refreshRow() with malicious column names in pgjdbc
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.
- Record
CVE-2022-31197- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - Weakness
- CWE-89
- Updated
- 2026-11-02
Show 15 moreShow less
OSVGHSA-r38f-c4h4-hqq2
7.1
PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names
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:
CREATE TABLE refresh_row_example (
id int PRIMARY KEY,
"1 FROM refresh_row_example; SELECT pg_sleep(10); SELECT * " int
);
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. Invoking the ResultSet.refreshRow() on a ResultSet that queried this table, e.g. SELECT * FROM refresh_row, would cause the additional SQL commands such as the SELECT pg_sleep(10) invocation to be executed.
As the multi statement command would contain multiple results, it would not be possible for the attacker to get data directly out of this approach as the ResultSet.refreshRow() method would throw an exception. However, the attacker could execute any arbitrary SQL including inserting the data into another table that could then be read or any other DML / DDL statement.
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.
Patches
Has the problem been patched? What versions should users upgrade to?
Yes, versions 42.2.26, 42.3.7, and 42.4.1 have been released with a fix.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Check that you are not using the ResultSet.refreshRow() method.
If you are, ensure that the code that executes that method does not connect to a database that is controlled by an unauthenticated or malicious user. If your application only connects to its own database with a fixed schema with no DDL permissions, then you will not be affected by this vulnerability as it requires a maliciously crafted schema.
- Record
GHSA-r38f-c4h4-hqq2- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - Weakness
- CWE-89
- Updated
- 2026-11-02
OSVOESA-2022-1835
7.1
postgresql-jdbc security update
PostgreSQL JDBC Driver (PgJDBC for short) allows Java programs to connect to a PostgreSQL database using standard, database independent Java code. Is an open source JDBC driver written in Pure Java (Type 4), and communicates in the PostgreSQL native network protocol.
Security Fix(es):
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-2022-31197)
- Record
OESA-2022-1835- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVRHLW-2026-b44d1f7dac7a0d3d
7.1
Lightwell Security Advisory: postgresql 42.3.3.rhlw-00006
Red Hat Lightwell has released org.postgresql:postgresql 42.3.3.rhlw-00006 with backported fixes for CVE-2022-31197, CVE-2022-41946, CVE-2024-1597, and CVE-2026-42198.
CVE-2022-31197: SQL Injection in ResultSet.refreshRow() with malicious column names in pgjdbc
CVE-2022-41946: TemporaryFolder on unix-like systems does not limit access to created files in pgjdbc
CVE-2024-1597: pgjdbc SQL Injection via line comment generation
CVE-2026-42198: pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
This patched artifact is a drop-in replacement for org.postgresql:postgresql 42.3.3 from Maven Central.
- Record
RHLW-2026-b44d1f7dac7a0d3d- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVRHSA-2023:0318
8.0
Red Hat Security Advisory: postgresql-jdbc security update
- Record
RHSA-2023:0318- CVSS 3.1
- 8.0 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVRLSA-2023:0318
8.0
Moderate: postgresql-jdbc security update
PostgreSQL is an advanced object-relational database management system. The postgresql-jdbc package includes the .jar files needed for Java programs to access a PostgreSQL database.
Security Fix(es):
- postgresql: SQL Injection in ResultSet.refreshRow() with malicious column names (CVE-2022-31197)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
- Record
RLSA-2023:0318- CVSS 3.1
- 8.0 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVUBUNTU-CVE-2022-31197
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.
- Record
UBUNTU-CVE-2022-31197- CVSS 3.1
- 7.1 High
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H - CVSS 3.1
- 8.0 High
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVALSA-2023:0318 No score
Moderate: postgresql-jdbc security update
PostgreSQL is an advanced object-relational database management system. The postgresql-jdbc package includes the .jar files needed for Java programs to access a PostgreSQL database.
Security Fix(es):
- postgresql: SQL Injection in ResultSet.refreshRow() with malicious column names (CVE-2022-31197)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
- Record
ALSA-2023:0318- Updated
- 2026-11-02
OSVBIT-postgresql-jdbc-driver-2022-31197 No score
SQL Injection in ResultSet.refreshRow() with malicious column names in pgjdbc
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.
- Record
BIT-postgresql-jdbc-driver-2022-31197- Updated
- 2026-11-02
OSVCLSA-2025-1764720464 No score
TuxCare security update for org.postgresql:postgresql (2 CVEs)
TuxCare rebuilt org.postgresql:postgresql to address 2 CVEs. Fixed in 42.2.16-tuxcare.2.
- Record
CLSA-2025-1764720464- Updated
- 2026-11-02
OSVDEBIAN-CVE-2022-31197 No score
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.
- Record
DEBIAN-CVE-2022-31197- Updated
- 2026-11-03
OSVopenSUSE-SU-2024:12369-1 No score
postgresql-jdbc-42.2.25-3.1 on GA media
These are all security issues fixed in the postgresql-jdbc-42.2.25-3.1 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2024:12369-1- Updated
- 2026-11-02
OSVSUSE-SU-2022:3537-1 No score
Security update for postgresql-jdbc
This update for postgresql-jdbc fixes the following issues:
- CVE-2022-31197: Fixed SQL injection vulnerability (bsc#1202170).
- Record
SUSE-SU-2022:3537-1- Updated
- 2026-11-02
OSVSUSE-SU-2022:3541-1 No score
Security update for postgresql-jdbc
This update for postgresql-jdbc fixes the following issues:
- CVE-2022-31197: Fixed SQL injection vulnerability (bsc#1202170).
- Record
SUSE-SU-2022:3541-1- Updated
- 2026-11-02
OSVSUSE-SU-2022:3613-1 No score
Security update for postgresql-jdbc
This update for postgresql-jdbc fixes the following issues:
- CVE-2022-31197: Fixed SQL injection vulnerability (bsc#1202170).
- Record
SUSE-SU-2022:3613-1- Updated
- 2026-11-02
OSVSUSE-SU-2022:3705-1 No score
Security update for postgresql-jdbc
This update for postgresql-jdbc fixes the following issues:
- CVE-2022-31197: Fixed SQL injection vulnerability (bsc#1202170).
- Record
SUSE-SU-2022:3705-1- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
org.postgresql:postgresqlMaven |
before 42.2.26 | 42.2.26 |
org.postgresql:postgresqlMaven |
42.4.0 up to 42.4.1 | 42.4.1 |
org.postgresql:postgresqlMaven |
42.3.0 up to 42.3.7 | 42.3.7 |
java-postgresql-jdbcAlpine:v3.16 |
before 42.4.2-r0 | 42.4.2-r0 |
java-postgresql-jdbcAlpine:v3.17 |
before 42.4.2-r0 | 42.4.2-r0 |
java-postgresql-jdbcAlpine:v3.18 |
before 42.4.2-r0 | 42.4.2-r0 |
java-postgresql-jdbcAlpine:v3.19 |
before 42.4.2-r0 | 42.4.2-r0 |
java-postgresql-jdbcAlpine:v3.20 |
before 42.4.2-r0 | 42.4.2-r0 |
java-postgresql-jdbcAlpine:v3.21 |
before 42.4.2-r0 | 42.4.2-r0 |
java-postgresql-jdbcAlpine:v3.22 |
before 42.4.2-r0 | 42.4.2-r0 |
Show 41 moreShow less
| Package | Affected | Fixed |
|---|---|---|
java-postgresql-jdbcAlpine:v3.23 |
before 42.4.2-r0 | 42.4.2-r0 |
java-postgresql-jdbcAlpine:v3.24 |
before 42.4.2-r0 | 42.4.2-r0 |
postgresql-jdbcAlmaLinux:9 |
before 42.2.18-6.el9_1 | 42.2.18-6.el9_1 |
postgresql-jdbc-driverBitnami |
before 42.2.26, 42.3.0 up to 42.3.7, 42.4.0 to 42.4.0 | 42.2.2642.3.7 |
org.postgresql:postgresqlTuxCare:Maven From an advisory covering 2 CVEs |
42.2.16 up to 42.2.16-tuxcare.2, plus listed versions 42.2.16-tuxcare.1 |
42.2.16-tuxcare.2 |
libpgjavaDebian:12 |
before 42.4.1-1 | 42.4.1-1 |
libpgjavaDebian:13 |
before 42.4.1-1 | 42.4.1-1 |
libpgjavaDebian:14 |
before 42.4.1-1 | 42.4.1-1 |
libpgjavaDebian:10 |
before 42.2.5-2+deb10u2, plus listed versions 42.2.5-242.2.5-2+deb10u1 |
42.2.5-2+deb10u2 |
libpgjavaDebian:11 From an advisory covering 3 CVEs |
before 42.2.15-1+deb11u2, plus listed versions 42.2.15-142.2.15-1+deb11u1 |
42.2.15-1+deb11u2 |
org.postgresql:postgresqlMaven |
before 42.2.26, plus listed versions 42.0.042.0.0.jre642.0.0.jre742.1.042.1.0.jre7 Show 45 moreShow less42.1.142.1.1.jre642.1.1.jre742.1.242.1.2.jre642.1.2.jre742.1.342.1.3.jre642.1.3.jre742.1.442.1.4.jre642.1.4.jre742.2.042.2.0.jre642.2.0.jre742.2.142.2.1.jre642.2.1.jre742.2.1042.2.10.jre642.2.10.jre742.2.1142.2.11.jre642.2.11.jre742.2.1242.2.12.jre642.2.12.jre742.2.1342.2.13.jre642.2.13.jre742.2.1442.2.14.jre642.2.14.jre742.2.1542.2.15.jre642.2.15.jre742.2.1642.2.16.jre642.2.16.jre742.2.1742.2.17.jre642.2.17.jre742.2.1842.2.18.jre642.2.18.jre7 |
42.2.26 |
org.postgresql:postgresqlMaven |
42.3.0 up to 42.3.7, plus listed versions 42.3.142.3.242.3.342.3.442.3.542.3.6 |
42.3.7 |
postgresql-jdbcopenEuler:20.03-LTS-SP1 |
before 42.4.1-1.oe1 | 42.4.1-1.oe1 |
postgresql-jdbcopenEuler:20.03-LTS-SP3 |
before 42.4.1-1.oe1 | 42.4.1-1.oe1 |
postgresql-jdbcopenEuler:22.03-LTS |
before 42.4.1-1.oe2203 | 42.4.1-1.oe2203 |
org.postgresql:postgresqlRed Hat Lightwell:Maven From an advisory covering 4 CVEs |
before 42.3.3.rhlw-00006, plus listed versions 42.0.042.0.0.jre642.0.0.jre742.1.042.1.0.jre7 Show 45 moreShow less42.1.142.1.1.jre642.1.1.jre742.1.242.1.2.jre642.1.2.jre742.1.342.1.3.jre642.1.3.jre742.1.442.1.4.jre642.1.4.jre742.2.042.2.0.jre642.2.0.jre742.2.142.2.1.jre642.2.1.jre742.2.1042.2.10.jre642.2.10.jre742.2.1142.2.11.jre642.2.11.jre742.2.1242.2.12.jre642.2.12.jre742.2.1342.2.13.jre642.2.13.jre742.2.1442.2.14.jre642.2.14.jre742.2.1542.2.15.jre642.2.15.jre742.2.1642.2.16.jre642.2.16.jre742.2.1742.2.17.jre642.2.17.jre742.2.1842.2.18.jre642.2.18.jre7 |
42.3.3.rhlw-00006 |
postgresql-jdbcRed Hat:enterprise_linux:9::appstream |
before 0:42.2.18-6.el9_1 | 0:42.2.18-6.el9_1 |
postgresql-jdbcRocky Linux:9 |
before 0:42.2.18-6.el9_1 | 0:42.2.18-6.el9_1 |
postgresql-jdbcSUSE:Linux Enterprise Module for Server Applications 15 SP4 |
before 42.2.25-150400.3.6.1 | 42.2.25-150400.3.6.1 |
postgresql-jdbcopenSUSE:Leap 15.4 |
before 42.2.25-150400.3.6.1 | 42.2.25-150400.3.6.1 |
postgresql-jdbcSUSE:OpenStack Cloud 9 |
before 9.4-3.6.3 | 9.4-3.6.3 |
postgresql-jdbcSUSE:OpenStack Cloud Crowbar 9 |
before 9.4-3.6.3 | 9.4-3.6.3 |
postgresql-jdbcSUSE:Linux Enterprise Server for SAP Applications 12 SP4 |
before 9.4-3.6.3 | 9.4-3.6.3 |
postgresql-jdbcSUSE:Linux Enterprise Server 12 SP2-BCL |
before 9.4-3.6.3 | 9.4-3.6.3 |
postgresql-jdbcSUSE:Linux Enterprise Server 12 SP3-BCL |
before 9.4-3.6.3 | 9.4-3.6.3 |
postgresql-jdbcSUSE:Linux Enterprise Server 12 SP4-LTSS |
before 9.4-3.6.3 | 9.4-3.6.3 |
postgresql-jdbcSUSE:Linux Enterprise Server 12 SP5 |
before 9.4-3.6.3 | 9.4-3.6.3 |
postgresql-jdbcSUSE:Linux Enterprise Server for SAP Applications 12 SP5 |
before 9.4-3.6.3 | 9.4-3.6.3 |
postgresql-jdbcSUSE:Manager Server Module 4.2 |
before 42.2.25-150300.3.8.1 | 42.2.25-150300.3.8.1 |
postgresql-jdbcSUSE:Linux Enterprise Module for Server Applications 15 SP3 |
before 42.2.25-150300.3.8.1 | 42.2.25-150300.3.8.1 |
postgresql-jdbcopenSUSE:Leap 15.3 |
before 42.2.25-150300.3.8.1 | 42.2.25-150300.3.8.1 |
postgresql-jdbcSUSE:Manager Server Module 4.1 |
before 42.2.10-150200.3.11.1 | 42.2.10-150200.3.11.1 |
libpgjavaUbuntu:14.04:LTS |
All versions, plus listed versions 9.2-1002-1 |
None known |
libpgjavaUbuntu:16.04:LTS |
All versions, plus listed versions 9.2-1002-1 |
None known |
libpgjavaUbuntu:Pro:18.04:LTS |
All versions, plus listed versions 9.4.1212-19.4.1212-1ubuntu0.1~esm1 |
None known |
libpgjavaUbuntu:Pro:20.04:LTS |
All versions, plus listed versions 42.2.6-142.2.8-142.2.9-142.2.10-142.2.10-1ubuntu0.1~esm1 |
None known |
libpgjavaUbuntu:22.04:LTS |
All versions, plus listed versions 42.2.23-142.2.24-142.3.1-142.3.2-142.3.3-1 |
None known |
libpgjavaUbuntu:24.04:LTS |
All versions, plus listed versions 42.5.4-142.6.0-242.7.0-142.7.1-142.7.2-1 |
None known |
libpgjavaUbuntu:25.10 |
All versions, plus listed versions 42.7.5-142.7.5-242.7.7-1 |
None known |
libpgjavaUbuntu:26.10 |
All versions, plus listed versions 42.7.10-142.7.11-142.7.12-142.7.13-1 |
None known |
libpgjavaUbuntu:26.04:LTS |
All versions, plus listed versions 42.7.7-142.7.8-142.7.8-242.7.9-142.7.10-1 |
None known |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, facts | ||
| affected, aliases, references | OSV | |
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2022-31197 is a high vulnerability (CVSS 7.1) in Pgjdbc, published August 3, 2022. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 2.35%, the 83rd percentile. Fixed in org.postgresql:postgresql 42.2.26.
References
github.com/pgjdbc/pgjdbc/security/advisories/GHSA-r38f-c4h4-hqq2
github.com/pgjdbc/pgjdbc/commit/739e599d52ad80f8dcd6efedc6157859b1a9d637
lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I6WHUADTZBBQLVHO4YG4XCWDGWBT4LRP
lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UTFE6SV33P5YYU2GNTQZQKQRVR3GYE4S
lists.debian.org/debian-lts-announce/2022/10/msg00009.html
lists.debian.org/debian-lts-announce/2024/12/msg00017.html
Show 54 moreShow less
nvd.nist.gov/vuln/detail/CVE-2022-31197
lists.fedoraproject.org/archives/list/[email protected]/message/I6WHUADTZBBQLVHO4YG4XCWDGWBT4LRP
lists.fedoraproject.org/archives/list/[email protected]/message/UTFE6SV33P5YYU2GNTQZQKQRVR3GYE4S
github.com/advisories/GHSA-r38f-c4h4-hqq2
security.alpinelinux.org/vuln/CVE-2022-31197
access.redhat.com/errata/RHSA-2023:0318
access.redhat.com/security/cve/CVE-2022-31197
bugzilla.redhat.com/2129428
errata.almalinux.org/9/ALSA-2023-0318.html
github.com/CVEProject/cvelistV5/tree/main/cves/2022/31xxx/CVE-2022-31197.json
security-tracker.debian.org/tracker/CVE-2022-31197
github.com/pgjdbc/pgjdbc
openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2022-1835
github.com/CVEProject/cvelistV5/tree/main/cves/2022/41xxx/CVE-2022-41946.json
github.com/pgjdbc/pgjdbc/security/advisories/GHSA-562r-vg33-8x8h
nvd.nist.gov/vuln/detail/CVE-2022-41946
github.com/pgjdbc/pgjdbc/commit/9008dc9aade6dbfe4efafcd6872ebc55f4699cf5
github.com/advisories/GHSA-562r-vg33-8x8h
github.com/CVEProject/cvelistV5/tree/main/cves/2024/1xxx/CVE-2024-1597.json
github.com/pgjdbc/pgjdbc/security/advisories/GHSA-24rp-q3w6-vc56
nvd.nist.gov/vuln/detail/CVE-2024-1597
github.com/advisories/GHSA-24rp-q3w6-vc56
github.com/pgjdbc/pgjdbc/releases/tag/REL42.7.11
security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-42198.json
access.redhat.com/errata/RHSA-2026:19098
access.redhat.com/errata/RHSA-2026:22304
access.redhat.com/errata/RHSA-2026:24348
access.redhat.com/errata/RHSA-2026:25030
access.redhat.com/errata/RHSA-2026:52928
access.redhat.com/errata/RHSA-2026:52929
access.redhat.com/errata/RHSA-2026:52930
access.redhat.com/errata/RHSA-2026:52978
access.redhat.com/errata/RHSA-2026:54532
access.redhat.com/errata/RHSA-2026:59277
access.redhat.com/errata/RHSA-2026:59278
access.redhat.com/errata/RHSA-2026:66488
access.redhat.com/errata/RHSA-2026:66545
access.redhat.com/security/cve/CVE-2026-42198
github.com/CVEProject/cvelistV5/tree/main/cves/2026/42xxx/CVE-2026-42198.json
github.com/pgjdbc/pgjdbc/security/advisories/GHSA-98qh-xjc8-98pq
nvd.nist.gov/vuln/detail/CVE-2026-42198
github.com/advisories/GHSA-98qh-xjc8-98pq
access.redhat.com/security/updates/classification
bugzilla.redhat.com/show_bug.cgi?id=2129428
security.access.redhat.com/data/csaf/v2/advisories/2023/rhsa-2023_0318.json
cve.org/CVERecord?id=CVE-2022-31197
errata.rockylinux.org/RLSA-2023:0318
suse.com/support/update/announcement/2022/suse-su-20223537-1
bugzilla.suse.com/1202170
suse.com/security/cve/CVE-2022-31197
suse.com/support/update/announcement/2022/suse-su-20223541-1
suse.com/support/update/announcement/2022/suse-su-20223613-1
suse.com/support/update/announcement/2022/suse-su-20223705-1
ubuntu.com/security/CVE-2022-31197
Left out here: 218 versions. The JSON record has them.