Taiko lost $1.7 million on June 22, 2026, after an attacker found a private signing key sitting in a public GitHub repository and used it to forge withdrawal proofs on the Ethereum Layer 2 network’s bridge. The protocol halted block production network-wide, paused its main bridge and ERC-20 vault, and told every user to withdraw funds from any Taiko-deployed bridge immediately. The TAIKO token fell as much as 20% within hours, trading near $0.069 to $0.073 against a token already sitting close to its all-time low. Security firms BlockSec Phalcon, PeckShield, Blockaid, and QuillAudits independently traced and confirmed the root cause within hours: an RSA-3072 private key for Taiko’s hardware-based prover system, never meant to leave secure silicon, had been sitting in a publicly accessible code repository.
What follows is the full technical reconstruction: what the attacker found, how a leaked key became forged transactions, what Taiko’s architecture got right and where it failed, what could have prevented it, and how this incident compares to the other major bridge exploits of 2026.
The Incident in Three Parts
The vulnerability
The exposed key, enclave-key.pem, is integral to Taiko’s SGX trust model. With this key, an attacker could legitimately derive the authorized signer signature, sign malicious SGX instances, and register as a trusted prover.
The exploit
The attacker registered their own controlled SGX instance, bypassed proof verification, and forged source signals to submit fraudulent cross-chain bridging messages. They called retryMessage on the Ethereum L1 side, successfully tricking the bridge into releasing native assets.
The response
Taiko halted block production, activated its Security Council multisig to pause the affected L1 bridge and ERC20Vault contracts, and urged users to withdraw funds from all deployed bridges.
Sources: Charles Guillemet (Ledger CTO) via LinkedIn, P3b7 on X, Incrypted, KuCoin, CoinEx, The Defiant | @cryptonewsbytes
What Happened: The Timeline
The attacker’s setup transaction landed on Ethereum at 22:18:23 UTC on June 21, 2026, registering fraudulent SGX prover instances using the leaked key. Blockaid’s monitoring system flagged the unusual activity in real time, and the firm credits its detection with limiting the scope of losses, with containment occurring between roughly 02:00 and 02:08 a.m. ET on June 22. Taiko posted a security notice on X at approximately 8:44 p.m. ET that Sunday: “We have confirmed a compromise of Taiko’s chain state verification mechanism. As a result, the security assumptions of all bridges deployed on Taiko can no longer be relied upon.” The Security Council, a multisig governance body, was activated. All block proposers stopped producing blocks. Centralized exchanges including Upbit, Bithumb, and KuCoin moved to suspend TAIKO deposits and withdrawals. By the team’s own end-of-day update, the exploit had been contained and “the remaining funds in the bridge are safe.”
Taiko Exploit: Hour by Hour
June 21-22, 2026 timeline | Sources: Blockaid, PeckShield, DarkNavy, Taiko official statements | @cryptonewsbytes
Sources: DarkNavy on-chain forensics, Blockaid, PeckShield, Taiko.eth on X | @cryptonewsbytes
How It Happened: The Technical Mechanism
Taiko’s bridge relies on a multi-prover system called Raiko, which combines Intel Software Guard Extensions (SGX) hardware attestation with zero-knowledge proof backends including SP1 and RISC0. SGX creates encrypted, isolated memory regions called enclaves inside server-class CPUs. The entire security premise rests on one guarantee: the signing key used to certify an enclave as genuine never leaves secure hardware. An RSA-3072 private key called `enclave-key.pem`, used to sign these SGX attestations, had been committed to the public `taikoxyz/raiko` GitHub repository, visible to anyone who knew where to look.
Taiko’s L1 bridge contracts authenticate enclaves using a field called `MrSigner`, a hash derived from the public portion of that same signing key. Any enclave whose signature matches the stored `MrSigner` value is accepted as legitimate, with no further check on who actually controls the hardware. With the private key in hand, the attacker did not need to compromise any physical server. They registered their own software-only SGX instances and the verifier accepted them, because the cryptographic check was satisfied even though the trust assumption behind it, that only Taiko’s real hardware held that key, no longer held.
DarkNavy’s on-chain forensic analysis identified the exact mechanism inside the bridge contracts: the Bridge proxy delegates source-message authenticity to `SignalService.proveSignalReceived()`, which accepts a Merkle proof against any saved checkpoint, not specifically a checkpoint tied to a verified, honest prover. The attack unfolded in two phases. First, the attacker used the forged enclave registration to submit a fabricated Taiko L2 state checkpoint, generating fake attestations claiming a transaction history that never occurred on the actual Taiko chain. Those forged attestations enabled calls to `processMessage()`, which set ten separate withdrawal statuses to `RETRIABLE`, a status meant only for legitimate pending withdrawals. Second, `retryMessage()` executed against those fraudulently elevated statuses with minimal additional verification, releasing real ETH and ERC-20 tokens, including USDC, USDT, crvUSD, WBTC, weETH, CRV, and TAIKO, from both the Bridge contract and the ERC20Vault on Ethereum mainnet. The chain did exactly what it was cryptographically told to do. The instruction it received was forged.
How the Attack Reached On-Chain Funds
Five steps from leaked key file to drained vault | Sources: DarkNavy, QuillAudits, BlockSec Phalcon | @cryptonewsbytes
enclave-key.pem committed to public repo
RSA-3072 key, taikoxyz/raiko on GitHub
Attacker registers forged SGX instances
MrSigner check passes, no real hardware needed
Fake L2 checkpoint submitted
No corresponding activity on real Taiko chain
processMessage() marks withdrawals RETRIABLE
10 message statuses fraudulently elevated
retryMessage() releases real funds
ETH, USDC, USDT, WBTC, weETH drained from Bridge and ERC20Vault
What never broke: the SGX hardware itself
No real enclave was compromised. The cryptographic check was satisfied by a key that should never have been exposed.
Not financial advice. Sources: DarkNavy on-chain forensics, QuillAudits, BlockSec Phalcon, Blockaid postmortem | @cryptonewsbytes
Why the Architecture Made One Leak Catastrophic
Taiko’s multi-prover design was meant to be resilient: Raiko combines SGX attestation with independent ZK proof backends specifically so that defeating any single proof system should not be sufficient to forge a valid withdrawal. L2Beat’s technical registry confirms that Taiko mandates SGX (Geth) alongside at least one other proof system for every proposal range. In principle, an attacker needs to defeat multiple, architecturally independent systems simultaneously.
In practice, at the time of the exploit, the ProverWhitelist controlling who could submit SGX attestations had just one registered prover, meaning a single key compromise was sufficient to forge that entire leg of the verification stack. The Defiant noted that Taiko’s layered design, combining SGX with ZK backends like SP1 and RISC0, was intended to require simultaneous defeats of independent proof systems, but the operational failure, a key exposed in a public repository, bypassed that layered design entirely rather than defeating it. A second compounding factor, identified in DarkNavy’s forensic writeup, is that `INSTANCE_VALIDITY_DELAY` was set to zero, meaning there was no required waiting period between registering a new SGX instance and using it to authorize a high-value withdrawal. Same-transaction registration-to-withdrawal was technically possible. That single configuration value removed what would otherwise have been a window for anomaly detection or manual intervention before funds left the vault.
OpenZeppelin conducted three comprehensive audits of the Taiko protocol across multiple versions, identifying 113 issues including 13 critical and high-severity vulnerabilities, all resolved before deployment. None of that audit work touched the operational security of key material inside the team’s developer pipeline, because that is not what a smart contract audit is built to examine. The contracts behaved exactly as written. The key that was supposed to never leave hardware never should have been in a file at all.
Comparison: How Taiko Differs From and Resembles Other 2026 Bridge Hacks
2026 DeFi Exploits: Where the Trust Actually Broke
Polymarket broke trust before the chain ever saw a transaction. The rest broke trust inside the chain itself. | @cryptonewsbytes
| Incident | Date | Amount | Entry point | Trust layer broken |
|---|---|---|---|---|
| Taiko | Jun 22, 2026 | $1.7M | Leaked SGX signing key on GitHub | Hardware attestation (TEE) |
| Polymarket | Jun 25, 2026 | $3.1M | Compromised vendor, frontend JS injection | User-facing website, not the chain |
| Kelp DAO | Apr 18, 2026 | $292M | Forged LayerZero cross-chain message | Cross-chain message verification |
| Verus-Ethereum bridge | May 2026 | $11.58M | Forged transfer | Bridge configuration |
| Axelar-Secret Network | 2026 | $4.67M | Infinite-mint exploit | Token supply logic |
| Gravity Bridge | 2026 | $5.4M | Not specified in public reporting | Bridge contract |
| Alephium TokenBridge | 2026 | $815K | Not specified in public reporting | Bridge contract |
Total 2026 cross-chain bridge losses: $340.7M+ across 14+ exploits, per PeckShield. Polymarket figure separate, not a bridge exploit. Sources: PeckShield, The Defiant, MEXC News, AMLBot, CNB prior coverage | @cryptonewsbytes
The shared failure mode across every entry on this list is the same: the destination chain was made to believe a withdrawal was legitimate when no corresponding deposit had genuinely occurred on the source chain. What distinguishes Taiko is where the chain of trust broke. Kelp DAO’s $292 million loss in April, the largest DeFi exploit of 2026, came from a forged LayerZero message exploiting a single compromised validator node in the cross-chain messaging layer. The Verus-Ethereum and Axelar-Secret Network incidents involved flaws in bridge configuration and token supply logic respectively. Taiko’s breach began one step earlier than all of them: not with a flaw in cross-chain messaging code, but with a credential that never should have existed in a version-controlled file in the first place. As The Defiant put it, the pattern is different in each case, but the shared failure mode is access control over the infrastructure layer that L1 contracts trust to validate L2 state.
What Could Have Prevented This
DarkNavy’s technical writeup lists specific remediations that map directly onto where the failure occurred. First, secret scanning: automated tools like GitHub’s own secret scanning or git-secrets would have flagged a `.pem` private key file at commit time, before it ever reached a public branch. This is a solved problem in conventional software security, and its absence here was a process failure, not a research gap. Second, the `INSTANCE_VALIDITY_DELAY` should never have been set to zero for a system protecting bridge custody; an effective challenge or finality delay between SGX instance registration and high-value message processing would have created a window in which anomalous registrations could be detected and frozen before funds moved. Third, DarkNavy recommends requiring multi-prover or committee quorum for any checkpoint root that can unlock L1 custody, rather than accepting a single freshly registered SGX path as sufficient for immediate withdrawal authorization, closing the single-point-of-failure gap that the one-prover whitelist created.
Fourth, and most structurally: source-message authenticity should be enforced at the Bridge layer through a canonical source-chain checkpoint with independent finality guarantees, rather than accepting a storage proof under any newly saved checkpoint as sufficient to unlock custody. None of these fixes require new cryptography. They are operational and architectural disciplines: rotate and properly isolate signing keys, never commit secrets to version control, require time delays before high-value actions, and avoid single points of failure in any system whose compromise can move real money. Taiko’s team has stated it is preparing a full post-mortem and pursuing both technical and legal action, and has published the attacker’s wallet addresses publicly, with reimbursement pledged from the protocol treasury for affected users.
The Broader Lesson for TEE-Based and ZK-Rollup Bridges
Taiko’s incident matters beyond its own $1.7 million loss because Trusted Execution Environment technology, of which Intel SGX is the most widely deployed implementation, is increasingly used across the Layer 2 ecosystem as a faster, cheaper alternative or complement to pure zero-knowledge proving. TEE-based proving systems all share the same fundamental dependency: a signing key that must never leave secure hardware. CNB has covered the Kelp DAO bridge hack and the Drift Protocol admin key seizure, both of which involved credential compromise rather than smart contract bugs. Taiko’s incident extends that pattern into a new category: not a stolen key taken from a hardware wallet through social engineering, as happened to Radiant Capital, and not a compromised validator node, as happened to Kelp DAO, but a key that was simply left in the wrong place by the development team itself. The attack surface for any protocol relying on TEE attestation now explicitly includes every developer’s local environment, every CI pipeline, and every git history, not just the production signing infrastructure. A four-year-old Zcash vulnerability, surfaced by an AI model rather than exploited by an attacker, made a related point earlier this month: the tools available to both defenders and attackers for finding exactly this class of exposed-secret or logic flaw are improving in parallel, and protocols relying on any single cryptographic trust anchor need processes, not just code review, to keep that anchor secret.
Frequently Asked Questions
Are funds still on Taiko’s bridge safe right now?
Taiko paused both the main Bridge and ERC20Vault contracts and confirmed the remaining funds in the bridge are safe in its end-of-day update on June 22, 2026. The team has not yet issued an official all-clear for resuming normal bridge operations as of the time of this incident’s public reporting, and has explicitly advised users not to bridge assets until an official resumption announcement is made through Taiko’s verified channels.
Were any user wallets or self-custodied TAIKO tokens directly compromised?
No. The attack drained ETH and ERC-20 assets held inside Taiko’s bridge contracts and ERC20Vault, the custody contracts on Ethereum mainnet, not individual user wallets. TAIKO tokens held in self-custody or on a centralized exchange were not directly stolen by this exploit; the price decline reflected market reaction to the security incident, not a loss of user-held funds.
What is the difference between Taiko’s SGX-based proving and a pure zero-knowledge rollup?
A pure ZK rollup proves the validity of L2 state transitions using only cryptographic zero-knowledge proofs, with no reliance on trusted hardware. Taiko’s Raiko stack is a multi-prover hybrid, combining SGX hardware attestation alongside ZK backends such as SP1 and RISC0, intended to require an attacker to defeat multiple independent systems simultaneously. The architecture’s resilience depends entirely on those systems remaining genuinely independent in practice; a single shared point of failure, such as one whitelisted SGX prover controlled by one exposed key, can undermine that independence even when the design intent was sound.
Further Reading
The closest comparison point. Polymarket’s contracts were never touched either, the difference is the trust broke in a browser, not in a signing key the chain itself was built to believe.
2026’s largest bridge hack, also a forged cross-chain message exploit, but through a compromised LayerZero validator node rather than a leaked GitHub key.
The contrast case in key compromise: Radiant’s keys were stolen through social engineering targeting a developer. Taiko’s were exposed by the team’s own process.
A related lesson from the same month: the tools for finding exposed secrets and logic flaws are improving for defenders and attackers alike.
This article is for informational purposes only and does not constitute financial advice. Sources: TechTimes June 23 2026 (Kyle Belmonte), The Defiant, CryptoTimes (QuillAudits), DarkNavy on-chain forensic blog, Blockaid postmortem, PeckShieldAlert, L2Beat technical registry, OpenZeppelin audit history, Decrypt, MEXC News, Thirdweb technical post-mortem, Charles Guillemet (Ledger CTO) via LinkedIn, P3b7 on X, Incrypted, KuCoin, CoinEx. Published June 30, 2026.
