SSerguey Asael Shinder
Java coding notes: the JVM, and writing software that lasts

Serguey Asael Shinder: Gradle 9.8.1 and 8.14.6 fix daemon deserialization and a TLS fall-through

· by Serguey Asael Shinder / Serguey Shinder

Gradle released 9.8.1 on 7 October and recommends it over 9.8.0. The release addresses three advisories rated high, all affecting org.gradle:gradle-core before 8.14.6 and from 9.0.0 to 9.8.0. The free fixed versions are 9.8.1 and 8.14.6.

1. Worker-to-daemon channel (GHSA-mvvg-497x-hmj8). Compilation, tests and Worker API actions run in forked worker processes that talk to the daemon over a loopback TCP socket. That socket did not authenticate the connecting peer; it accepted the first connection during a short window while a worker started, and messages could fall back to Java serialization. Whoever won that race could make the daemon deserialize a hostile object graph: code execution in the daemon JVM, with the build user's privileges and secrets, or a crash. Gradle says a proof of concept exists and is not published. The fix adds a per-connection secret.

2. Client-to-daemon channel (GHSA-xwqc-3h47-hg64). The gradle / gradlew CLI and IDEs using the Tooling API send commands to the daemon over loopback. The daemon checks a secret token — but it deserialized the message before checking the token. Unlike the first bug, this needs only a running daemon, not an active build. The fix verifies the token first.

Both are local: Gradle states they are not exploitable from a remote network connection, and names shared, multi-user build hosts as the most exposed.

Serguey Asael Shinder: Gradle 9.8.1 and 8.14.6 fix daemon deserialization and a TLS fall-through
Gradle 9.8.1 and 8.14.6 fix daemon deserialization and a TLS fall-through — Serguey Asael Shinder

3. Repository fall-through on TLS errors (GHSA-j5m7-59rp-24f5). Gradle searches repositories in declaration order and is meant to disable a repository and fail resolution on a connection error, so that a dependency never silently comes from somewhere else. SSLException and SSLHandshakeException were treated as neither fatal nor transient, so Gradle moved on to the next repository. An attacker able to disrupt one repository and control a later one could serve their own artifact. Gradle now stops on these errors.

Also fixed in 9.8.1: invalid-toolchain complaints on Debian/Ubuntu packaged JDKs, root java.util.logging handlers being removed under a custom LogManager (which broke Quarkus test log capture), and a dependency-resolution regression.

Older lines. Fixes for 9.1 through 9.7 and for 7.6 are listed only under Gradle's paid Security Subscription. Builds on those lines that want a free fix have two choices: 9.8.1, or 8.14.6.

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