If you keep assets on Scroll, or you depend on its bridge when you want funds back on Ethereum, the question is whether a finalized withdrawal root still matches the state you expect.
PANews reported on November 11, 2026, that Scroll had posted a report on its governance forum. The report says Scroll received a bug-bounty submission on November 3 about a flaw in the bundle proof verification contract on Ethereum mainnet, and that on November 10 it registered a repaired verification contract for batch version 10.
As described in that report, an old valid proof could be paired with new public inputs. That path could, in principle, be used to finalize arbitrary state roots and withdrawal roots. Exploitation was not open to an arbitrary caller: it required the permissioned prover role, or the forced batch mode that becomes available only after seven days without finalization.
Scroll said its check found the flaw was not used on mainnet. All 748 finalizations while the vulnerable verification contract was active used ordinary proofs. Forced mode was never turned on. Earlier versions of the verification contract were unaffected.
The trade-off in the reported design is narrow access versus delayed fallback. A permissioned prover, or a forced mode that opens only after a week of silence, is a smaller attack surface than a public function, but both still sit on the boundary that decides which state root and withdrawal root become final. Scroll’s statements cover that specific window: no mainnet use, 748 normal finalizations, forced mode never enabled, and prior verifier versions unaffected. The report does not claim those checks remove every other risk in bridging or self-custody, and it does not list extra steps for holders beyond the version-10 verifier already registered.
Original report: PANews
