Optimism — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Optimism, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 14
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 14 closed, publicly disclosed Optimism reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Oracle manipulation, Access control, Logic error, Integer overflow / underflow, across EVM-Solidity, Move. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Oracle manipulation findings disclosed against Optimism
- Access control findings disclosed against Optimism
- Logic error findings disclosed against Optimism
- Integer overflow / underflow findings disclosed against Optimism
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Optimism: LPP metadata can be altered after the challenge period is over, allowing incorrect states to be proven
The Optimism PreimageOracle allows for the manipulation of Large Preimage Proposal (LPP) metadata, even after the challenge period has concluded. By exploiting a lack of re-initialization checks and redundant storage reads, an attacker can overwrite critical proposal data. This manipulation compromises the integrity of the MIPS VM state, as the system can be coerced into accepting fraudulent preimage data due to the absence of consistency checks in the `squeezeLPP` function.
Optimism: An attacker can bypass the challenge period during LPP finalization
The Optimism PreimageOracle protocol contains a logic vulnerability that allows attackers to bypass the mandatory challenge period for Large Preimage Proposals (LPP). By intentionally failing to finalize the proposal during data submission, an attacker leaves the proposal's timestamp uninitialized (zero), causing the finalization check to inadvertently pass. This allows malicious or invalid preimage data to be finalized instantly, undermining the integrity of the oracle and the dispute mechanism.
Optimism: L2 precompile calls can be impossible to reproduce on L1
Optimism's fault-proof system uses a PreimageOracle on L1 to re-execute specific L2 precompiles. Certain precompiles, such as bn256Pairing, have dynamic gas costs that allow them to consume nearly the full block gas limit in a single transaction. Due to the inherent gas overhead in the L1 verification function and the EIP-150 gas forwarding limit, these high-gas L2 transactions cannot be successfully re-executed on L1. This failure prevents the fault-proof system from validating these specific state transitions, potentially allowing invalid L2 state to remain uncorrected.
Optimism: The LPP challenge period can cause malicious and freeloader claims to be uncounterable and can also cause freeloader claims to be abused to entrap honest challengers
The Optimism Fault Dispute Game mechanism suffered from an insufficient clock extension issue when handling large preimage proposals (LPPs). Attackers could force honest challengers into a situation where they needed to interact with the preimage oracle to counter a claim, but were left with insufficient time on their chess clock to complete the mandatory challenge period. This vulnerability allowed attackers to steal bonds from honest challengers by making their claims uncounterable within the allocated time constraints.
Optimism: Unvalidated memory access in `readMem` and `writeMem` functions
The readMem and writeMem functions in the Cannon MIPS implementation lack sufficient bounds checking for memory addresses. This oversight allows an attacker to perform unauthorized read or write operations across the entire 32-bit address space. Such memory manipulation compromises the integrity of the fault proof state machine by allowing the corruption of critical system data, including program counters and preimage state.
Optimism: Invalid `DISPUTED_L2_BLOCK_NUMBER` is passed to VM
Optimism's FaultDisputeGame computes the DISPUTED_L2_BLOCK_NUMBER preimage handed to the op-program as startingBlock + traceIndex + 1 without bounding it by the game's actual claimed block. When the split-depth game tree span exceeds the distance from the starting block to the claimed block, the VM keeps executing past the target and only halts at the L2 safe head, so a legitimate claim on an earlier block can be challenged and ruled invalid. Because the claimed block number is never passed to the VM, an identical valid block transition can be defended inside one game and attacked inside another, exposing missing game context. The fix caps the derived block number with min(startingBlock + traceIndex + 1, l2BlockNumber()) so the op-program stops at the claimed block.
All reports in this group
- Optimism: Honest party's move could become invalid when re-org takes placeLogic error$0
- Optimism: The LPP proposer may not be reimbursed their gas costs by the bonds at `MAX_GAME_DEPTH` because `step()` does not check if the LPP proposer is the one that called itLogic error$0
- Optimism: Missing address check for instructions LH and LHULogic error$0
- Optimism: In some cases, proper `CLOCK_EXTENTSION` time cannot be ensured to generate the initial instruction traceLogic error$0
- Optimism: Multiplication overflow leading to memory corruption and incorrect register write-backInteger overflow/underflow$0
- Optimism: Addresses can be pre-populated with bad dataLogic error$0
- Optimism: Attacker can continuously create games for not yet safe l2 blocks to prevent the update of anchor stateLogic error$0
- Optimism: `MIPS` - Incorrect implementation of SRAV instructionLogic error$0