Improper Verification of Cryptographic Signature Affecting rh-maven36-byte-buddy package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL7-RHMAVEN36BYTEBUDDY-5904713
- published18 Sept 2023
- disclosed14 Jul 2022
Introduced: 14 Jul 2022
CVE-2022-31156 (opens in a new tab)How to fix?
There is no fixed version for RHEL:7 rh-maven36-byte-buddy.
NVD Description
Note: Versions mentioned in the description apply only to the upstream rh-maven36-byte-buddy package and not the rh-maven36-byte-buddy package as distributed by RHEL.
See How to fix? for RHEL:7 relevant fixed versions and status.
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.