Introducing the Gradle Security Subscription

August 31, 2026

Gradle Build Tool

Security

Introduction

The Gradle Security Subscription is available today. It provides security fixes under a service-level agreement, security maintenance for Gradle versions beyond the open source end-of-life policy, and advance notice of newly discovered vulnerabilities ahead of public disclosure. Coverage details are on our subscription page.

The rest of this post explains why the subscription is important and what changes for the open source community (in short, nothing).

The toolchain as an attack surface #

In 1984, while accepting the Turing Award, Ken Thompson described a compiler he had modified to insert a backdoor into the programs it compiled. Reviewing the source of the affected program revealed nothing. And reviewing the source of the compiler revealed nothing either. His conclusion was that you cannot fully trust code you did not create entirely yourself.

Four decades later, we find ourselves facing the same dilemma. Software composition analysis scans the dependencies a project declares. Static analysis scans the source a team writes. But neither examines the build tool that turns that source and those dependencies into the artifact that goes to production.

This gap has been exploited repeatedly.

In 2015, XcodeGhost distributed a modified version of Apple’s IDE that inserted malicious code into every application compiled with it, reaching thousands of App Store applications whose developers had written nothing malicious.

In 2020, SolarWinds released a compromised version of their IT software, but the attackers modified no source code. They gained access to the build environment and installed malware that monitored the compilation process, injecting a backdoor into the resulting binary as it was produced. Approximately 18,000 organizations installed the signed update, including the U.S. Departments of Treasury, State, Defense, and Homeland Security.

There are two more recent incidents. The Codecov Bash Uploader compromise ran undetected for roughly two months in 2021, exfiltrating environment variables from customer CI runs; among the casualties was the GPG private key HashiCorp used to sign its product releases. And in 2025, the s1ngularity attack on the Nx build system published malicious package versions with a post-install payload that harvested developer credentials, notably by enlisting locally installed AI CLI tools to accelerate its own reconnaissance.

Gradle is not exempt from this. In 2023, we published a report on an attack targeting the Gradle Wrapper, in which a modified gradle-wrapper.jar was submitted through a pull request. The wrapper JAR is committed to millions of public GitHub repositories and executed by every developer and every continuous integration job that invokes ./gradlew.

That is what makes the wrapper worth attacking. A modified one can download and execute arbitrary code while behaving identically to a legitimate one.

We have long argued that the toolchain belongs in the same operational class as the systems it produces, a case Hans Dockter made recently in Your Toolchain Is Production Now.

Limits to our end-of-life policy #

Gradle ships some of the strongest supply chain protections available in a modern build system, dependency verification and repository content filtering among them. We published a free course on the topic on YouTube.

Gradle has an end-of-life policy, under which security fixes are only delivered to the latest minor release of the current and previous major versions.

In practice:

• Organizations on an older major version are producing production artifacts with software that no longer receives fixes.
• Organizations that are behind within the current major version must upgrade to the latest release to obtain a patch. Individual fixes are not backported.
• Security fixes are delivered on a best-effort basis and may be held for the next scheduled minor release.

Organizations maintaining codebases that cannot move to the latest version of Gradle need extended coverage, and those with formal compliance obligations often need more than best effort.

What the subscription provides #

That’s where the security subscription comes in. It doesn’t change Gradle’s existing end-of-life policy, but it adds guarantees and extended coverage.

It provides three things:

1. Prioritized fixes under a service-level agreement. Critical vulnerabilities are fixed within 7 days and high-severity vulnerabilities within 30 days. For first-party vulnerabilities, the SLA begins at discovery. For vulnerabilities in third-party components, it begins when the upstream patch is released.

2. Extended security maintenance. High-severity and critical vulnerabilities (CVSS ≥ 7) are addressed beyond the open source end-of-life policy. Coverage extends to every minor release in the current major published in the last 12 months, plus the last minor of the previous two major releases.

3. Embargoed vulnerability information. Under a confidentiality agreement, subscribers receive advance notification of newly discovered vulnerabilities and any available mitigations ahead of public disclosure under our responsible disclosure policy. This allows remediation to be prepared before a fix becomes public.

What that second point means in practice, as of August 2026:

Fixes are produced by the engineering team that maintains Gradle rather than by a third-party backporting service and are validated against our comprehensive test suite.

The commitment is that Gradle is free of known exploitable high-severity and critical vulnerabilities, including those that could enable a supply chain attack. Coverage applies to Gradle itself rather than to peripheral products.

Handling third-party vulnerabilities #

Gradle bundles third-party components, so a scanner run against a Gradle distribution may report CVEs even on a fully patched version.

A vulnerability reported against a bundled component is not necessarily exploitable through Gradle, and where it is, the severity is not necessarily the same. A vulnerability rated high against a dependency may rate lower once scored against how Gradle actually uses it. Our security team publishes that impact analysis, the adjusted CVSS score, and the reasoning behind it.

What this means for the open source community #

The Gradle Security Subscription is added coverage on top of the existing end-of-life policy that is useful for organizations that are looking for more security assurances in their development process.

Nothing changes for projects using Gradle.

Gradle’s development is funded by commercial offerings from Develocity and the security subscription is another way for us to keep Gradle safe and secure.

Published advisories #

Over the years, various security vulnerabilities have been reported against and fixed in Gradle, including high-severity issues and one critical issue.

Here is where each Gradle version stands as of August 2026:

Being on the current major version is not sufficient on its own. Early 9.x releases carry two known high-severity advisories, where the open source fix is to upgrade to the latest minor and subscribers instead receive a patch release for the minor they are already on.

The complete list is published in the repository.

Next steps #

Build tools execute code and produce the artifacts that reach production. They warrant the scrutiny applied to other production infrastructure, and in most organizations they currently receive less.

If you are running a version with known advisories, upgrade to the latest version in your release line.

Whether or not you upgrade, we recommend reading Protecting Project Integrity and enabling the wrapper validation action, which addresses the Gradle wrapper attack described above.

For organizations that need stronger guarantees and broader version coverage, see gradle.org/security-subscription.

Discuss