CVE-2025-52884

lowPriorität · verfolgen · 0EPSS 0.004 · 35. PerzentilEUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.41% (35th) EPSS
CVSS 1.7 · low
Is it mine?
2 products
Prüfe deine Angriffsfläche
Who says so?
3 sources
cnnvd · enisa_euvd · osv

EPSS · bewertet 2026-10-26

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.

01

cvss

Technischer Schweregrad, 0–10. Eine Zeile je Quelle.

1.7
010

Basiswert 0–10 · höher = schwerwiegender · Vektor überfahren zum Auflösen

v4.01.7lowCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:Usecondary · ENISA EU
v4.01.7lowCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · security-advisories@github.com
v4.01.7lowCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · CVSS-BT (t0sche)
02

SSVC

Eine Handlungsentscheidung — aus Ausnutzung und Auswirkung.

Exploitation: poc · Automatable: no · Technical Impact: partialcoordinatorcisa_ssvcUS
03

schwächen

Die CWE-Schwächeklassen, zu denen dies gehört.

04

betroffene Produkte (2)

Betroffene Produkte und Versionsbereiche.

05

Advisories (1)

Hersteller- und Ökosystem-Meldungen dazu.

  • GHSA-gjv3-89hh-9xq2RISC Zero Ethereum invalid commitment with digest value of zero accepted by Steel.validateCommitment2025-06-25ghsa · osvUS

    ### 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 their application to do so, as this is incorrect usage of Steel. ### Credit A thank you to Daniel526 on HackenProof for reporting this issue [#605]: https://github.com/risc0/risc0-ethereum/pull/605 [example]: https://github.com/risc0/risc0-ethereum/blob/ff0cb9253a87945b653b825711b8b5075f8b7545/examples/erc20-counter/contracts/src/Counter.sol#L56-L63 [documentation]: https://docs.beboundless.xyz/developers/steel/how-it-works#verifying-the-proof-onchain [2.1.1]: https://github.com/risc0/risc0-ethereum/releases/tag/v2.1.1 [2.2.0]: https://github.com/risc0/risc0-ethereum/releases/tag/v2.2.0

06

auch bekannt als (3)

Weitere Namen und Kennungen dieser Entität.

07

quellen

Welche Quellen diesen Datensatz belegen und wann.

veröffentlicht 2025-06-24geändert 2026-06-17
08

Referenzen (23)

Externe Belege — Patches, Meldungen, Analysen.

scry

Angreifer nutzen Schwachstellen wie diese gegen im Internet exponierte Dienste aus. Sehen Sie mit einem kostenlosen Passiv-Scan, was exponiert ist.

Kostenloser Scan