CVE-2026-22816: 
Gradle vulnerability analysis and mitigation

CVE-2026-22816 is a dependency confusion/repository fallback vulnerability in Gradle, the build automation tool, where failure to disable repositories with unresolvable hostnames can expose builds to malicious artifacts. When Gradle encounters certain non-fatal exceptions (such as UnknownHostException) during dependency resolution, it silently continues to the next repository in the list rather than failing the build, potentially resolving dependencies from an attacker-controlled source. Affected versions are Gradle before 8.14.4 and Gradle 9.0.0 through 9.2.1. The vulnerability was published on January 16, 2026, and patched in Gradle 8.14.4 and 9.3.0. It carries 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 classified under CWE-494 (Download of Code Without Integrity Check) and CWE-829 (Inclusion of Functionality from Untrusted Control Sphere). Gradle's dependency resolution engine searches repositories in declaration order and is designed to disable a repository upon encountering connection errors, preventing silent fallback to other sources. However, prior to the fix, certain exceptions — notably UnknownHostException triggered by unresolvable hostnames — were not treated as fatal errors and did not trigger repository disabling, causing Gradle to silently proceed to the next configured repository. An attacker exploiting this flaw must register a service under the hostname of the intended (but unresolvable) repository and ensure that repository is listed before others in the build configuration. The fix, introduced in commit e5707d0, adds an isRepositoryDisabled() interface method and modifies ConnectionFailureRepositoryDisabler to treat max-retry exhaustion on transient errors as a disabling condition, halting further repository traversal (GitHub Commit, GitHub Advisory).

Successful exploitation allows an attacker to serve malicious artifacts to a Gradle build without authentication, resulting in high confidentiality and integrity impact — including potential code execution within the build environment, data theft, and compromise of built artifacts distributed downstream. The attack is particularly dangerous in CI/CD pipelines where build outputs are automatically deployed, enabling supply chain compromise. Availability is not directly impacted, as the build continues to function (resolving from the attacker's repository), which also makes the attack difficult to detect without explicit monitoring (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The EPSS score is approximately 0.019% (0.000190), reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high attack complexity — the attacker must register a domain matching a typo or lapsed registration of a repository hostname and ensure the vulnerable repository is listed first in the build configuration — but requires no privileges or authentication (GitHub Advisory).

1. Reconnaissance: Identify target Gradle builds (e.g., open-source projects on GitHub) that declare custom or third-party repository URLs in their build.gradle or settings.gradle files, particularly repositories that may have lapsed domain registrations or contain typos.
2. Identify unresolvable hostname: Confirm that the target repository's hostname is currently unresolvable (e.g., via DNS lookup tools like dig or nslookup), indicating an expired domain or misconfiguration.
3. Register malicious domain: Register the unresolvable hostname as a new domain and set up a web server mimicking a Maven/Ivy artifact repository, hosting trojanized versions of dependencies the target build requires.
4. Serve malicious artifacts: Publish malicious JAR files or other build artifacts under the expected group/artifact/version coordinates on the attacker-controlled repository server.
5. Trigger build: Wait for or trigger a Gradle build on the target system. Gradle will attempt to resolve dependencies from the (now attacker-controlled) first repository, receive a valid response, and download the malicious artifacts without integrity verification.
6. Achieve objective: The malicious code embedded in the downloaded artifact executes during the build process, enabling code execution, credential theft, backdoor installation, or supply chain compromise of the resulting build artifacts (GitHub Advisory).

• Network: Outbound HTTP/HTTPS connections from build systems to unexpected or newly registered repository hostnames; DNS queries resolving repository hostnames to unfamiliar IP addresses not associated with known artifact hosting providers (e.g., Maven Central, JFrog, Sonatype).
• Logs: Gradle build logs showing dependency resolution succeeding from a repository other than the primary/expected one; absence of expected UnknownHostException or repository-disabled warnings in build output for known-bad hostnames.
• File System: Unexpected or modified JAR files in the Gradle dependency cache (~/.gradle/caches/) with checksums that do not match known-good values from trusted sources; newly downloaded artifacts with unusual metadata or signing information.
• Process: Unexpected processes spawned during or after a Gradle build (e.g., reverse shells, data exfiltration tools) originating from the JVM process running the build (GitHub Advisory).

Upgrade Gradle to version 8.14.4 (for 8.x users) or 9.3.0 (for 9.x users), which introduce the behavioral change to stop searching other repositories when encountering unresolvable hostname errors (GitHub Advisory). If upgrading is not immediately possible, enable strict repository content filtering and/or dependency verification (checksums/signatures) in your Gradle build configuration, as either control prevents malicious artifacts from being accepted even if resolved from an unexpected repository. Additionally, audit all repository declarations in build scripts to remove unused, outdated, or suspicious entries, and ensure trusted repositories (e.g., Maven Central) are listed first.

The vulnerability was reported by community members KostyaSha and Vampire (finders) and reported by TheGoesen, with remediation credited to ljacomet and big-guy from the Gradle team (GitHub Advisory). A brief write-up was published by Infinitsec covering the vulnerability's impact on build pipelines (Infinitsec). Red Hat has also tracked the vulnerability for potential impact on their products (Red Hat CVE).