[dependabot]

Bumps the production group with 9 updates:

Package	From	To
gradle-wrapper	9.8.0	9.8.1
org.jetbrains.kotlin:kotlin-gradle-plugin	2.4.20	2.4.21
org.jetbrains.exposed:exposed-core	1.5.0	1.5.1
org.jetbrains.exposed:exposed-jdbc	1.5.0	1.5.1
org.jetbrains.exposed:exposed-json	1.5.0	1.5.1
org.jetbrains.exposed:exposed-java-time	1.5.0	1.5.1
org.jetbrains.exposed:spring7-transaction	1.5.0	1.5.1
org.postgresql:postgresql	42.7.13	42.7.14
org.hibernate.orm:hibernate-core	7.4.12.Final	7.4.13.Final

Updates gradle-wrapper from 9.8.0 to 9.8.1

Release notes

Sourced from gradle-wrapper's releases.

9.8.1

This is a patch release for Gradle 9.8.0. We recommend using 9.8.1 instead of 9.8.0.

This release addresses three high rated vulnerabilities:

• Unauthenticated worker-to-daemon channel deserializes untrusted Java objects
• Deserialization of untrusted Java objects before authentication in the client - daemon communication
• Failure to disable repositories failing to establish an SSL connection can expose builds to malicious artifacts

The following issues were resolved:

• [Gradle 9.8.0 complains again about invalid Toolchains on Debian / Ubuntu packaged systems]- (gradle/gradle#39358)
• Gradle 9.8.0 removes root java.util.logging handlers installed by a custom LogManager (breaks Quarkus test log capture)
• Dependency resolution regression

Read the Release Notes

We would like to thank the following community members for their contributions to this release of Gradle: Aman Gautam, Björn Kautler, Eng Zer Jun, Hashim Khan, Julian Krannich, KBS, Labh R Jethe, Mark Dodgson, Maxim, monkey, nataphon-ktsystems, Paul King, Qiu Tian, rg_sandesh, Roberto Perez Alcolea, Sean, Zongle Wang.

Upgrade instructions

Switch your build to use Gradle 9.8.1 by updating your wrapper:

./gradlew :wrapper --gradle-version=9.8.1 && ./gradlew :wrapper

See the Gradle 9.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading.

For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.

Reporting problems

If you find a problem with this release, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure you're encountering a bug, please use the forum.

... (truncated)

Commits

• 39daf39 Release notes for Gradle 9.8.1 (#39409)
• 4fc92e5 Release notes for Gradle 9.8.1
• bfbd14a Make repository disabling stricter (#39403)
• 95e0bf9 Check daemon & worker preamble earlier (#39402)
• 7aa9a5b Improve display for distribution url in wrapper (#39401)
• 74a7720 Wrap GCP & S3 resolution errors into HTTP to reuse repository disabling mecha...
• 651110a Check worker token before any serialization similarly to daemon
• 8a6b9d9 Harden repository disabling: disable them by default on failure unless there'...
• f28e514 Check the daemon token before any serialization
• 86ab273 Replace credentials for distribution url with *** and avoid showing the plain...
• Additional commits viewable in compare view

Updates org.jetbrains.kotlin:kotlin-gradle-plugin from 2.4.20 to 2.4.21

Release notes

Sourced from org.jetbrains.kotlin:kotlin-gradle-plugin's releases.

Kotlin 2.4.21

Changelog

Backend. Wasm

• KT-89267 K/Wasm: calling a (T) -> R lambda with an argument that isn't a T traps instead of throwing ClassCastException

JVM. Reflection

• KT-89280 NoSuchElementException in argumentsMakeSenseOnlyForMutableContainer for Java non-static inner class of generic outer class
• KT-80710 Reflection: change KCallable representation to avoid dependency on K1

JavaScript

• KT-89449 Kotlin/JS: Member names no longer minified in production
• KT-89363 KJS. Regular class with companion can't extend external class

Tools. Compiler plugins. Serialization

• KT-89275 Kotlin/Wasm: Invalid Wasm is emitted for a @Serializable generic class with a class upper bound

Tools. Gradle. Native

• KT-89285 SwiftPM import results in flooded log
• KT-86251 K/N: Flaky linkDebugTestLinuxX64 failure with "truncated or malformed archive" on libstdlib-cache.a

Tools. Scripts

• KT-89247 Kotlin Script: NoClassDefFoundError on 2nd execution with transitive dependency from imported script
• KT-89220 JSR-223: generic Java bindings break all subsequent eval() calls
• KT-88458 Audit closeable resource usage
• KT-88453 VirtualFileScriptSource.text leaks an unclosed file stream — script source file handle held until GC, blocks file deletion on Windows

Kotlin 2.4.21-RC

Changelog

Backend. Wasm

• KT-89267 K/Wasm: calling a (T) -> R lambda with an argument that isn't a T traps instead of throwing ClassCastException

JVM. Reflection

• KT-89280 NoSuchElementException in argumentsMakeSenseOnlyForMutableContainer for Java non-static inner class of generic outer class
• KT-80710 Reflection: change KCallable representation to avoid dependency on K1

JavaScript

• KT-89449 Kotlin/JS: Member names no longer minified in production
• KT-89363 KJS. Regular class with companion can't extend external class

... (truncated)

Changelog

Sourced from org.jetbrains.kotlin:kotlin-gradle-plugin's changelog.

2.4.21

Backend. Wasm

• KT-89267 K/Wasm: calling a (T) -> R lambda with an argument that isn't a T traps instead of throwing ClassCastException

JVM. Reflection

• KT-89280 NoSuchElementException in argumentsMakeSenseOnlyForMutableContainer for Java non-static inner class of generic outer class
• KT-80710 Reflection: change KCallable representation to avoid dependency on K1

JavaScript

• KT-89449 Kotlin/JS: Member names no longer minified in production
• KT-89363 KJS. Regular class with companion can't extend external class

Tools. Compiler plugins. Serialization

• KT-89275 Kotlin/Wasm: Invalid Wasm is emitted for a @Serializable generic class with a class upper bound

Tools. Gradle. Native

• KT-89285 SwiftPM import results in flooded log
• KT-86251 K/N: Flaky linkDebugTestLinuxX64 failure with "truncated or malformed archive" on libstdlib-cache.a

Tools. Scripts

• KT-89247 Kotlin Script: NoClassDefFoundError on 2nd execution with transitive dependency from imported script
• KT-89220 JSR-223: generic Java bindings break all subsequent eval() calls
• KT-88458 Audit closeable resource usage
• KT-88453 VirtualFileScriptSource.text leaks an unclosed file stream — script source file handle held until GC, blocks file deletion on Windows

Commits

• 9180ce6 Add changelog for 2.4.21-RC
• 851077b [Serialization] Copy type parameter bounds onto generated serializers (#8421)
• 1b6b624 [Wasm]: Generate a Kotlin-level cast for bridged lambda functions. (#8404)
• 3c223c2 Rrr/2.4.20/core docs (#8322)
• c681c2e [2.4.20] [KT-89285] Stop the xcodebuild logs being output by default (#8277)
• f0645d1 [2.4.20] [JS] Reorder CompilerConfiguration properties initialization (#8282)
• f507ecd [JS] Don't try to initialize an external class's companion object
• c60d7d8 Reflection: fix NoSuchElementException in ConvertFromJava.kt
• 05d1cde REPL: render correct reflected binding type
• 5acec47 Scripting: store collected dependencies recursively
• Additional commits viewable in compare view

Updates org.jetbrains.exposed:exposed-core from 1.5.0 to 1.5.1

Release notes

Sourced from org.jetbrains.exposed:exposed-core's releases.

1.5.1

Change log

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093

New Contributors

• @​kwy404 made their first contribution in JetBrains/Exposed#2888

Changelog

Sourced from org.jetbrains.exposed:exposed-core's changelog.

1.5.1

Security:

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093 below

Bug fixes:

• fix: EXPOSED-909 Escape single quotes in locate() substring by @​kwy404 in JetBrains/Exposed#2946
• fix: EXPOSED-1093 Bind string arguments of SQL functions instead of concatenating them into SQL by @​obabichevjb in JetBrains/Exposed#2957
  • The string arguments of locate(), concat(), groupConcat(), match() and the JSON extract(), exists() and contains() are now bound as query parameters, so they are always treated as data.
  • Where a database does not accept a parameter in that position, the argument is written into the statement as a string literal with its single quotes escaped instead:
    • Oracle: the JSON path of extract() and exists()
    • SQL Server: the separator of groupConcat()
  • These arguments must be passed as is. A value that was escaped on the client side, for example with its single quotes doubled, now reaches the database with the escaping intact.

Commits

• b4039ac chore: Bump Exposed version from 1.5.0 to 1.5.1
• 4cf829b fix: EXPOSED-1093 Bind string arguments instead of concatenating them into SQ...
• 3689785 fix: EXPOSED-909 Escape single quotes in locate() substring (#2946)
• See full diff in compare view

Updates org.jetbrains.exposed:exposed-jdbc from 1.5.0 to 1.5.1

Release notes

Sourced from org.jetbrains.exposed:exposed-jdbc's releases.

1.5.1

Change log

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093

New Contributors

• @​kwy404 made their first contribution in JetBrains/Exposed#2888

Changelog

Sourced from org.jetbrains.exposed:exposed-jdbc's changelog.

1.5.1

Security:

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093 below

Bug fixes:

• fix: EXPOSED-909 Escape single quotes in locate() substring by @​kwy404 in JetBrains/Exposed#2946
• fix: EXPOSED-1093 Bind string arguments of SQL functions instead of concatenating them into SQL by @​obabichevjb in JetBrains/Exposed#2957
  • The string arguments of locate(), concat(), groupConcat(), match() and the JSON extract(), exists() and contains() are now bound as query parameters, so they are always treated as data.
  • Where a database does not accept a parameter in that position, the argument is written into the statement as a string literal with its single quotes escaped instead:
    • Oracle: the JSON path of extract() and exists()
    • SQL Server: the separator of groupConcat()
  • These arguments must be passed as is. A value that was escaped on the client side, for example with its single quotes doubled, now reaches the database with the escaping intact.

Commits

• b4039ac chore: Bump Exposed version from 1.5.0 to 1.5.1
• 4cf829b fix: EXPOSED-1093 Bind string arguments instead of concatenating them into SQ...
• 3689785 fix: EXPOSED-909 Escape single quotes in locate() substring (#2946)
• See full diff in compare view

Updates org.jetbrains.exposed:exposed-json from 1.5.0 to 1.5.1

Release notes

Sourced from org.jetbrains.exposed:exposed-json's releases.

1.5.1

Change log

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093

New Contributors

• @​kwy404 made their first contribution in JetBrains/Exposed#2888

Changelog

Sourced from org.jetbrains.exposed:exposed-json's changelog.

1.5.1

Security:

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093 below

Bug fixes:

• fix: EXPOSED-909 Escape single quotes in locate() substring by @​kwy404 in JetBrains/Exposed#2946
• fix: EXPOSED-1093 Bind string arguments of SQL functions instead of concatenating them into SQL by @​obabichevjb in JetBrains/Exposed#2957
  • The string arguments of locate(), concat(), groupConcat(), match() and the JSON extract(), exists() and contains() are now bound as query parameters, so they are always treated as data.
  • Where a database does not accept a parameter in that position, the argument is written into the statement as a string literal with its single quotes escaped instead:
    • Oracle: the JSON path of extract() and exists()
    • SQL Server: the separator of groupConcat()
  • These arguments must be passed as is. A value that was escaped on the client side, for example with its single quotes doubled, now reaches the database with the escaping intact.

Commits

• b4039ac chore: Bump Exposed version from 1.5.0 to 1.5.1
• 4cf829b fix: EXPOSED-1093 Bind string arguments instead of concatenating them into SQ...
• 3689785 fix: EXPOSED-909 Escape single quotes in locate() substring (#2946)
• See full diff in compare view

Updates org.jetbrains.exposed:exposed-java-time from 1.5.0 to 1.5.1

Release notes

Sourced from org.jetbrains.exposed:exposed-java-time's releases.

1.5.1

Change log

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093

New Contributors

• @​kwy404 made their first contribution in JetBrains/Exposed#2888

Changelog

Sourced from org.jetbrains.exposed:exposed-java-time's changelog.

1.5.1

Security:

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093 below

Bug fixes:

• fix: EXPOSED-909 Escape single quotes in locate() substring by @​kwy404 in JetBrains/Exposed#2946
• fix: EXPOSED-1093 Bind string arguments of SQL functions instead of concatenating them into SQL by @​obabichevjb in JetBrains/Exposed#2957
  • The string arguments of locate(), concat(), groupConcat(), match() and the JSON extract(), exists() and contains() are now bound as query parameters, so they are always treated as data.
  • Where a database does not accept a parameter in that position, the argument is written into the statement as a string literal with its single quotes escaped instead:
    • Oracle: the JSON path of extract() and exists()
    • SQL Server: the separator of groupConcat()
  • These arguments must be passed as is. A value that was escaped on the client side, for example with its single quotes doubled, now reaches the database with the escaping intact.

Commits

• b4039ac chore: Bump Exposed version from 1.5.0 to 1.5.1
• 4cf829b fix: EXPOSED-1093 Bind string arguments instead of concatenating them into SQ...
• 3689785 fix: EXPOSED-909 Escape single quotes in locate() substring (#2946)
• See full diff in compare view

Updates org.jetbrains.exposed:spring7-transaction from 1.5.0 to 1.5.1

Release notes

Sourced from org.jetbrains.exposed:spring7-transaction's releases.

1.5.1

Change log

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093

New Contributors

• @​kwy404 made their first contribution in JetBrains/Exposed#2888

Changelog

Sourced from org.jetbrains.exposed:spring7-transaction's changelog.

1.5.1

Security:

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093 below

Bug fixes:

• fix: EXPOSED-909 Escape single quotes in locate() substring by @​kwy404 in JetBrains/Exposed#2946
• fix: EXPOSED-1093 Bind string arguments of SQL functions instead of concatenating them into SQL by @​obabichevjb in JetBrains/Exposed#2957
  • The string arguments of locate(), concat(), groupConcat(), match() and the JSON extract(), exists() and contains() are now bound as query parameters, so they are always treated as data.
  • Where a database does not accept a parameter in that position, the argument is written into the statement as a string literal with its single quotes escaped instead:
    • Oracle: the JSON path of extract() and exists()
    • SQL Server: the separator of groupConcat()
  • These arguments must be passed as is. A value that was escaped on the client side, for example with its single quotes doubled, now reaches the database with the escaping intact.

Commits

• b4039ac chore: Bump Exposed version from 1.5.0 to 1.5.1
• 4cf829b fix: EXPOSED-1093 Bind string arguments instead of concatenating them into SQ...
• 3689785 fix: EXPOSED-909 Escape single quotes in locate() substring (#2946)
• See full diff in compare view

Updates org.jetbrains.exposed:exposed-jdbc from 1.5.0 to 1.5.1

Release notes

Sourced from org.jetbrains.exposed:exposed-jdbc's releases.

1.5.1

Change log

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093

New Contributors

• @​kwy404 made their first contribution in JetBrains/Exposed#2888

Changelog

Sourced from org.jetbrains.exposed:exposed-jdbc's changelog.

1.5.1

Security:

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093 below

Bug fixes:

• fix: EXPOSED-909 Escape single quotes in locate() substring by @​kwy404 in JetBrains/Exposed#2946
• fix: EXPOSED-1093 Bind string arguments of SQL functions instead of concatenating them into SQL by @​obabichevjb in JetBrains/Exposed#2957
  • The string arguments of locate(), concat(), groupConcat(), match() and the JSON extract(), exists() and contains() are now bound as query parameters, so they are always treated as data.
  • Where a database does not accept a parameter in that position, the argument is written into the statement as a string literal with its single quotes escaped instead:
    • Oracle: the JSON path of extract() and exists()
    • SQL Server: the separator of groupConcat()
  • These arguments must be passed as is. A value that was escaped on the client side, for example with its single quotes doubled, now reaches the database with the escaping intact.

Commits

• b4039ac chore: Bump Exposed version from 1.5.0 to 1.5.1
• 4cf829b fix: EXPOSED-1093 Bind string arguments instead of concatenating them into SQ...
• 3689785 fix: EXPOSED-909 Escape single quotes in locate() substring (#2946)
• See full diff in compare view

Updates org.jetbrains.exposed:exposed-json from 1.5.0 to 1.5.1

Release notes

Sourced from org.jetbrains.exposed:exposed-json's releases.

1.5.1

Change log

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093

New Contributors

• @​kwy404 made their first contribution in JetBrains/Exposed#2888

Changelog

Sourced from org.jetbrains.exposed:exposed-json's changelog.

1.5.1

Security:

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093 below

Bug fixes:

• fix: EXPOSED-909 Escape single quotes in locate() substring by @​kwy404 in JetBrains/Exposed#2946
• fix: EXPOSED-1093 Bind string arguments of SQL functions instead of concatenating them into SQL by @​obabichevjb in JetBrains/Exposed#2957
  • The string arguments of locate(), concat(), groupConcat(), match() and the JSON extract(), exists() and contains() are now bound as query parameters, so they are always treated as data.
  • Where a database does not accept a parameter in that position, the argument is written into the statement as a string literal with its single quotes escaped instead:
    • Oracle: the JSON path of extract() and exists()
    • SQL Server: the separator of groupConcat()
  • These arguments must be passed as is. A value that was escaped on the client side, for example with its single quotes doubled, now reaches the database with the escaping intact.

Commits

• b4039ac chore: Bump Exposed version from 1.5.0 to 1.5.1
• 4cf829b fix: EXPOSED-1093 Bind string arguments instead of concatenating them into SQ...
• 3689785 fix: EXPOSED-909 Escape single quotes in locate() substring (#2946)
• See full diff in compare view

Updates org.jetbrains.exposed:exposed-java-time from 1.5.0 to 1.5.1

Release notes

Sourced from org.jetbrains.exposed:exposed-java-time's releases.

1.5.1

Change log

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093

New Contributors

• @​kwy404 made their first contribution in JetBrains/Exposed#2888

Changelog

Sourced from org.jetbrains.exposed:exposed-java-time's changelog.

1.5.1

Security:

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093 below

Bug fixes:

• fix: EXPOSED-909 Escape single quotes in locate() substring by @​kwy404 in JetBrains/Exposed#2946
• fix: EXPOSED-1093 Bind string arguments of SQL functions instead of concatenating them into SQL by @​obabichevjb in JetBrains/Exposed#2957
  • The string arguments of locate(), concat(), groupConcat(), match() and the JSON extract(), exists() and contains() are now bound as query parameters, so they are always treated as data.
  • Where a database does not accept a parameter in that position, the argument is written into the statement as a string literal with its single quotes escaped instead:
    • Oracle: the JSON path of extract() and exists()
    • SQL Server: the separator of groupConcat()
  • These arguments must be passed as is. A value that was escaped on the client side, for example with its single quotes doubled, now reaches the database with the escaping intact.

Commits

• b4039ac chore: Bump Exposed version from 1.5.0 to 1.5.1
• 4cf829b fix: EXPOSED-1093 Bind string arguments instead of concatenating them into SQ...
• 3689785 fix: EXPOSED-909 Escape single quotes in locate() substring (#2946)
• See full diff in compare view

Updates org.jetbrains.exposed:spring7-transaction from 1.5.0 to 1.5.1

Release notes

Sourced from org.jetbrains.exposed:spring7-transaction's releases.

1.5.1

Change log

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093

New Contributors

• @​kwy404 made their first contribution in JetBrains/Exposed#2888

Changelog

Sourced from org.jetbrains.exposed:spring7-transaction's changelog.

1.5.1

Security:

• Fixes CVE-2026-108474: SQL injection through the string arguments of SQL functions, fixed by EXPOSED-1093 below

Bug fixes:

• fix: EXPOSED-909 Escape single quotes in locate() substring by @​kwy404 in JetBrains/Exposed#2946
• fix: EXPOSED-1093 Bind string arguments of SQL functions instead of concatenating them into SQL by @​obabichevjb in JetBrains/Exposed#2957
  • The string arguments of locate(), concat(), groupConcat(), match() and the JSON extract(), exists() and contains() are now bound as query parameters, so they are always treated as data.
  • Where a database does not accept a parameter in that position, the argument is written into the statement as a string literal with its single quotes escaped instead:
    • Oracle: the JSON path of extract() and exists()
    • SQL Server: the separator of groupConcat()
  • These arguments must be passed as is. A value that was escaped on the client side, for example with its single quotes doubled, now reaches the database with the escaping intact.

Commits

• b4039ac chore: Bump Exposed version from 1.5.0 to 1.5.1
• 4cf829b fix: EXPOSED-1093 Bind string arguments instead of concatenating them into SQ...
• 3689785 fix: EXPOSED-909 Escape single quotes in locate() substring (#2946)
• See full diff in compare view

Updates org.postgresql:postgresql from 42.7.13 to 42.7.14

Release notes

Sourced from org.postgresql:postgresql's releases.

v42.7.14

Security

This release fixes two security vulnerabilities.

requireAuth is silently not enforced when the value excludes every authentication method (GHSA-rhp9-mr79-r74h, CVE-2026-107314)

Severity: Moderate (CVSS 5.9) | Affected versions: 42.7.11 – 42.7.13

If the requireAuth connection property excluded all six authentication methods the driver knows (for example requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none) or contained no method at all (for example requireAuth=,), the driver applied no restriction and accepted whatever method the server asked for, including cleartext password. An attacker positioned between the application and the server could use this to request cleartext password authentication and receive the database password.

Unset values, positive lists (such as requireAuth=scram-sha-256) and partial exclusions (such as requireAuth=!password,!md5) were not affected, and neither were deployments that do not set requireAuth.

Behavior after upgrading:

• A value that excludes every method now refuses the connection with SQLState 08004 and the message Authentication method is not allowed by requireAuth (or the channel binding error when channelBinding=require is also set).
• A value that names no method is rejected as an invalid requireAuth value.

Because affected deployments had this value by mistake, and connections worked normally on affected versions, connections with such a value will fail after upgrading. Replace it with a positive list of the methods your server uses, for example requireAuth=scram-sha-256.

Independently of this fix, use sslmode=verify-full with a trusted CA so that an attacker cannot present a substitute server.

Thanks to @​manus-pi for finding and reporting this issue.

Driver stores bytes of earlier statements when it pads a value shorter than its declared length (GHSA-f64h-wr5q-3qf3, CVE-2026-107315)

Severity: Moderate (CVSS 5.3) | Affected versions: 42.7.4 – 42.7.13

When an application sent a value shorter than the length it declared, the driver padded the missing bytes with data from earlier messages on the same connection instead of zeros, and the server stored them. The stored value could contain SQL text and parameter values of earlier, unrelated statements (up to 8192 bytes, or 16320 with GSS encryption). On pooled connections, those statements could come from other requests. 42.7.3 and earlier padded with zeros.

This is reachable through the following public API when the declared length is larger than the data:

• PreparedStatement.setObject(int, ByteStreamWriter)
• CopyIn.writeToCopy(ByteStreamWriter) and CopyIn.writeToCopy(byte[], int, int)
• PGCopyOutputStream.write(byte[], int, int) (writes over 64 KiB)
• LargeObject.write(byte[], int, int)
• java.sql.Blob.setBytes(long, byte[], int, int)

Padding is now always zeros. Applications whose declared length always matches the data were not affected. Values stored by an affected version through such a call may already contain leaked data, so you may want to review affected columns. There is no connection property to disable the old behavior; the workaround on older versions is to make the declared length match the data.

Thanks to @​vlsi for finding and reporting this issue.

Full Changelog: pgjdbc/pgjdbc@REL42.7.13...REL42.7.14

Changelog

Sourced from org.postgresql:postgresql's changelog.

Changelog

Notable changes since version 42.0.0, read the complete History of Changes.

The format is based on Keep a Changelog.

[Unreleased]

Fixed

• fix: PGStream.skip no longer loops forever when the connection ends while the driver is discarding bytes, and no longer mistakes a stream that skips nothing for one that has ended. InputStream.skip may return zero with more data still coming, which a stream supplied through the socketFactory property is free to do; the driver now reads a byte in that case and treats only -1 as the end [PR #4358](pgjdbc/pgjdbc#4358)
• fix: LargeObjectManager operations now work inside an active XA transaction. Since 42.7.13 an XA branch keeps the caller's autoCommit=true, and the guard rejected large objects as if the connection were idle. It now checks the server transaction state (getTransactionState()) instead of autoCommit, so a genuine auto-commit connection with no open transaction is still refused [Issue #4309](pgjdbc/pgjdbc#4309) [PR #4310](pgjdbc/pgjdbc#4310)
• fix: batch update counts are no longer secured as committed inside an XA transaction. BatchResultHandler treated per-statement progress as durable whenever autoCommit=true, but an XA branch keeps autoCommit=true while the transaction is open, so a batch that flushed mid-way and then failed could report rolled-back statements as succeeded. Progress is now secured only when no server transaction is open [Issue #4309](pgjdbc/pgjdbc#4309) [PR #4311](pgjdbc/pgjdbc#4311)

Changed

• fix: backend message lengths are checked before anything is sized from them. Each length is checked against the message layout and a limit for its type, the lengths inside DataRow and FunctionCallResponse are checked against the message, and the NegotiateProtocolVersion option count is bounded. A hostile or out of sync backend could previously force an allocation of up to two gigabytes with a five byte header [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: the read buffer is limited to 32 MiB and grows once per request rather than once per socket read. It previously doubled on every read while a large request was outstanding, so a peer that declared a large length and sent it slowly grew the buffer until the doubling past 1 GiB overflowed to a negative size [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: a zero-length CopyData body is accepted. It is valid on the wire and was previously rejected by an assertion, so it failed only on JVMs started with -ea [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: GSS packet lengths are bounded. The encrypted transport is limited to a 16380 byte payload and the handshake to a 65532 byte token, matching PQ_GSS_MAX_PACKET_SIZE and PQ_GSS_AUTH_BUFFER_SIZE [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: a connection whose stream has been refused is no longer reusable. Any refused length or count marks the stream broken, so Connection.isClosed() reports it closed and a pool that tests on borrow discards it. The socket is dropped with SO_LINGER 0 [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: a protocol violation before authentication is reported as PSQLException with SQLState 08P01 rather than as a plain I/O error, and is no longer retried under sslMode=allow or sslMode=prefer [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: the counts inside RowDescription, ParameterDescription, CopyInResponse and CopyOutResponse are checked against the declared message length. A RowDescription claiming more fields than its length can hold previously read its field descriptions out of the messages that followed it [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: the driver checks that each backend message was consumed exactly before reading the next message type, so a reader that stops short of its declared length is refused rather than misreading what follows [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: the authentication loop, the GSS encryption handshake and the GSS authentication handshake each stop after 64 round trips. A zero-length GSS token is a valid continuation, so a server could previously keep a client exchanging tokens forever before any credentials were exchanged [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: ErrorResponse before authentication is limited to 30000 bytes rather than 32 MiB, matching libpq's limit for messages outside VALID_LONG_MESSAGE_TYPE, and a C string inside a declared message is no longer scanned past the end of that message. Both were allocations an unauthenticated peer could cause [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: an ErrorResponse or NoticeResponse longer than 32 MiB is truncated to that size rather than refused. The body past the limit is drained and the shortened message is delivered, so the connection stays usable [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: the read buffer returns to its initial size once the message that grew it is drained, so a connection no longer retains 32 MiB after one large error [Issue #4015](pgjdbc/pgjdbc#4015)
• fix: exceeding maxResultBuffer closes the connection. The row is not read past the limit, so the connection cannot continue, and it is now dropped where the limit is exceeded rather than refused as a protocol violation at the next message. The error reported is the limit alone, with SQLState 08S01 as before [Issue #4015](pgjdbc/pgjdbc#4015)

Security

• fix: a requireAuth value that excludes every authentication method, such as !password,!md5,!gss,!sspi,!scram-sha-256,!none, now refuses every method. A connection with such a value now fails with SQLState 08004. Before, the driver treated the value as if requireAuth were not set, and used any method the server asked for, even a cleartext password. This affects 42.7.11 through 42.7.13 GHSA-rhp9-mr79-r74h
• fix: a requireAuth value without a method in it, such as , or ,,, now fails with SQLState 22023. Before, the driver treated it as if requireAuth were not set. Commas at the very end of a value are still ignored, as in password,. This affects 42.7.11 through 42.7.13 GHSA-rhp9-mr79-r74h

Commits

• ebdd9d0 chore: bump version to 42.7.14
• 0e764c8 test: Add additional PgBufferedOutputStream.writeZeros(...) tests
• c8998c8 fix: writeZeros() could send stale buffer contents instead of zeros
• a65ef98 fix: refuse every method when requireAuth excludes them all
• See full diff in compare view

Updates org.hibernate.orm:hibernate-core from 7.4.12.Final to 7.4.13.Final

Release notes

Sourced from org.hibernate.orm:hibernate-core's releases.

Release 7.4.13

Hibernate ORM 7.4.13.Final released

Today, we published a new release of Hibernate ORM 7.4: 7.4.13.Final.

You can find the full list of 7.4.13.Final changes here.

What's new

• See the website for requirements and compatibilities.
• See the What's New guide for details about new features and capabilities.
• See the Migration Guide for details about migration.

Conclusion

For additional details, see:

• the release page
• the Migration Guide
• the Introduction Guide
• the User Guide
• the API docs

See also the following resources related to supported APIs:

• the compatibility policy
• the incubating API report (@Incubating)
• the deprecated API report (@Deprecated + @Remove)
• the internal API report (internal packages, @Internal)

Visit the website for details on getting in touch with us.

Changelog

Sourced from org.hibernate.orm:hibernate-core's changelog.

Changes in 7.4.13.Final (October 11, 2026)

https://hibernate.atlassian.net/projects/HHH/versions/40491

** Bug * HHH-20906 Bug in combination of @​Audited, Joined Inheritance and @​SecondaryTable * HHH-17354 HQL queries do not handle quoted identifiers from sub-queries

** Task * HHH-20957 Upgrade ByteBuddy to 1.18.14 (latest micro update) for Java 27

Commits

• ba8526a [Jenkins release job] Preparing release 7.4.13.Final