Gradle 9.8.1 Patches Three High-Rated Vulnerabilities, Two Involving Unsafe Java Deserialization in Its Build Daemon Channels

Overview

Gradle released version 9.8.1 on October 7, 2026, the first patch release for Gradle 9.8.0, which the project says addresses three high-rated vulnerabilities. According to the GitHub release notes, the project recommends using 9.8.1 instead of 9.8.0. Two of the flaws involve the unsafe deserialization of Java objects in the communication between Gradle’s long-lived daemon and the processes that talk to it, and the third concerns how dependency resolution behaves when a repository fails an SSL connection.

What We Know

Worker-to-daemon channel

The first advisory, titled Unauthenticated worker-to-daemon channel deserializes untrusted Java objects, describes a loopback TCP connection between the Gradle daemon and the forked worker processes that run compilation, tests and Worker API actions. According to the advisory, that connection performs no authentication of the connecting peer. An attacker who can place bytes on the channel can cause the daemon to deserialize a hostile object graph, which the advisory says can lead to remote code execution in the daemon JVM or a denial of service.

The advisory says this has been demonstrated with a proof-of-concept, which it does not publish. It lists builds on shared or multi-user build hosts as the most at risk, and states that exploitation requires the attacker to win a race to connect during the short window between a worker process starting and the daemon accepting a connection from it. The advisory says the vulnerability is not exploitable from a remote network connection. Gradle’s fix updates the worker and daemon protocol to use a per-connection secret for authentication.

Client-to-daemon channel

The second advisory, Deserialization of untrusted Java objects before authentication in the client - daemon communication, covers the channel between a Gradle client, meaning the command-line tool or an IDE using the Tooling API, and the daemon. According to the advisory, the daemon authenticates client commands with a secret token but deserializes the incoming message before it verifies that token. The impact it describes matches the first flaw: remote code execution in the daemon JVM or a denial of service, running with the privileges of the user running the build.

One difference is timing. The advisory says this flaw requires a Gradle daemon to be running but that the daemon does not need to be actively building. It too is described as not exploitable from a remote network connection, and as most dangerous on shared or multi-user hosts. The fix verifies the secret token before deserializing untrusted input.

Repository fallback

The third advisory, Failure to disable repositories failing to establish an SSL connection can expose builds to malicious artifacts, concerns dependency resolution. Gradle searches repositories in declaration order, and the advisory says exceptions such as SSLException or SSLHandshakeException were neither handled as fatal exceptions nor as transient failures. As a result, a build could move on to the next repository in the list.

According to the advisory, that behavior could let an attacker disrupt the service of one repository and use another repository to serve malicious artifacts, though the attack requires control over a repository declared after the disrupted one. Gradle changed its behavior to stop searching other repositories when it encounters these errors. The advisory says builds that use strict repository content filtering or dependency verification are safe from the described vulnerabilities, and names dependency verification as the best protection for teams that cannot update.

Which versions are fixed

Per the first advisory, affected versions run from 9.0.0 through 9.8.0, plus anything older than 8.14.6, and the patched versions are 8.14.6 and 9.8.1. All three advisories list 9.8.1 and 8.14.6 as available in the open-source distribution. Fixes for other lines, including 9.7.2, 9.6.2, 9.5.2, 9.4.2, 9.3.2, 9.2.2 and 7.6.7, are listed as available through the Gradle Security Subscription.

The release also resolves three regressions reported against 9.8.0, according to the GitHub release page: a complaint about invalid toolchains on Debian and Ubuntu packaged systems, the removal of root java.util.logging handlers installed by a custom LogManager that broke Quarkus test log capture, and a dependency resolution regression.

The release notes also list Java 27 support for both the Gradle daemon and Java toolchains and lets Gradle reuse Maven’s mirror settings. Projects can move to the patch by running the wrapper update command given in the release notes on GitHub: ./gradlew :wrapper --gradle-version=9.8.1 && ./gradlew :wrapper.

Mitigations and Detection

For teams that cannot upgrade immediately, the worker-to-daemon advisory advises against running builds on shared, multi-user machines and recommends single-tenant, ephemeral runners on CI rather than shared hosts. The client-to-daemon advisory describes a warning that the daemon logs when it fails to process a message: “Unable to receive command from client socket connection from /127.0.0.1: to /127.0.0.1:. Discarding connection.” Both advisories caution that the lack of a log entry cannot be used to conclude no attack was performed, and that a log entry is not confirmation of an attack.

What We Don’t Know

• The advisories as retrieved did not list CVE identifiers or CVSS scores; the project describes each only as high-rated, so teams tracking these through vulnerability scanners may not find them under a CVE ID yet.
• The advisories do not say whether any of the flaws has been exploited outside of the proof-of-concept the project describes.
• The advisories do not say how the issues were discovered or reported.
• The fixed releases for most older lines are available only through the Gradle Security Subscription, so how many open-source users on those lines can take the fix without a major upgrade is not stated.