CVE-2025-52884
BaseFortify
Publication date: 2025-06-24
Last updated on: 2025-06-26
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-159 | The product does not properly filter, remove, quote, or otherwise manage the invalid use of special elements in user-controlled input, which could cause adverse effect on its behavior and integrity. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-52884 is a vulnerability in the Steel.validateCommitment function of the Steel.sol Solidity library used in the risc0-ethereum project. The function incorrectly returns true for a crafted commitment with a digest value of zero, which does not correspond to any block in the current blockchain and has no valid openings. This violates the intended semantics of validateCommitment, as such a commitment should not be considered valid. Exploiting this flaw to compromise the soundness of a program using Steel requires an additional bug or misuse of the Steel library, such as failing to verify zkVM proofs alongside validateCommitment. The issue was fixed in versions 2.1.1 and 2.2.0 by modifying the validation logic to revert on invalid timestamps and improving block commitment validation to prevent acceptance of invalid commitments. [2, 3, 5]
How can this vulnerability impact me? :
This vulnerability can impact applications using the Steel Solidity library if they rely solely on Steel.validateCommitment without verifying zkVM proofs. In such cases, an attacker could craft a commitment with a zero digest that incorrectly passes validation, potentially compromising the soundness of the program's logic that depends on these commitments. However, applications that correctly use Steel by validating zkVM proofs alongside validateCommitment, as recommended in the official documentation and examples, are not at risk. Exploiting this vulnerability requires either a separate bug or misuse of the Steel library. [2, 3, 5]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability relates to the Steel.validateCommitment Solidity function incorrectly returning true for a crafted commitment with a zero digest. Detection involves verifying if your application uses Steel versions prior to 2.1.1 or 2.2.0 and whether it uses Steel.validateCommitment without proper zkVM proof verification. There are no specific network or system commands provided to detect this vulnerability directly. Instead, detection is primarily through code and version audit: check the Steel library version in use and confirm that zkVM proof verification is implemented alongside validateCommitment as per the ERC-20 counter example and documentation. [2, 4]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading the risc0-ethereum Steel library to version 2.1.1 or later (including 2.2.0), where the vulnerability is fixed. Additionally, ensure that your application uses Steel.validateCommitment in conjunction with zkVM proof verification of Steel programs, following the correct usage pattern demonstrated in the ERC-20 counter example and official documentation. If your application currently does not verify zkVM proofs, update it to do so to avoid misuse of the Steel library. These steps prevent acceptance of invalid commitments with zero digests and preserve program soundness. [2, 5]