Sign in Subscribe
Vulnerabilities

RISC Zero zkVM Hit by Critical Missing Constraint Flaw Allowing False Proofs

RISC Zero zkVM Hit by Critical Missing Constraint Flaw Allowing False Proofs

Source: RISC Zero zkVM Missing Constraint Vulnerability - HackenProof

Introduction

Imagine a scenario where a mathematical fact as basic as "7 % 5" can be “proven” to equal 50,000 - and that this proof passes as cryptographically valid. In zero-knowledge cryptography, where mathematical proofs must be absolute, this is an impossible failure.

Yet, for several months, one of the most promising zero-knowledge virtual machines (zkVMs) - RISC Zero - had a flaw enabling exactly this kind of false proof.

Founded in 2021, RISC Zero aims to fight centralization by enabling general-purpose computing within zero-knowledge proofs. Its zkVM lets developers prove that Rust code executes correctly off-chain, promising to revolutionize trust in decentralized systems.

What Happened?

On May 15, 2025, security researcher Christoph “zkCrusher” Hochrainer uncovered a critical vulnerability in the rv32im circuit of RISC Zero zkVM versions 2.0.0 through 2.0.2.

The issue: a missing constraint in the RISC-V instruction validation logic that allowed a malicious prover to manipulate how input registers were interpreted during computation.

Specifically, it was possible to confuse the two input registers (rs1 and rs2) in three-register instructions like unsigned division (divu) and remainder (remu). This loophole let provers submit fake computation traces, which the verifier accepted as true.

Why Is This Critical?

At the core of zero-knowledge proofs is the assumption that the prover cannot be trusted - they might lie about execution results. The system’s job is to mathematically enforce soundness, meaning only true statements can be proven.

Here, a missing mathematical check meant the verifier accepted mathematically incorrect outputs.

In other words:

  • Invalid computations passed as valid proofs.
  • The zkVM’s foundational integrity was broken.
  • Any app relying on RISC Zero zkVM (2.0.0-2.0.2) risked accepting fraudulent proofs.
  • On-chain verifiers could be tricked, risking financial and operational consequences.

Technical Deep-Dive

The rv32im circuit encodes rules that ensure RISC-V CPU instructions execute correctly. Registers in this VM are stored in RAM.

For instructions using three registers (two inputs and one output), constraints must guarantee the two inputs (rs1, rs2) are accurately distinguished.

The vulnerability allowed a malicious prover to treat both inputs as the same value - bypassing this essential distinction.

The zero-knowledge proof system failed to detect this inconsistency, breaking soundness.

Reproducing the Vulnerability

The process involves:

  • Setting up a Docker environment to build RISC Zero.
  • Cloning the repository and organizing it correctly:
  • Navigating to a minimal example inside the my_project directory that illustrates the vulnerability.

This example has two components:

  • A guest program runs inside the zkVM, doing a simple remainder operation (7 % 5).
  • A host program supplying inputs and verifying the proof.

When running the host normally, it outputs:

verified that 7 % 5 = 2

But due to the flaw, a malicious prover can produce a proof for:

verified that 7 % 5 = 0

or any other false remainder — and the verifier will accept it.

Impact Summary

  • Complete loss of soundness in RISC Zero zkVM 2.0.x versions.
  • All computations verified by these zkVM versions could be fraudulent.
  • Any decentralized application or protocol relying on this zkVM was vulnerable.
  • On-chain verification processes risked accepting false proofs causing systemic trust breakdown.
  • No practical mitigation was available at the application level — the flaw was at the circuit level.

This affected RISC Zero during a critical growth phase, impacting DeFi projects and scaling solutions building on it.

Resolution & Response

The RISC Zero team promptly:

  • Patched the missing constraint in the rv32im circuit.
  • Released updated risc0 versions with the fix.
  • Disabled impacted on-chain verifiers using an emergency stop ("estop") mechanism.

This quick action prevented further exploitation on live systems.

Read next