Most recent entries from all

EUVD-2026-245796

2026-10-05T11:43:49.207736+00:00

EUVD-2026-245796

fkie_cve-2025-52884

2026-10-05T11:43:49.207772+00:00

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.

GHSA-gjv3-89hh-9xq2 — RISC Zero Ethereum invalid commitment with digest value of zero accepted by Steel.validateCommitment

2026-10-05T11:43:49.207812+00:00

Affected: crates.io: risc0-ethereum-contracts

### Impact

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.

### Fix

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].

### Recommended actions

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][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 t…