Gradle's dependency verification can ignore checksum verification when signature verification cannot be performed
Key facts
- Attack vector
- Network
- Privileges required
- High
- User interaction
- None
- Attack complexity
- High
- Impact type
- Code execution, Security bypass
- Confidentiality · integrity · availability
- High · High · High
- Fix status
- Deferred Red Hat: fix deferred
Attack profile from CVSS 3.1 · CNA. Fix status from CNA and Red Hat. Impact type from CWE-829 and CWE-347.
Summary
Gradle is a build tool. Dependency verification is a security feature in Gradle Build Tool that was introduced to allow validation of external dependencies either through their checksum or cryptographic signatures. In versions 6.2 through 7.4.2, there are some cases in which Gradle may skip that verification and accept a dependency that would otherwise fail the build as an untrusted external artifact. This can occur in two ways. When signature verification is disabled but the verification metadata contains entries for dependencies that only have a `gpg` element but no `checksum` element. When signature verification is enabled, the verification metadata contains entries for dependencies with a `gpg` element but there is no signature file on the remote repository. In both cases, the verification will accept the dependency, skipping signature verification and not complaining that the dependency has no checksum entry. For builds that are vulnerable, there are two risks. Gradle could download a malicious binary from a repository outside your organization due to name squatting. For those still using HTTP only and not HTTPS for downloading dependencies, the build could download a malicious library instead of the expected one. Gradle 7.5 patches this issue by making sure to run checksum verification if signature verification cannot be completed, whatever the reason. Two workarounds are available: Remove all `gpg` elements from dependency verification metadata if you disable signature validation and/or avoid adding `gpg` entries for dependencies that do not have signature files.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Total
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
Remediation
No fixed version listed by the sources yet.
Vendor assessments
Red Hat
Red Hat rating: Low. Red Hat's page for this CVE →
| Product | Status | Plan or fix |
|---|---|---|
| Red Hat JBoss Enterprise Application Platform 6 | Affected | No fix planned: Out of support scope |
| Red Hat Software Collections | Affected | No fix yet: Fix deferred |
Not affected: 2 products
- Red Hat JBoss Enterprise Application Platform 7
- Red Hat JBoss Enterprise Application Platform Expansion Pack
Timeline
- 2026-10-02 Threatist record created from CVE-2022-31156
References
More Gradle vulnerabilities
- TI-2016-05320 ObjectSocketWrapper.java in Gradle 2.12 allows remote attackers to execute arbitrary code… CVSS 3.0CRITICAL 9.8
- TI-2020-09639 Injection in Apache Ant CVSS 3.1HIGH 7.5
- TI-2019-11237 The HTTP client in Gradle before 5.6 sends authentication credentials originally destined… CVSS 3.1CRITICAL 9.8
- TI-2021-12419 Arbitrary code execution via specially crafted environment variables CVSS 3.1HIGH 7.5
- TI-2023-11286 Gradle usage of long IDs for PGP keys opens potential for collision attacks CVSS 3.1CRITICAL 9.8
- TI-2021-10141 Local privilege escalation through system temporary directory CVSS 3.1HIGH 8.8
Sources
- CVE-2022-31156 · CVE Program
- CVE-2022-31156 · NVD
- FIRST EPSS
- CVE-2022-31156 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences