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
- 15
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 15 closed, publicly disclosed Taiko 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 Logic error, Access control, Bridge exploit, Front-running / MEV, Governance attack, 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
- Bridge exploit findings disclosed against Taiko
- Front-running / MEV findings disclosed against Taiko
- Governance attack 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: 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: 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: 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: Malicious caller of `processMessage()` can pocket the fee while forcing `excessivelySafeCall()` to fail
The Taiko bridge protocol contained a vulnerability where relayers could maliciously claim processing fees without successfully completing the cross-chain message delivery. By exploiting the 63/64th gas rule, an attacker could force the message execution to fail while still triggering the bridge's payment logic, which did not verify the success of the underlying transaction. This allowed relayers to grief users and misappropriate fees for incomplete relay tasks.
Taiko: Bridged tokens would be lost if sender and receiver are contracts that don't implement fallback/receive
The Taiko bridge protocol was vulnerable to a denial-of-service issue where token transfers would fail if the recipient address was a contract lacking fallback or receive functions. The protocol's ERC20Vault contract incorrectly attempted to execute an ether transfer via a low-level call, even when the transfer value was zero. This triggered a revert on the destination chain, effectively locking the bridged assets and preventing transaction finalization. In some cases, this could also block the recall of messages, trapping the funds indefinitely.
All reports in this group
- Taiko: Gas issuance is inflated and will halt the chain or lead to incorrect base feeLogic error$0
- Taiko: Invocation delays are not honoured when protocol unpausesFront-running / MEV$0
- Taiko: A recalled ERC20 bridge transfer can lock tokens in the bridgeBridge exploit$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: There is no slippage check for the eth deposits processing in the `LibDepositing.processDeposits`Logic error$0
- Taiko: Bridge watcher can forge arbitrary message and drain bridgeAccess control$0
- Taiko: The top tier prover can not re-proveGovernance attack$0
- Taiko: Users will never be able to withdraw their claimed airdrop fully in ERC20Airdrop2.sol contractLogic error$0