- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
RISC Zero zkVM was designed from its inception to provide three main guarantees: 1. *Computational integrity*: that a given software program executed correctly. 2. *Succinctness*: that the proof of execution does not grow in relation to the program being executed. 3. *Zero Knowledge*: that details of the program execution are not visible within the proof of program execution.
Ulrich Habock and Al Kindi have released [new research] that indicates that several STARK implementations -including our RISC Zero zkVM- do not meet the requirements to assert the specific property of zero knowledge provably.
While a vast majority of real-world applications that leverage RISC Zero zkVM or similar systems depend primarily on computational integrity and succinctness, a subset of applications critically depend on the privacy guarantees provided by zero-knowledge; and for those use cases, users are cautioned to understand the research and make informed decisions based on the risks outlined in using an impacted system.
Although the maintainers are not aware of any attacks that can take advantage of this potential weakness, they are working to proactively address this discovery as quickly as possible.
[new research]: https://eprint.iacr.org/2024/1037
Is GHSA-5xgj-pmjj-gw49 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | risc0-zkvm | <=1.0.2 |
no fix listed |
References
Sources
- GitHub Advisory GHSA-5xgj-pmjj-gw49
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.