CVE-2026-22865: Gradle Build Tool DOS Vulnerability

CVE-2026-22865 Overview

Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. A vulnerability exists in versions before 9.3.0 where certain exceptions during dependency resolution were not treated as fatal errors and would not cause a repository to be disabled. When a build encountered one of these exceptions, Gradle would continue to the next repository in the list and potentially resolve dependencies from a different repository, enabling supply chain attack scenarios.

Critical Impact

This vulnerability could allow an attacker to disrupt the service of a legitimate repository and leverage another controlled repository to serve malicious artifacts, compromising the software supply chain.

Affected Products

• Gradle versions prior to 9.3.0
• Gradle native-platform tool with Java bindings
• Build systems utilizing multiple repository configurations

Discovery Timeline

• 2026-01-16 - CVE CVE-2026-22865 published to NVD
• 2026-01-16 - Last updated in NVD database

Technical Details for CVE-2026-22865

Vulnerability Analysis

This vulnerability relates to CWE-494 (Download of Code Without Integrity Check), manifesting in Gradle's dependency resolution mechanism. The issue arises from improper error handling during repository communication. When Gradle encounters transient errors such as NoHttpResponseException, the build tool does not properly treat these as conditions that should terminate the repository search. Instead, after exhausting retry attempts, Gradle proceeds to query subsequent repositories in the configured list.

The vulnerability creates a window of opportunity for supply chain attacks. An attacker who can cause disruption to a primary, trusted repository—through denial of service or network interference—can force Gradle to fall back to a secondary repository under their control. This secondary repository can then serve malicious artifacts that appear legitimate to the build process.

Root Cause

The root cause stems from Gradle's error classification logic in the dependency resolution subsystem. Certain HTTP exceptions, including NoHttpResponseException, were categorized as recoverable errors rather than terminal failures. While this design was intended to handle genuine transient network issues gracefully, it created an attack surface where persistent errors (potentially induced by an attacker) would not prevent Gradle from seeking dependencies elsewhere.

The permissive fallback behavior means that even after the maximum retry count is exceeded for a given repository, Gradle continues its search through the repository chain rather than failing the build with an appropriate error.

Attack Vector

The attack vector requires network-level access to disrupt communication between the build system and a legitimate repository. An attacker must have control over a repository that appears later in the build's repository configuration. The attack unfolds as follows:

1. The attacker disrupts the target's connection to a legitimate repository (e.g., through network interference or denial of service)
2. Gradle encounters errors when attempting to resolve dependencies from the disrupted repository
3. After retries are exhausted, Gradle falls back to the next configured repository
4. The attacker-controlled repository serves malicious artifacts in place of legitimate dependencies
5. The build proceeds with compromised dependencies, potentially introducing backdoors or malware

This attack is network-based but requires specific preconditions: the attacker must control a repository in the fallback chain and must be able to sustain disruption of the primary repository.

Detection Methods for CVE-2026-22865

Indicators of Compromise

• Unexpected dependency resolution from secondary or tertiary repositories in build logs
• Increased NoHttpResponseException or similar transient errors targeting specific repositories
• Hash mismatches for resolved artifacts compared to expected values
• Build artifacts originating from untrusted or unexpected repository sources

Detection Strategies

• Review Gradle build logs for repository fallback patterns and repeated connection failures to primary repositories
• Implement artifact verification using checksums or signatures to detect substitution attacks
• Monitor network traffic for anomalous patterns targeting repository connections
• Enable Gradle's dependency verification feature to detect unexpected artifact sources

Monitoring Recommendations

• Configure alerting for builds that resolve dependencies from non-primary repositories
• Implement integrity verification for all resolved dependencies using Gradle's built-in verification features
• Monitor for unusual network activity or denial of service indicators targeting build infrastructure
• Audit repository configurations to minimize exposure to untrusted fallback repositories

How to Mitigate CVE-2026-22865

Immediate Actions Required

• Upgrade Gradle to version 9.3.0 or later, which includes the behavioral fix for repository error handling
• Review and minimize the number of repositories in your build configuration to reduce fallback attack surface
• Enable Gradle dependency verification to cryptographically verify artifact integrity
• Audit existing builds for any evidence of unexpected repository fallback behavior

Patch Information

Gradle has addressed this vulnerability by introducing a behavioral change in version 9.3.0. In the patched version, Gradle will stop searching other repositories when encountering persistent errors rather than continuing through the repository chain. This prevents the fallback mechanism from being exploited for supply chain attacks.

For additional details, refer to the GitHub Security Advisory.

Workarounds

• Configure builds to use a single trusted repository when possible, eliminating fallback attack vectors
• Implement network-level controls to ensure stable connectivity to legitimate repositories
• Use Gradle's dependency locking feature to prevent unexpected dependency version changes
• Deploy a repository manager proxy that validates artifacts before serving them to builds

# Enable dependency verification in Gradle
# Create or update gradle/verification-metadata.xml with trusted checksums
gradle --write-verification-metadata sha256

# Configure strict repository handling by limiting repositories
# In settings.gradle.kts, define only essential repositories:
# dependencyResolutionManagement {
#     repositories {
#         mavenCentral()  // Single trusted repository
#     }
# }