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
- 7
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 7 closed, publicly disclosed Optimism reports indexed on Coin Buggie. 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, Integer overflow / underflow, Logic error, 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
- Integer overflow / underflow findings disclosed against Optimism
- Logic error 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: 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: 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: 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: 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: 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: Multiplication overflow leading to memory corruption and incorrect register write-back
The Optimism cannon MIPS.sol VM implements the MUL instruction via unchecked int32 multiplication (uint32(int32(rs) * int32(rt))). The warden argued that overflow in an unchecked block could produce an incorrect value that flows into writeMem and the destination register through step(), causing data corruption. The sponsor and judge pushed back, noting that MIPS spec for MUL explicitly calls for retaining the low-order 32 bits of a 64-bit product with no arithmetic exception, so the wrap-around is actually compliant and the proposed mitigation is functionally equivalent. The report was kept as a Medium based on the finding that the program deviates from the MIPS spec in a way that is 'likely can't be triggered' but could yield invalid state transitions in the fault-proof game.