CVE-2026-22816
Gradle ≤ 8.14.4
Raw vector
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-22816 is a high-severity Download of Code Without Integrity Check (CWE-494) vulnerability in Gradle Gradle. Its CVSS base score is 8.6 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Supply Chain Compromise (T1195); ranked at the 5th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to CM-14 (Signed Components) and SI-7 (Software, Firmware, and Information Integrity) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-22816 affects Gradle, a build automation tool, specifically its dependency resolution process in versions prior to 9.3.0. The native-platform tool in Gradle provides Java bindings for native APIs, but during dependency resolution, certain exceptions—such as those from unresolvable host names—were not treated as fatal errors. Instead, Gradle would proceed to the next repository in the configuration list, potentially resolving dependencies from an alternative source. This behavior stems from CWEs-494 (Download of Code Without Integrity Check) and CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), with a CVSS v3.1 base score of 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).
An attacker can exploit this vulnerability by registering a domain name that matches a lapsed registration or a typo in a repository URL listed in a Gradle build configuration. No special privileges are required, only the ability to control a domain and host a malicious repository, with network access to the build environment. For successful exploitation, the targeted repository must be listed before others in the configuration; Gradle will attempt resolution there first, and if the attacker has made the previously unresolvable host active, it can serve malicious artifacts. This enables a supply chain attack, allowing arbitrary code execution via tampered dependencies, compromising confidentiality and integrity.
The Gradle security advisory (GHSA-w78c-w6vf-rw82) and associated commit (e5707d0d8fce3d768c9c489004700d78eab1773a) detail the fix in Gradle 9.3.0, which treats these exceptions as fatal and halts resolution without falling back to other repositories. Security practitioners should upgrade to Gradle 9.3.0 or later and review build configurations for repository order, domain accuracy, and lapsed registrations to mitigate risks.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-3593
Vulnerability Data
Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. When resolving dependencies in versions before 9.3.0, some exceptions were not treated as fatal errors and would not cause a repository to be disabled.…
more
If 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. If a Gradle build used an unresolvable host name, Gradle would continue to work as long as all dependencies could be resolved from another repository. An unresolvable host name could be caused by allowing a repository's domain name registration to lapse or typo-ing the real domain name. This behavior could allow an attacker to register a service under the host name used by the build and serve malicious artifacts. The attack requires the repository to be listed before others in the build configuration. Gradle has introduced a change in behavior in Gradle 9.3.0 to stop searching other repositories when encountering these errors.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 15 hardening rules · 6 OS baselines
V14.2.3V3.5.6V9.1.3V15.3.2
Mitigating Controls (NIST 800-53 r5) AI
Requires digital signature verification before component installation, directly stopping execution of code downloaded without integrity checks.
Employs integrity verification tools that can identify missing or failed checks on downloaded software after the fact.
Requires documented, valid provenance for components, preventing acceptance of code from outside the trusted sphere.
Implements detection and prevention of counterfeit or inauthentic components before they are integrated.
Establishes processes to identify and address supply-chain weaknesses that would allow untrusted functionality.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Directly requires assessing authenticity/integrity of software before acquisition and use, preventing unverified downloads.
Supply-chain program directly governs inclusion of third-party executable code.
Contractual requirements can mandate trusted sources and integrity checks for included functionality.
Supplier risk assessment explicitly covers risks from their products and libraries.
Critical-supplier assessment reduces risk of importing executable functionality from untrusted parties.
Requires cryptographic integrity protections (signatures/hashes) for data-in-transit, covering downloaded code.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
By requiring suppliers to propagate security requirements and to disclose component provenance, the control limits the inclusion of functionality obtained from untrusted third-party sources without oversight.
Blocking domains that serve malware or untrusted scripts prevents the browser from automatically including functionality from an attacker-controlled source.
Requiring suppliers to disclose vulnerabilities and mandating verified updates lowers the chance that code lacking integrity checks will be deployed.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 8 (2 rules)
- V-248575 OL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-494
- V-248635 Executable search paths within the initialization files of all local interactive OL 8 users must only contain paths that resolve to the system default or the user's home directory. prevents CWE-829
Oracle Linux 9 (2 rules)
- V-271524 OL 9 must check the GPG signature of software packages originating from external software repositories before installation. prevents CWE-494
- V-271847 OL 9 must be configured so that executable search paths within the initialization files of all local interactive users must only contain paths that resolve to the system default or the users home directory. prevents CWE-829
RHEL 7 (3 rules)
- V-204447 The Red Hat Enterprise Linux operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-494
- V-204448 The Red Hat Enterprise Linux operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-494
- V-204477 The Red Hat Enterprise Linux operating system must be configured so that all local interactive user initialization files executable search paths contain only paths that resolve to the users home directory. prevents CWE-829
RHEL 8 (2 rules)
- V-230264 RHEL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-494
- V-230317 Executable search paths within the initialization files of all local interactive RHEL 8 users must only contain paths that resolve to the system default or the users home directory. prevents CWE-829
RHEL 9 (2 rules)
- V-257820 RHEL 9 must check the GPG signature of software packages originating from external software repositories before installation. prevents CWE-494
- V-258050 Executable search paths within the initialization files of all local interactive RHEL 9 users must only contain paths that resolve to the system default or the users home directory. prevents CWE-829
Windows 10 (1 rule)
- V-220737 Administrative accounts must not be used with applications that access the Internet, such as web browsers, or with potential Internet sources, such as email. prevents CWE-829