Taiko — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Taiko, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 18
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 18 closed, publicly disclosed Taiko 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 Logic error, Access control, Governance attack, Bridge exploit, Front-running / MEV, 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
- Logic error findings disclosed against Taiko
- Access control findings disclosed against Taiko
- Governance attack findings disclosed against Taiko
- Bridge exploit findings disclosed against Taiko
- Front-running / MEV findings disclosed against Taiko
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Taiko: Incorrect __Essential_init() function is used in TaikoToken making snapshooter devoid of calling snapshot()
The TaikoToken contract was initialized with an incorrect configuration function, causing the address resolution system to remain uninitialized. This error prevented the contract from verifying the 'snapshooter' role, effectively blocking the ability to take system snapshots. The issue necessitated an administrative override or manual intervention until it was formally patched.
Taiko: Users will never be able to withdraw their claimed airdrop fully in ERC20Airdrop2.sol contract
The ERC20Airdrop2.sol contract for Taiko's token airdrop contained a logic error that caused user tokens to become permanently locked. The issue stemmed from an overly restrictive modifier that prevented users from withdrawing tokens once the designated withdrawal window elapsed, even though the tokens were fully unlocked at that point. Because the withdraw function reverted after the window closed, any users who delayed their claims were effectively denied access to their funds, resulting in potential total loss of the allocated airdrop.
Taiko: Taiko SGX Attestation - Improper validation in certchain decoding
Taiko relies on SGX provers for its ZK proof architecture, utilizing remote attestation to verify the trustworthiness of these provers. A flaw was identified in the certificate chain validation logic within the attestation process, where the library responsible for parsing X.509 certificates failed to correctly validate the ASN.1 tag for the certificate's 'notBefore' field. This vulnerability could allow an attacker to submit certificates with arbitrary or invalidly formatted time tags, potentially undermining the integrity and reliability of the SGX prover attestation mechanism.
Taiko: Validity and contests bond ca be incorrectly burned for the correct and ultimately verified transition
The Taiko protocol suffers from a logic error in its proof-of-validity and contest bonding system, leading to the potential for honest provers and contesters to have their funds permanently slashed. This occurs during complex multi-tier proving scenarios where a transition is contested and later verified as correct by a Guardian, but the contract fails to track the historical validity of the initial proof. Consequently, funds are effectively frozen as there is no mechanism for the protocol to issue refunds for these incorrectly slashed bonds.
Taiko: First block proposer check in the `LibProposing._isProposerPermitted` function is errorneous
A flaw in the LibProposing library causes the first block proposal after genesis to fail whenever a general 'proposer' address is configured. The authorization logic incorrectly continues to validate the sender against the general 'proposer' even after successfully verifying them as the authorized 'proposer_one'. This design oversight causes valid transactions from the genesis proposer to be rejected, resulting in a denial of service for the network's initial block production.
Taiko: LibProposing:proposeBlock allows blocks with a zero parentMetaHash to be proposed after the genesis block and avoid parent block verification
Taiko's block-proposal validation in LibProposing.proposeBlock only enforces parentMetaHash consistency when the caller supplies a non-zero value, so a proposer can submit a post-genesis block with a zero parent metadata hash and have it accepted. Because the on-chain record now lacks a genuine parent reference, honest independent provers who reconstruct the real parent metadata from on-chain state fail the parent-match check and their proveBlock calls revert with L1_BLOCK_MISTATCH. This lets a malicious proposer artificially contest a block whose winning transition cannot be used for verification, destabilizing the block lifecycle. The Taiko team confirmed the fix of rejecting zero parentMetaHash for every block other than genesis.
All reports in this group
- Taiko: The top tier prover can not re-proveGovernance attack$0
- Taiko: There is no slippage check for the eth deposits processing in the `LibDepositing.processDeposits`Logic error$0
- Taiko: A recalled ERC20 bridge transfer can lock tokens in the bridgeBridge exploit$0
- Taiko: Invocation delays are not honoured when protocol unpausesFront-running / MEV$0
- Taiko: Proposers would choose to avoid higher tier by exploiting non-randomness of parameter used in getMinTier()Logic error$0
- Taiko: Taiko L1 - Proposer can maliciously cause loss of funds by forcing someone else to pay prover's feeGovernance attack$0
- Taiko: Signatures can be replayed in `withdraw()` to withdraw more tokens than the user originally intended.Signature replay$0
- Taiko: Bridge watcher can forge arbitrary message and drain bridgeAccess control$0
- Taiko: Gas issuance is inflated and will halt the chain or lead to incorrect base feeLogic error$0
- Taiko: The decision to return the liveness bond depends solely on the last guardianLogic error$0
- Taiko: Malicious caller of `processMessage()` can pocket the fee while forcing `excessivelySafeCall()` to failBridge exploit$0
- Taiko: Bridged tokens would be lost if sender and receiver are contracts that don't implement fallback/receiveBridge exploit$0