Prior to 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. Leveraging this bug to compromise the soundness of an application 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 (e.g. having the guest commit to a digest of zero, or failing to check the zkVM proof).
Because this bug does not risk application integrity, correctly written applications are not at risk.
Please see [#605] for a full description of the bug, and the fix. This 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.
A thank you to Daniel526 on HackenProof for reporting this issue
{ "nvd_published_at": "2025-06-24T21:15:26Z", "cwe_ids": [ "CWE-159" ], "severity": "LOW", "github_reviewed": true, "github_reviewed_at": "2025-06-25T21:27:59Z" }