https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 14:12:03 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-245796 EUVD-2026-245796 https://cve.radiocsirt.org/vuln/euvd-2026-245796 https://cve.radiocsirt.org/vuln/fkie_cve-2025-52884 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-52884 https://cve.radiocsirt.org/vuln/ghsa-gjv3-89hh-9xq2 <p><strong>Affected:</strong> crates.io: risc0-ethereum-contracts</p> <p>### Impact</p> <p>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.</p> <p>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).</p> <p>Because this bug does not risk application integrity, correctly written applications are not at risk.</p> <p>### Fix</p> <p>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].</p> <p>### Recommended actions</p> <p>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.</p> <p>Users not verifying a zkVM proof of a Steel program should update t…</p> <p><strong>Affected:</strong> crates.io: risc0-ethereum-contracts</p> <p>### Impact</p> <p>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.</p> <p>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).</p> <p>Because this bug does not risk application integrity, correctly written applications are not at risk.</p> <p>### Fix</p> <p>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].</p> <p>### Recommended actions</p> <p>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.</p> <p>Users not verifying a zkVM proof of a Steel program should update t…</p> https://cve.radiocsirt.org/vuln/ghsa-gjv3-89hh-9xq2