CVE-2026-22865: 
Gradle vulnerability analysis and mitigation

CVE-2026-22865 is a dependency resolution flaw in Gradle's build automation tool (and its native-platform component) that can expose builds to malicious artifacts via repository fallback. When resolving dependencies, certain non-fatal exceptions (e.g., NoHttpResponseException) did not cause Gradle to disable the failing repository, allowing it to silently fall through to the next repository in the configured list. This behavior enables a supply chain attack where an attacker who controls a downstream repository can serve malicious artifacts after disrupting an upstream one. Affected versions are all Gradle releases before 8.14.4 and versions 9.0.0 through 9.2.1. The vulnerability was published on January 16, 2026, with a CVSS v3.1 base score of 7.4 (High) and a CVSS v4.0 base score of 8.6 (High) (GitHub Advisory, Red Hat CVE).

The root cause is improper error handling during dependency resolution, classified under CWE-494 (Download of Code Without Integrity Check) and CWE-829 (Inclusion of Functionality from Untrusted Control Sphere). Gradle is designed to disable a repository and halt resolution when it encounters connection errors, ensuring reproducibility and security. However, certain transient exceptions — such as NoHttpResponseException — were not treated as fatal; after exhausting retries, Gradle would silently proceed to the next repository in the declaration order rather than failing the build. An attacker must control a repository that appears later in the build's repository list and must be able to disrupt (e.g., via denial-of-service) the repository that precedes it, making this a network-based, high-complexity attack with no privileges required (GitHub Advisory).

Successful exploitation enables a supply chain compromise where malicious artifacts are silently substituted for legitimate dependencies during a Gradle build. This carries high integrity impact (unauthorized modification of build dependencies, potentially injecting malicious code into compiled software) and high confidentiality impact (malicious artifacts could exfiltrate secrets or credentials accessible during the build process). Availability of the build system itself is not directly impacted, but downstream consumers of the compromised build artifacts could face severe consequences including code execution, data theft, or further lateral movement within CI/CD pipelines (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (Feedly). The EPSS score is approximately 0.019% (0.000190), reflecting a currently low probability of exploitation in the near term. The attack requires high complexity — specifically, the attacker must both control a downstream repository and be able to disrupt an upstream repository — limiting opportunistic exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Detection is available via Tenable Nessus plugin 291302 (Tenable).

1. Reconnaissance: Identify target organizations using Gradle builds (versions < 8.14.4 or 9.0.0–9.2.1) with multiple repositories declared in their build.gradle or settings.gradle files, particularly those using public repositories like Maven Central followed by a secondary or internal repository.
2. Position in repository chain: Gain control over a repository that appears after a primary repository in the target build's repository declaration order (e.g., a mirror, internal Nexus/Artifactory instance, or a public repository the attacker can publish to).
3. Disrupt the upstream repository: Launch a denial-of-service or network-level disruption against the primary repository so that Gradle receives persistent NoHttpResponseException or similar transient errors when attempting to resolve dependencies from it.
4. Exhaust retry attempts: Allow Gradle to exhaust its maximum retry count against the disrupted repository. In vulnerable versions, Gradle will not disable the repository as a fatal failure and will instead proceed to the next repository in the list.
5. Serve malicious artifacts: Host a malicious artifact (with the same group ID, artifact ID, and version as a legitimate dependency) in the attacker-controlled repository. Gradle resolves and downloads this artifact without integrity verification.
6. Achieve code execution or data exfiltration: The malicious artifact is incorporated into the build, enabling arbitrary code execution within the build environment, exfiltration of secrets (e.g., API keys, credentials), or injection of backdoors into the compiled software (GitHub Advisory).

• Network: Unexpected outbound connections from build servers to unfamiliar or unauthorized artifact repositories during dependency resolution; repeated failed connection attempts to a primary repository followed by successful connections to a secondary repository.
• Logs: Gradle build logs showing NoHttpResponseException or similar transient errors against a primary repository, followed by successful artifact downloads from a different repository; discrepancies between expected and actual artifact download URLs in build output.
• File System: Presence of dependency JARs or artifacts with unexpected checksums compared to known-good values; artifacts in the Gradle cache (~/.gradle/caches/) with mismatched SHA-256/MD5 hashes relative to those published by the legitimate upstream repository.
• Process: Unusual processes or network connections spawned by the build JVM or test execution that are inconsistent with the expected build behavior; unexpected outbound connections during or after build execution.

Gradle has released patched versions 8.14.4 (for the 8.x branch) and 9.3.0 (for the 9.x branch), which change behavior to stop searching other repositories when encountering these errors. Organizations should upgrade immediately to one of these versions. As a workaround for those unable to upgrade, enabling strict repository content filtering and/or dependency verification (checksum and signature validation) in Gradle will prevent malicious artifacts from being accepted even if repository fallback occurs. Additionally, auditing build.gradle and settings.gradle files to remove unused or untrusted repository declarations reduces the attack surface (GitHub Advisory).

The vulnerability was reported by security researchers identified as "Vampire" and "KostyaSha" and remediated by Gradle developers "ljacomet" and "TheGoesen," as credited in the official GitHub Security Advisory. Red Hat has acknowledged the CVE and published a tracking entry. A technical blog post analyzing the vulnerability was published at infinitsec.net shortly after disclosure, and the CVE was noted in a broader analysis of package manager CWEs published in May 2026 (GitHub Advisory, Red Hat CVE, Infinitsec Blog).