CVE-2025-52884 in risc0-ethereum
Summary
by MITRE • 06/25/2025
RISC Zero is a zero-knowledge verifiable general computing platform, with Ethereum integration. The risc0-ethereum repository contains Solidity verifier contracts, Steel EVM view call library, and supporting code. Prior to versions 2.1.1 and 2.2.0, the `Steel.validateCommitment` Solidity library function will return `true` for a crafted commitment with a digest value of zero. This violates the semantics of `validateCommitment`, as this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel and leveraging this bug to compromise the soundness of a program using Steel would require a separate bug or misuse of the Steel library, which is expected to be used to validate the root of state opening proofs. A fix has been released as part of `risc0-ethereum` 2.1.1 and 2.2.0. Users for the `Steel` Solidity library versions 2.1.0 or earlier should ensure they are using `Steel.validateCommitment` in tandem with zkVM proof verification of a Steel program, as shown in the ERC-20 counter example, and documentation. This is the correct usage of Steel, and users following this pattern are not at risk, and do not need to take action. Users not verifying a zkVM proof of a Steel program should update their application to do so, as this is incorrect usage of Steel.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 06/25/2025
The vulnerability identified as CVE-2025-52884 affects the RISC Zero zero-knowledge verifiable computing platform, specifically within the risc0-ethereum repository's Solidity verifier contracts and Steel EVM view call library. This issue resides in the `Steel.validateCommitment` function where a crafted commitment with a digest value of zero incorrectly returns true, creating a fundamental breach in the commitment validation semantics. The vulnerability represents a critical flaw in the cryptographic integrity verification process that undermines the security assumptions of the entire system.
The technical flaw manifests when the `validateCommitment` function fails to properly validate that a commitment actually corresponds to a legitimate block within the current blockchain chain. When a digest value of zero is presented, the function erroneously accepts it as valid, even though zero digest values cannot correspond to any actual blockchain block and therefore cannot have valid openings. This creates a scenario where malicious actors could potentially exploit this weakness to bypass proper validation checks, though the vulnerability alone does not directly compromise soundness without additional flaws or misuse of the library. The issue is classified under CWE-284 Access Control Bypass, as it allows unauthorized validation of invalid commitments, and aligns with ATT&CK technique T1068 Valid Accounts for potential misuse in bypassing proper verification mechanisms.
The operational impact of this vulnerability extends beyond simple validation failures, as it affects the core trust model of the RISC Zero platform when integrated with Ethereum. Applications relying on the Steel library for commitment verification may accept invalid commitments that appear legitimate due to the flawed validation logic. This creates a potential attack surface where adversaries could manipulate the verification process without directly compromising the underlying zkVM proofs, though the actual security implications depend heavily on how the library is being used. The vulnerability particularly impacts systems where the Steel library is used without proper zkVM proof verification, which represents a misuse pattern that the security team has explicitly identified as problematic.
Mitigation strategies for CVE-2025-52884 require immediate action from affected users. The primary fix involves upgrading to risc0-ethereum versions 2.1.1 or 2.2.0, which contain the corrected implementation of the `validateCommitment` function. Users operating on versions 2.1.0 or earlier must ensure they are implementing proper zkVM proof verification alongside the Steel library usage, as demonstrated in the ERC-20 counter example provided in the documentation. This dual verification approach is essential for maintaining the security guarantees of the platform, since the vulnerability only becomes exploitable when the Steel library is used without proper zkVM proof validation. Organizations should also conduct comprehensive audits of their implementations to ensure they are following the correct usage patterns and not relying solely on the Steel library for commitment validation without proper cryptographic proof verification.