0x1db80b281db8…1db80b25

ConfirmedSecurity446 vB92 sat/vB2 min decode

Scroll Patches Verifier Flaw That Could Have Forged Finalized State Roots

Scroll registered a corrected Batch Version 10 verifier on Ethereum mainnet on Nov. 10 after a Nov. 3 bounty report; all 748 finalizations in the affected window used normal proofs.

Scroll Patches Ethereum Proof Verifier Flaw, Says It Was Not Exploited
WitnessScroll Patches Ethereum Proof Verifier Flaw, Says It Was Not Exploitedgeralt / pixabay

Outputs

  1. Scroll received the bug bounty report on Nov. 3 and registered a corrected verifier on Nov. 10.

  2. The flaw in the Bundle proof verifier could have let attackers reuse old valid proofs with new inputs to finalize arbitrary state and withdrawal roots.

  3. All 748 finalizations during the vulnerable period used normal proofs; Scroll says forced batch mode was never activated.

  4. Earlier verifier versions were unaffected.

Scroll has patched a vulnerability in the proof verifier for its Ethereum mainnet deployment, registering a corrected verifier for Batch Version 10 on Tuesday, Nov. 10, after a bug bounty report flagged the flaw on Nov. 3.

The zkEVM rollup said the vulnerability was not exploited.

What could the flaw have done?

The bug sat in the Bundle proof verifier deployed on Ethereum mainnet. It could have allowed an attacker to take an old, valid proof and replay it against new public inputs, according to Scroll's disclosure. In practical terms, that means the attacker could have finalized arbitrary state roots and withdrawal roots — the core commitments a rollup posts to its Ethereum settlement layer.

Arbitrary withdrawal roots are the more dangerous half of that equation. If a forged withdrawal root had been finalized, the door opens to claims against state that never existed. The flaw effectively broke the assumption that a verified proof binds to one specific set of inputs.

Exploitation was not trivial, though. An attacker needed either access to a permissioned prover role or activation of forced batch mode — a fallback mechanism that becomes available after seven consecutive days without finalization.

Scroll said forced batch mode was never activated.

How does Scroll know it wasn't exploited?

The project checked its own finalization record. Scroll said all 748 finalizations that occurred during the period the vulnerability was live used normal proofs, not the paths an attacker would have needed. Earlier versions of the verifier were unaffected by the flaw.

The issue was confined to proof verification for batches on Ethereum mainnet. Scroll's remediation was to register the corrected verifier for Batch Version 10, which addresses the input-binding weakness in the Bundle proof verifier.

Why this matters

Verifier bugs occupy a special category of risk in zk-rollup architecture. The entire security model rests on the chain trusting only what a verifier contract accepts, so a flaw that lets a proof be re-cut for new inputs undermines the foundation rather than one application layer on top of it.

The disclosure also shows the guardrails working as designed. Exploitation required a privileged role or a seven-day finalization outage — two conditions that are monitored and neither of which, per Scroll, materialized. The bug bounty pipeline delivered the report on Nov. 3, and a patched verifier was live on mainnet within a week.

For users, the operative facts are the on-chain ones: a corrected Batch Version 10 verifier is registered on Ethereum, the 748 finalizations in the affected window check out as normal, and earlier verifier versions carry no exposure. Anyone verifying Scroll batches should now be running against the fixed verifier.

via tokenpost.com (Source)

More from Daniel Okafor

Daniel Okafor

Show full bio

Correspondent covering people, launches and day-to-day practice in crypto and web3 industry at Mempool Brief.

992 articles