CVE-2025-52484: 
Rust vulnerability analysis and mitigation

CVE-2025-52484 is a zkVM underconstrained vulnerability in RISC Zero's risc0-zkvm and risc0-circuit-rv32im Rust crates. Due to a missing constraint in the rv32im circuit, any 3-register RISC-V instruction (including remu and divu) in affected versions is exploitable by a malicious prover, who can confuse the virtual machine into treating the value of the rs1 register as identical to the rs2 register. Affected versions are risc0-zkvm 2.0.0–2.0.2 and risc0-circuit-rv32im 2.0.0–2.0.3. The vulnerability was disclosed on June 18, 2025, and published to the GitHub Advisory Database on June 20, 2025. Despite RISC Zero internally rating the severity as "Critical," the official CVSS v4.0 base score is 2.7 (Low) (GitHub Advisory).

The root cause is classified as CWE-345 (Insufficient Verification of Data Authenticity): the rv32im arithmetic circuit lacks a constraint that would enforce the distinctness of the rs1 and rs2 source registers in 3-register RISC-V instructions (GitHub Advisory). A malicious prover can craft a proof where the circuit is tricked into treating rs1 and rs2 as the same register, allowing the prover to generate a fraudulent but verifier-accepted proof for computations that were never actually performed correctly. The attack vector is network-accessible (AV:N), requires no privileges or user interaction, and has low attack complexity. The fix was implemented by disallowing memory I/O to the same address in the same memory cycle, addressed in zirgen/pull/238 and risc0/pull/3181 (risc0 PR #3181).

Successful exploitation allows a malicious prover to submit fraudulent zero-knowledge proofs that will be accepted as valid by on-chain and off-chain verifiers using the affected zkVM versions. This undermines the integrity guarantees of the RISC Zero zkVM — the core security property of the system — enabling a prover to falsely attest to computations they did not perform. There is no confidentiality or availability impact; the impact is limited to integrity of the proof system, but in blockchain/smart contract contexts this could enable unauthorized state transitions or financial fraud (GitHub Advisory).

No public proof-of-concept exploit code has been released, and the EPSS score is approximately 0.03% (0.000300), indicating a very low probability of exploitation in the near term (GitHub Advisory). The vulnerability was responsibly disclosed by researcher Christoph Hochrainer via the Hackenproof bug bounty program, and RISC Zero paid a bounty. There is no evidence of in-the-wild exploitation or threat actor attribution. The CVE is not listed in the CISA KEV catalog. As a proactive measure, RISC Zero disabled impacted on-chain verifiers via their estop mechanism before public disclosure (GitHub Advisory).

1. Identify target: Locate a system or smart contract that accepts RISC Zero zkVM proofs generated using risc0-zkvm versions 2.0.0–2.0.2 or risc0-circuit-rv32im versions 2.0.0–2.0.3.
2. Craft malicious guest program: Write a RISC-V guest program that uses 3-register instructions (e.g., remu, divu) where the intended computation depends on distinct rs1 and rs2 register values.
3. Exploit missing constraint: During proof generation, manipulate the witness/execution trace so that the circuit treats rs1 and rs2 as the same register, producing a proof for a computation that was not faithfully executed.
4. Submit fraudulent proof: Submit the crafted proof to a verifier (on-chain or off-chain) running the vulnerable version; the verifier accepts the proof as valid due to the missing circuit constraint.
5. Achieve fraudulent attestation: The verifier incorrectly confirms that a computation was performed correctly, potentially enabling unauthorized state changes in smart contracts or bypassing integrity checks in applications relying on zkVM proofs (GitHub Advisory, risc0 PR #3181).

RISC Zero has released patched versions: risc0-zkvm 2.1.0 and risc0-circuit-rv32im 2.0.4. All users of affected Rust crates should upgrade immediately. Smart contract applications using the official RISC Zero Verifier Router do not need to take additional action, as zkVM version 2.1 is now active on all official routers and version 2.0 has been disabled via the estop mechanism. Smart contract applications not using the official verifier router must update their contracts to direct verification calls to the 2.1 version of the verifier (GitHub Advisory).

RISC Zero evaluated the severity internally as "Critical" and paid a bug bounty to the reporting researcher, Christoph Hochrainer, via Hackenproof — indicating the vendor took the issue seriously despite the relatively low official CVSS score (GitHub Advisory). The proactive use of the estop mechanism to disable impacted on-chain verifiers before public disclosure was noted as a responsible incident response measure. No significant broader media coverage or notable community debate has been identified beyond the advisory itself.