CVE-2022-23630 Overview
CVE-2022-23630 is a dependency verification bypass vulnerability in Gradle, a popular build automation tool widely used for multi-language development projects. The vulnerability allows Gradle to skip dependency verification under specific conditions, potentially accepting untrusted external artifacts that would otherwise fail the build process. This flaw occurs when dependency verification is disabled on one or more configurations that share common dependencies with other configurations where verification is enabled. If the configuration with disabled verification is resolved first, Gradle fails to verify the shared dependencies for the configuration that has verification active.
Critical Impact
Attackers could potentially inject malicious dependencies into software builds by exploiting the verification bypass, leading to supply chain compromise and execution of untrusted code within development and production environments.
Affected Products
- Gradle versions prior to 7.4
- Projects using ResolutionStrategy.disableDependencyVerification() method
- Builds with mixed dependency verification configurations
Discovery Timeline
- 2022-02-10 - CVE CVE-2022-23630 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2022-23630
Vulnerability Analysis
This vulnerability falls under CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), which describes scenarios where software imports or includes functionality from a source outside of its trust boundary without sufficiently verifying that the source is trustworthy. In this case, Gradle's dependency verification mechanism can be circumvented when configurations with different verification settings share common dependencies.
The flaw exploits a race condition in how Gradle processes dependency resolution across multiple configurations. When a build contains configurations with dependency verification both enabled and disabled, the order of resolution becomes critical. If a configuration with verification disabled resolves first, the cached artifacts are then reused by subsequent configurations without additional verification checks, effectively bypassing the security control.
Root Cause
The root cause lies in Gradle's artifact caching mechanism and how resolved artifacts were shared between verified and non-verified configurations. The ResolvedArtifactCaches component did not differentiate between artifacts that required verification and those that did not. When the provideResolvedArtifactCache() method was called, it did not consider whether the resolution strategy had dependency verification enabled, causing verified and unverified artifacts to be mixed in the same cache.
Attack Vector
An attacker could exploit this vulnerability through a supply chain attack scenario. By compromising an artifact repository or performing a man-in-the-middle attack during dependency resolution, an attacker could inject malicious dependencies. If the victim's build configuration inadvertently resolves a non-verified configuration before a verified one, the malicious artifacts would be cached and subsequently trusted by verified configurations. This attack requires network access and the ability to influence the artifact resolution process, along with specific build configuration patterns that mix verification settings.
// Security patch in ResolveIvyFactory.java
// Source: https://github.com/gradle/gradle/commit/88ab9b652933bc3b2e3161b31ad8b8f4f0516351
moduleComponentRepository = startParameterResolutionOverride.overrideModuleVersionRepository(moduleComponentRepository);
moduleComponentRepository = new CachingModuleComponentRepository(moduleComponentRepository, cacheProvider.getPersistentCaches(), cachePolicy, timeProvider, componentMetadataProcessor, listener);
}
- moduleComponentRepository = cacheProvider.getResolvedArtifactCaches().provideResolvedArtifactCache(moduleComponentRepository);
+ moduleComponentRepository = cacheProvider.getResolvedArtifactCaches().provideResolvedArtifactCache(moduleComponentRepository, resolutionStrategy.isDependencyVerificationEnabled());
if (baseRepository.isDynamicResolveMode()) {
moduleComponentRepository = new IvyDynamicResolveModuleComponentRepository(moduleComponentRepository);
The fix modifies the provideResolvedArtifactCache() method to include a parameter indicating whether dependency verification is enabled for the current resolution strategy, ensuring that verified and non-verified artifacts are properly segregated.
Detection Methods for CVE-2022-23630
Indicators of Compromise
- Unexpected or unauthorized dependencies appearing in build outputs
- Build logs showing dependency resolution patterns where non-verified configurations resolve before verified ones
- Discrepancies between expected dependency checksums and actual resolved artifacts
- Unusual network activity during build processes to untrusted artifact sources
Detection Strategies
- Audit Gradle build scripts for usage of ResolutionStrategy.disableDependencyVerification() method
- Review build configuration files for mixed dependency verification settings across configurations
- Implement artifact integrity monitoring to compare resolved dependencies against known-good checksums
- Enable verbose logging during Gradle builds to track dependency resolution order
Monitoring Recommendations
- Monitor CI/CD pipelines for changes to dependency verification settings
- Implement Software Composition Analysis (SCA) tools to track dependency changes
- Set up alerts for new or modified dependencies in build outputs
- Regularly audit plugin configurations that may disable dependency verification
How to Mitigate CVE-2022-23630
Immediate Actions Required
- Upgrade Gradle to version 7.4 or later immediately
- Audit all build configurations for usage of ResolutionStrategy.disableDependencyVerification() method
- Review and remove plugins that disable dependency verification for single configurations
- Ensure dependency verification is consistently enabled across all configurations
Patch Information
Gradle version 7.4 addresses this vulnerability by validating artifacts at least once if they are present in a resolved configuration that has dependency verification active. The fix ensures that verified and non-verified artifacts are not shared between configurations. Detailed information is available in the Gradle 7.4 Release Notes and the GitHub Security Advisory GHSA-9pf5-88jw-3qgr. The security patch can be reviewed at Gradle Commit 88ab9b6.
Workarounds
- Do not use ResolutionStrategy.disableDependencyVerification() in any build configuration
- Avoid using plugins that disable dependency verification for individual configurations
- Ensure that configurations with dependency verification disabled are never resolved in builds that also resolve configurations with verification enabled
- Consider implementing manual verification steps for all dependencies until upgrade is possible
# Configuration example - Enable dependency verification consistently
# In your build.gradle or settings.gradle
// Do NOT use this pattern as it creates the vulnerability:
// configurations.someConfig.resolutionStrategy.disableDependencyVerification()
// Instead, ensure verification is enabled for all configurations:
// settings.gradle
dependencyResolutionManagement {
// Keep dependency verification enabled globally
// Do not disable on any individual configuration
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

