The current report says Scroll patched a flaw in its Ethereum mainnet bundle-proof validator for batch version 10 on November 10, after receiving a bounty report on November 3. Scroll also concluded that the bug was not exploited on mainnet, despite the reported risk that old valid proofs could be reused with new public inputs to confirm arbitrary state roots and withdrawal roots.

What the reported Scroll validator flaw could have done

According to the report, the flaw could have allowed an old valid proof to be accepted with new public inputs, potentially enabling the confirmation of arbitrary state roots and withdrawal roots. Put simply, this describes a failure to bind a proof to its intended inputs: a validator could regard a proof as valid for data it was not meant to approve.

This matters because state roots and withdrawal roots are not minor bookkeeping fields. If the reported mechanism is accurate, it would affect what the validator accepts as finalized on mainnet, rather than merely causing delays or processing failures. The reported risk therefore involves the confirmation of incorrect commitments, although the available material does not establish that this would necessarily have led to successful fraudulent withdrawals.

The same report says earlier validator versions were unaffected. However, it does not include the code changes, validator registration record, or technical postmortem needed to show precisely how batch version 10 resolved the proof-to-input mismatch.

Why Scroll says the bug was not used on mainnet

According to the report, Scroll’s conclusion rests on two points. Exploiting the flaw required either a permissioned prover role or forced batch mode after seven days without finalization. Scroll said forced mode was never enabled, while all 748 finalizations during the affected period used normal proofs. This makes the bug a vulnerability on a restricted path, rather than one that any ordinary external user could openly exploit.

Within the scope of the report, the no-exploitation conclusion follows from those access restrictions and an operational review. If forced mode was never activated and every reviewed finalization used normal proofs, Scroll is effectively saying that the route required for abuse never existed on mainnet during the affected period.

The main limitation is that the underlying Scroll disclosure, validator registration record, and review methodology for the 748 finalizations were not included in the current report. The most precise reading, therefore, is that Scroll said the bug was not exploited and provided specific reasons for that conclusion, but those reasons were not independently verified here.

Reported timeline and key details

Within the scope of the same current report, these are the main details related to the validator issue: