Worked example · 2026-06

Taiko bridge — a leaked SGX prover signing key forges L2-state proofs to drain the L1 bridge — Ethereum L1 ⇄ Taiko Alethia L2 — 2026-06-21

Loss: ~$1.7M realised (USDC, ETH, and TAIKO) drained from Taiko's L1 Bridge and ERC20Vault contracts across two phases. The attacker broke no cryptography and compromised no live operator machine: they used an Intel SGX prover signing key that had been committed to a public GitHub repository (taikoxyz/raiko) to sign their own enclave, register it as a legitimate prover, and produce forged L2-state attestations backing bridge withdrawals that no real L2 state transition supported. The realised figure is bounded by the assets sitting in the bridge/vault at the time and by how fast Taiko paused; the notional ceiling is the full bridge + vault reserve, because a forged-proof withdrawal primitive is limited only by what the contracts will release. OAK records both: realised ~$1.7M, notional bounded only by the broken trust predicate.
OAK Techniques observed: OAK-T10.002 (Message-Verification Bypass — the L1 contracts accepted an L2-state message whose proof was forged but validly signed. This is a new TEE-attestation-signing-key-exposure sub-shape: unlike Nomad (trusted-root initialised to 0x00), Wormhole (missing guardian-account validation), Verus (missing source-amount validation), MAP Protocol (abi.encodePacked collision), or Syscoin (proof-*parser* misreads malformed bytes), Taiko's verification predicate was evaluated correctly — the L1 verifier checked that the proof came from an SGX enclave whose measurement/signer matched the trusted instance key, and it did. The defect is that the trusted key itself was public, so the attacker produced genuinely well-signed proofs for state that never happened. The closest prior anchor is Stake DAO's trust-root-reconfiguration sub-class — there the trusted peer was maliciously repointed; here the trusted signer was leaked. See techniques/T10.002-message-verification-bypass.md). OAK-T15.004 (Operator-Credential Compromise — the root-cause entry vector: a privileged signing credential, the RSA-3072 SGX enclave/instance signing key, was exposed in a public source repository and used by an unauthorised party. It was not phished or exfiltrated from a live host — it was published — but the effect is identical: an outsider holds a key the trust model assumes only the operator holds. See techniques/T15.004-operator-credential-compromise.md). The chain is T15.004 (leaked prover key) → T10.002 (forged-but-valid proof accepted → unbacked withdrawal): credential exposure off-chain, forged-proof drain on-chain. This is OAK's first worked example where a leaked TEE attestation key, not a logic flaw, is the load-bearing cause of a bridge message-verification bypass.
Attribution: pseudonymous. The on-chain attacker addresses and the two-phase drain were traced and disclosed by SlowMist and corroborated by Taiko's own incident statement; no named actor or group. The root cause — an RSA-3072 SGX instance signing key committed to the public taikoxyz/raiko repository — is confirmed by multiple independent write-ups (thirdweb, Crypto Times, TechTimes) and is consistent with Taiko's response (pausing proving and the bridge, rotating trust). The exploit ran across 2026-06-21 → 2026-06-22.
Key teaching point: A TEE/SGX attestation is only as trustworthy as the secrecy of the enclave signing key — and a signing key in source control is not a secret. Taiko's L1 verification logic was not buggy: it correctly checked that a proof came from an SGX prover whose signing identity matched a trusted value. The trust model collapsed because that trusted value's private half was public, reducing "a proof from our trusted enclave" to "a proof from anyone who cloned the repo." Three defensive lessons compose: (1) treat enclave/prover/attestation signing keys as the highest tier of secret — generated and held in an HSM or sealed enclave, never written to a repo, with mandatory pre-commit and historical secret-scanning on every repository (the key was discoverable to anyone, so detection had to be pre-publication); (2) a multi-proof system must not let any single proving backend unilaterally authorise a withdrawal — if SGX-attested state and a ZK validity proof are both required (M-of-N proving), a single leaked SGX key cannot by itself release funds; (3) bridge/L1 withdrawals need an independent runtime circuit-breaker — a per-window value/rate cap and a challenge delay on large withdrawals would have bounded the loss and bought time for the human response that ultimately paused the system. Taiko is OAK's canonical anchor for the lesson that TEE-based rollup security inherits, undiminished, the operational secrecy requirements of the keys that anchor the attestation.

Summary

Taiko Alethia is an Ethereum Layer-2 (a based rollup) whose proving system includes Intel SGX attestations produced by its raiko prover. Taiko's L1 contracts release bridged assets when presented with a proof of the corresponding L2 state; for the SGX path, the L1 verifier accepts a proof if it was produced by an enclave whose signing identity matches a trusted instance key registered on-chain.

The RSA-3072 private key used to sign that SGX enclave was committed to the public taikoxyz/raiko GitHub repository. An attacker retrieved it, signed their own enclave so its attestation matched the trusted signer, and registered the malicious instance as a legitimate SGX prover. With a "trusted" prover under their control, they generated forged L2-state attestations — proofs of bridge-withdrawal state transitions that never occurred — and submitted them to the L1 Bridge and ERC20Vault. Because each forged proof was correctly signed by a trusted key, the verification predicate passed and the contracts released funds. The drain ran in two phases on 2026-06-21 → 06-22, removing ~$1.7M in USDC, ETH, and TAIKO.

Taiko confirmed the verification compromise, paused the bridge and block production/proving, urged users to withdraw funds from the affected bridges, and coordinated with exchanges to freeze attacker-controlled assets. Several outlets placed the incident in the 2026 cross-chain proof-forgery class blamed for well over $300M across a dozen-plus bridge exploits this year.

Timeline (UTC)

When	Event	OAK ref
Pre-2026-06-21	RSA-3072 SGX instance signing key is committed to the public `taikoxyz/raiko` repo; Taiko's L1 SGX verifier trusts any enclave whose signer matches the registered instance	T15.004 standing exposure
2026-06-21	Attacker signs a malicious enclave with the leaked key and registers it as a legitimate SGX prover	T15.004 → T10.002 setup
2026-06-21 → 06-22	Attacker submits forged, correctly-signed L2-state proofs to the L1 `Bridge` / `ERC20Vault`; verification passes; ~$1.7M (USDC/ETH/TAIKO) drained across two phases	T10.002 execution
2026-06-22	Taiko confirms the compromise, pauses the bridge and proving/block production, urges bridge withdrawals, coordinates exchange freezes	(operator response)
2026-06-22 → 06-23	SlowMist and third-party write-ups (thirdweb, Crypto Times, TechTimes) publish the leaked-`raiko`-key root cause	(third-party forensics)

What defenders observed

Pre-event (secret-in-source-control). The load-bearing exposure was a privileged signing key in a public repository — discoverable to anyone, with no intrusion required. There is no on-chain signal for this; the control is historical and pre-commit secret-scanning across all org repositories, with attestation/enclave keys explicitly enumerated as scan targets and held only in HSM/sealed storage (OAK-T15.004 mitigation surface).
At-event (newly-registered prover instance). The on-chain fingerprint is a new SGX prover/instance registration followed immediately by withdrawal proofs from that instance with no corresponding canonical L2 state. A monitor on prover-registration events plus a reconciliation invariant ("every L1 withdrawal maps to a finalised L2 state root") is the highest-leverage runtime control and would have fired on the first forged withdrawal.
At-event (single-backend authority). A single proving backend (SGX) was sufficient to authorise withdrawals; an M-of-N multi-proof requirement (SGX and ZK) would have made the leaked key insufficient on its own. The absence of corroboration is the structural amplifier.
At-event (no withdrawal rate-limit). The two-phase drain proceeded without a per-window value cap or challenge delay; either would have bounded realised loss and widened the human-response window before Taiko paused.
Post-event (containment). Taiko's pause-of-proving-and-bridge plus exchange-coordinated freezes is the correct response template; the residual lesson is that the trust-anchor key must be rotated and the entire trusted-instance set re-attested before unpausing.

Public references

[thirdwebtaiko2026] — thirdweb, "Taiko Bridge Exploit Explained: Forged Proofs, Leaked Key, $1.7M Loss" (RSA-3072 SGX signing key committed to public taikoxyz/raiko; attacker registered a malicious prover and forged L2-state attestations; two-phase drain of L1 Bridge + ERC20Vault; ~$1.7M USDC/ETH/TAIKO): https://blog.thirdweb.com/taiko-bridge-exploit-explained-how-a-leaked-key-led-to-1-7m-in-forged-withdrawals/
[cryptotimestaiko2026] — Crypto Times, 2026-06-22, "$1.7M Gone: Taiko Bridge Exploited After SGX Signing Key Leak" (date; SGX signing-key leak; chain-state verification compromise): https://www.cryptotimes.io/2026/06/22/1-7m-gone-taiko-bridge-exploited-after-sgx-signing-key-leak/
[techtimestaiko2026] — TechTimes, 2026-06-23, "Ethereum L2 Bridge Exploit Drains $1.7M: Leaked SGX Key Defeats Taiko Trust Model" (trust-model framing; L1 contracts trusted any enclave matching the stored signer; bridge withdrawal urged): https://www.techtimes.com/articles/318886/20260623/ethereum-l2-bridge-exploit-drains-17m-leaked-sgx-key-defeats-taiko-trust-model.htm
[cryptoeconomytaiko2026] — Crypto Economy, "Taiko Sounds the Alarm After Bridge Exploit Drains $1.7M in Unauthorized Withdrawals" (operator response: pause, withdrawal warning, exchange coordination): https://crypto-economy.com/taiko-sounds-the-alarm-after-bridge-exploit/
[spotedtaiko2026] — SpotedCrypto, "Taiko Bridge Exploit June 2026: $1.7M SGX Key Leak Explained" (MrSigner/instance-trust mechanism; malicious prover registration; forged attestations): https://www.spotedcrypto.com/taiko-bridge-exploit-june-2026/

Discussion

Taiko is the cleanest 2026 addition to OAK's T10.002 family because it isolates a sub-shape none of the prior anchors carry: the verification predicate was correct and was satisfied honestly — the attacker's proofs really were signed by a trusted instance key. Every other T10.002 anchor fails because the predicate is wrong or under-specified (Nomad's zero root, Wormhole's missing account check, Verus's missing amount check, MAP's non-injective hash, Syscoin's parser misread). Taiko fails because the secret that anchors a correct predicate was published. That makes it the canonical reference for the lesson that TEE/attestation-based verification does not remove key-management risk — it concentrates it into the enclave signing key, and a leaked enclave key is indistinguishable on-chain from a legitimate prover until reconciliation against canonical state catches the unbacked withdrawal.

It also sits at the T15.004 ↔ T10.002 boundary in a way worth recording for contributors: the entry vector is mundane (a secret in a public repo — the same class of failure as any leaked API key) but the blast radius is a bridge-draining forged-proof primitive, because the leaked credential was the trust anchor of the proving system rather than an ordinary operational key. Future contributors documenting TEE/ZK rollup incidents should record, per incident, (a) where the attestation/prover signing keys live and whether any could reach a public surface, and (b) whether a single proving backend can unilaterally authorise withdrawals — those two variables are what converted a leaked key into a $1.7M drain, and an M-of-N multi-proof design plus an independent withdrawal circuit-breaker are the structural fixes. A forward-candidate T10.002 sub-technique (TEE-attestation-key exposure) is flagged for TAXONOMY-GAPS pending a second independent anchor.