Every CVE Search/ Get API key

CVE-2022-31197

SQL Injection in ResultSet.refreshRow() with malicious column names in pgjdbc

7.1 HighFix available

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

2.35%Up 1.5 points since Aug 4, 2022
90%50%10%1%

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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
CVSS 3.1
8.0 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
CVSS 3.1
8.0 HighCVSS: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

Affected packages
PackageAffectedFixed
org.postgresql:postgresql
Maven
before 42.2.26
42.2.26
org.postgresql:postgresql
Maven
42.4.0 up to 42.4.1
42.4.1
org.postgresql:postgresql
Maven
42.3.0 up to 42.3.7
42.3.7
java-postgresql-jdbc
Alpine:v3.16
before 42.4.2-r0
42.4.2-r0
java-postgresql-jdbc
Alpine:v3.17
before 42.4.2-r0
42.4.2-r0
java-postgresql-jdbc
Alpine:v3.18
before 42.4.2-r0
42.4.2-r0
java-postgresql-jdbc
Alpine:v3.19
before 42.4.2-r0
42.4.2-r0
java-postgresql-jdbc
Alpine:v3.20
before 42.4.2-r0
42.4.2-r0
java-postgresql-jdbc
Alpine:v3.21
before 42.4.2-r0
42.4.2-r0
java-postgresql-jdbc
Alpine:v3.22
before 42.4.2-r0
42.4.2-r0
Show 41 moreShow less
Affected packages
PackageAffectedFixed
java-postgresql-jdbc
Alpine:v3.23
before 42.4.2-r0
42.4.2-r0
java-postgresql-jdbc
Alpine:v3.24
before 42.4.2-r0
42.4.2-r0
postgresql-jdbc
AlmaLinux:9
before 42.2.18-6.el9_1
42.2.18-6.el9_1
postgresql-jdbc-driver
Bitnami
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:postgresql
TuxCare: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
libpgjava
Debian:12
before 42.4.1-1
42.4.1-1
libpgjava
Debian:13
before 42.4.1-1
42.4.1-1
libpgjava
Debian:14
before 42.4.1-1
42.4.1-1
libpgjava
Debian:10
before 42.2.5-2+deb10u2, plus listed versions
42.2.5-242.2.5-2+deb10u1
42.2.5-2+deb10u2
libpgjava
Debian: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:postgresql
Maven
before 42.2.26, plus listed versions
42.0.042.0.0.jre642.0.0.jre742.1.042.1.0.jre7
Show 45 moreShow less
42.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:postgresql
Maven
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-jdbc
openEuler:20.03-LTS-SP1
before 42.4.1-1.oe1
42.4.1-1.oe1
postgresql-jdbc
openEuler:20.03-LTS-SP3
before 42.4.1-1.oe1
42.4.1-1.oe1
postgresql-jdbc
openEuler:22.03-LTS
before 42.4.1-1.oe2203
42.4.1-1.oe2203
org.postgresql:postgresql
Red 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 less
42.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-jdbc
Red Hat:enterprise_linux:9::appstream
before 0:42.2.18-6.el9_1
0:42.2.18-6.el9_1
postgresql-jdbc
Rocky Linux:9
before 0:42.2.18-6.el9_1
0:42.2.18-6.el9_1
postgresql-jdbc
SUSE:Linux Enterprise Module for Server Applications 15 SP4
before 42.2.25-150400.3.6.1
42.2.25-150400.3.6.1
postgresql-jdbc
openSUSE:Leap 15.4
before 42.2.25-150400.3.6.1
42.2.25-150400.3.6.1
postgresql-jdbc
SUSE:OpenStack Cloud 9
before 9.4-3.6.3
9.4-3.6.3
postgresql-jdbc
SUSE:OpenStack Cloud Crowbar 9
before 9.4-3.6.3
9.4-3.6.3
postgresql-jdbc
SUSE:Linux Enterprise Server for SAP Applications 12 SP4
before 9.4-3.6.3
9.4-3.6.3
postgresql-jdbc
SUSE:Linux Enterprise Server 12 SP2-BCL
before 9.4-3.6.3
9.4-3.6.3
postgresql-jdbc
SUSE:Linux Enterprise Server 12 SP3-BCL
before 9.4-3.6.3
9.4-3.6.3
postgresql-jdbc
SUSE:Linux Enterprise Server 12 SP4-LTSS
before 9.4-3.6.3
9.4-3.6.3
postgresql-jdbc
SUSE:Linux Enterprise Server 12 SP5
before 9.4-3.6.3
9.4-3.6.3
postgresql-jdbc
SUSE:Linux Enterprise Server for SAP Applications 12 SP5
before 9.4-3.6.3
9.4-3.6.3
postgresql-jdbc
SUSE:Manager Server Module 4.2
before 42.2.25-150300.3.8.1
42.2.25-150300.3.8.1
postgresql-jdbc
SUSE:Linux Enterprise Module for Server Applications 15 SP3
before 42.2.25-150300.3.8.1
42.2.25-150300.3.8.1
postgresql-jdbc
openSUSE:Leap 15.3
before 42.2.25-150300.3.8.1
42.2.25-150300.3.8.1
postgresql-jdbc
SUSE:Manager Server Module 4.1
before 42.2.10-150200.3.11.1
42.2.10-150200.3.11.1
libpgjava
Ubuntu:14.04:LTS
All versions, plus listed versions
9.2-1002-1
None known
libpgjava
Ubuntu:16.04:LTS
All versions, plus listed versions
9.2-1002-1
None known
libpgjava
Ubuntu:Pro:18.04:LTS
All versions, plus listed versions
9.4.1212-19.4.1212-1ubuntu0.1~esm1
None known
libpgjava
Ubuntu: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
libpgjava
Ubuntu: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
libpgjava
Ubuntu: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
libpgjava
Ubuntu:25.10
All versions, plus listed versions
42.7.5-142.7.5-242.7.7-1
None known
libpgjava
Ubuntu:26.10
All versions, plus listed versions
42.7.10-142.7.11-142.7.12-142.7.13-1
None known
libpgjava
Ubuntu: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

History
RecordedChangedSources
affected, facts
affected, aliases, referencesOSV
first indexedCVE 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

Show 54 moreShow less
This page doesn't list everything

Left out here: 218 versions. The JSON record has them.

MoveEnter Open