Taiko Bridge $1.7M Leaked SGX Enclave Key Exploit (Explained)

On June 21, 2026, Taiko lost approximately $1.7M when an attacker forged SGX prover attestations using a private key that had been committed to a public GitHub repository. There was no theft of a hot wallet key, no social engineering, and no flash loan involved. An RSA-3072 signing key sitting in plain sight at docker/enclave-key.pem inside the taikoxyz/raiko repo was enough to register a malicious prover that Taiko's L1 contracts trusted completely.

Protocol Background

Taiko is a based rollup that uses Intel SGX, via its Raiko prover, to attest the correctness of L2 state transitions to L1. An SGX enclave generates a signed attestation that a state transition was computed correctly inside a genuine, unmodified enclave. L1 contracts verify this by checking that the enclave's identity, its MrSigner, matches a value stored on-chain called  trustedUserMrSigner. MrSigner is derived as SHA-256 of the little-endian RSA modulus of the key used to sign the enclave, so whoever holds that RSA private key effectively controls which enclaves the protocol will ever trust.

The Bridge contract (0xd60247c6848B7Ca29eDdF63AA924E53dB6Ddd8EC) and ERC20Vault (0x996282cA11E5DEb6B5D122CC3B9A1FcAAD4415Ab) on Ethereum rely on these SGX attestations to process cross-chain messages, including processMessage() for initial relay and retryMessage() for retrying messages that did not complete on the first attempt.

Hack Analysis

The RSA-3072 private key used to sign every Taiko SGX enclave had been committed to the public taikoxyz/raiko GitHub repository, sitting on a hotfix branch where it was readable by anyone.

The attacker pulled enclave-key.pem from the repo and derived its MrSigner value, then confirmed it matched the trustedUserMrSigner value Taiko's L1 contracts already had stored on-chain.

With that confirmed, the attacker built a malicious enclave and signed it using the leaked key. The signature traced back to a key the protocol implicitly trusted, so the malicious enclave registered successfully as a legitimate SGX prover, with no compromise of Intel's actual SGX hardware required anywhere in the process.

Once registered as a trusted prover, the malicious enclave attested to fake L2 state, including bridge messages that had never occurred on Taiko's actual L2.

That forged attestation reached processMessage() on the L1 Bridge, where the proof check passed since the signature was valid for a registered MrSigner, and the message status was set to RETRIABLE.

retryMessage() then executed against that status with zero independent proof verification of its own. It simply checked that a message carried RETRIABLE status and ran it.

Repeating this path to drain the Bridge and ERC20Vault, sending stolen funds to attacker wallets 0x7506DeA0c38ca0B55364B22424374c5A1ae1B76a and 0xa98035081fb739ebe9c8f80904668fb11438a846.

Root Cause

The root cause was not a flaw in Intel SGX itself or in the cryptography behind attestations. It was operational. A private key that functioned as the protocol's entire trust root for L2 state was stored inside a Git repository that was at some point made public. Once that key leaked, the SGX trust model collapsed entirely, because nothing distinguishes a legitimate Raiko-built enclave from an attacker-built enclave signed with the same key.

Two compounding contract-level design choices turned the key leak into immediate, repeatable theft. First, processMessage() accepted any SGX attestation matching the registered MrSigner with no secondary signal, such as volume limits or a second attestation source, to catch a state transition with no corresponding event on Taiko's actual L2. Second, retryMessage() trusted the RETRIABLE status set by a single prior forged attestation rather than re-verifying proof independently, turning one successful forgery into a repeatable drain primitive instead of a contained, one-time event.

The link between the leaked key and the exploit is independently verifiable. MrSigner is just SHA-256 of the little-endian RSA modulus of the signing key, so pulling the committed enclave-key.pem and running the derivation locally reproduces the exact value Taiko's L1 contracts had stored as trustedUserMrSigner.

1-----BEGIN RSA PRIVATE KEY-----
2MIIG4wIBAAKCAYEAy2c2h0zCLmynJY+E5wpHPjz9VoaCskcxNfQVM5E1cbf3/b4j
37nPcSs/3oxvBFHTZGxnLIJY/A29Y/GKDjBIQdhT5f4p/Y2l7wAZZUEeyJs1dyybU
4F1dFKKZEOAmuXGE0p4g9pbE2RuYFfAug+SR3FDUedktg79Pa7Wn+IRG79xKrD4i0
5XR8wbxRZaubFtMJH/djC4EUBDQ1wkes0T1rvRvubqP3EdGsRBHg44B6D01pcfTUV
65/Z9f+IjQLYGNSMJiwHrFmVD42gHvMKApe5tv4No19QNz78OiTh4lUlJBYcZlUzY
7UJNaH+tAaJ3zUrgHeACFqFJ72RURhD5Fr7MlAufefDK/ZvFm/ozIP9A6fSw3KMlk
8BYXeul7M4CA6RGLCyTxLAs94romrSvPzWr5qZryFVGr1xA39qcKHgDDkzpxCxQXs
9UjJ453RAZSni/CVd4ZiyKJMBwuHcKo6hs48ymK4EBXlKjg/DqmEZcF0YLHzUfXf7
10O38CL8vyQslrEw4JAgEDAoIBgCHmiRaMywe8xoZCliaBtopff45rwHML3Yj+A4iY
11M5Lz/qpKW1JopLciqUXZ9YNoztnZodrDtSs9OX9lwJdYWBOuKZVBv+Xm6fVWZDgL
128wZ3j6HbzgPj4NwbtglW8mS63hvsCkZIM7Z7q5SsmtQwvoNeL75h5X1N+dI8VQWC
139Kktxy1Bc2TaiBKDZDx7y54gYVT5ddALgCzXksL8iLfkfTZ/RJwqS2i8gtYUCXqv
14wKM5uhTeLlFTv5VQWzVzq7OF1p/4uWlrDXiCFSj+I7yCYtKyB5I7vB/Z6KKSsEmJ
15tFcYw6Syibw43tnTrAs9AeE+j5qwauLCUryKXxe+HtY9bDscCXxX5guaVw0AIOPR
16xJ299UVqwEAU2F6igYBT4eWCyAR3FzYiwMdKq50a6HHuwkC1LYIXFZcVite7XsPa
17Zx0Qgg1iKDDjCMgF3Q5wfOs0Wbyt1piofyZPLvYOmF6mrFoobKCCLOnM5xtZMw5E
18ik7VIm0obylJnRnHsKwgq1blIwKBwQD+4qA0hr0OGQuv0OAKZiZwNQFbKQwAKOwz
194eXN58VRBe3IKyq2kfmzuDVvosCz2CPtUtIMK8o7A9zN+YuDAYECqMpVdP4QJT3F
204rRRw9lLanoFLOngkDHGMfS5VbOiWFlGfYuInppxQrs+Mdwz9jTERpsUr4iKh8mr
21TJ6x8UMhasUaMk1xZjURzCvoI4Rmhmy0hJPqZzTL9UTrKGEhoAAMpJvPZvvMEKAU
22IhwdL5JA4I+Oj+F5qUgP35HETdHQuxUCgcEAzEryaVw2AkJ9FvzKMHn2XyI6D0SZ
23EHquheZxDidJqeyV8PJzMKwnUT0CtY0nV2iF6osyS5jBMtL6J9ABJ0EanZbbPK5d
24ES4e6qlOlyHFf039gxv4pHiavF3PJNM7QPm5Z/Q0NWBZkYbqXiCkey+oHjbZMzDr
25rwTy8BGwNyE2/s5xWoatu3oPJYTmJmNxEmTWwQEWqjjSERF9ew6uWgcobxbccwVB
26RzG48ifK/ZJIEp12X/V+yhwLhT48dbeVOPQlAoHBAKnsas2vKLQQsnU16rGZbvV4
27q5IbXVVwnXfr7olFLjYD89rHcc8L+80lePUXKyKQF/OMjAgdMXytPd6mXQIBAKxw
28huOjVArDfoPseDaCkNzxpq4d8UBgIS7L+HuOd8GQO4RTslsUZvYsfNQhPXf5eILZ
29vLh1BbGv28eIacv2LMDx2LwhiPZEI2Eyx/AXrZmu8yMDDUbveIf42JzFlhZqqrMY
30Z9+Z/TK1wA1sEr4fttXrCl8KllEbhV/qYS2JNosnYwKBwQCIMfbw6CQBgai5/dwg
31UU7qFtFfgxC1px8D7vYJb4ZxSGP19vd1yBo2KKx5CMTk8FlHB3bdEIDMjKbFNVYa
32K2cTued9yZNgyWnxxjRkwS5U3qkCEqXC+xHS6TTDN3zV+9Dv+CLOQDu2WfGUFcL8
33ynAUJJDMy0fKA0ygC8rPa3n/NEuRrx58/AoZA0QZl6C27eSAq2Rxeza2C6j8tHQ8
34BMWfZJL3WNYvdntMGodTttq3E6Q/+P8xaAeuKX2jz7jQosMCgcEAjGP7ZkAF1njP
35AymHlEOC0YQrn9QOSfd9jU00WP9wUSF4YAVS0IKrBhZrXLSDAd/6GU6QdS4SBSB1
364OQwL19RhoN+RAiO37JSFi8WoBAGe1g6VYy6wktnysaBGgqoqCMKVfw+fCRXEV+b
37sQEOIJRGZvbrBU38Jm41386ZDnqOXGGlWjI12BvFarUIN6IPNytxuj4J0+BTwre/
38/YxlapRxEkmHTHZWMXF03Nhv5tPa63BVM6PNdP4xO3kJWwg1tPqF
39-----END RSA PRIVATE KEY-----
40

1from Crypto.PublicKey import RSA
2import hashlib
3
4key = RSA.import_key(open("enclave-key.pem").read())
5modulus_le = key.n.to_bytes(key.size_in_bytes(), "big")[::-1]
6mrsigner = hashlib.sha256(modulus_le).hexdigest()
7
8print(f"MrSigner: {mrsigner}")
9

How QuillAudits Infrastructure Review Could Have Prevented This

This attack class, a leaked signing key undermining an entire trust model, is preventable through controls that exist today.

Secret scanning in CI/CD. Automated pre-commit and pre-merge scanning flags private keys, certificates, and .pem files before they ever reach a remote branch, including hotfix and feature branches that often bypass normal review.

Single-key trust roots for TEE attestation. A single RSA key controlling MrSigner for every enclave a protocol will ever accept is a single point of total failure. A QuillAudits infrastructure review would recommend multi-party enclave signing or a key rotation and revocation path that does not require a full contract upgrade to respond to a leak.

Defense in depth on retry paths. retryMessage() executing on RETRIABLE status alone, without re-checking the underlying proof, converts any successful forgery into a repeatable drain primitive. Retry logic handling cross-chain value transfer should re-verify proofs independently rather than trusting a status flag set earlier in the same trust chain.

Repository hygiene on hotfix branches. The leaked key sat in a hotfix branch, exactly the kind of fast-moving, lower-scrutiny branch where build artifacts and secrets are most likely to slip past review. QuillAudits recommends the same secret-handling standards apply regardless of branch type.

Funds Flow After Attack

Stolen funds moved to two attacker-controlled wallets,  0x7506DeA0c38ca0B55364B22424374c5A1ae1B76a and 0xa98035081fb739ebe9c8f80904668fb11438a846 and to Tornado Cash. Taiko paused the bridge shortly after confirming the exploit. The team has stated no user has lost funds, with the protocol replenishing the bridge from its own resources so that every L2 asset remains backed 1:1 by its Ethereum counterpart.

Post-Attack Mitigation

Shortly after the attack, Taiko confirmed the exploit, explaining that forged message proofs had been accepted on L1 with no corresponding event on the source chain, letting the attacker register fraudulent withdrawals against the bridge and token vault, with losses estimated near $1.7M before the bridge was paused.

Taiko then announced it was ready to bring the chain back, stating the June 21 attack path had been closed and the fixes independently reviewed, and laid out a four-step staged plan covering fix deployment and finalized-state verification, replenishing the bridge 1:1, restoring the network, and finally reopening the bridge with conservative withdrawal quotas, while reiterating that no user would lose funds.

Taiko confirmed the first step of that plan was complete, with the Security Council having executed the fix proposal and the chain's finalized state checking out clean, no forged checkpoints and no attacker claims left reachable.

Taiko confirmed the network was back online, with the bridge fully replenished so every asset is matched 1:1 by its Ethereum counterpart and transfers, swaps, and trading restored as normal, leaving only the final step, reopening the bridge to Ethereum, still pending.

Relevant Addresses and Transactions

SGX Prover Register Transaction

0x2f44dc1b883522a88f9b0cbbdfabf9ec33884b69dd4326600c3fab7fb2277260

Bridge Contract

0xd60247c6848B7Ca29eDdF63AA924E53dB6Ddd8EC

ERC20Vault

0x996282cA11E5DEb6B5D122CC3B9A1FcAAD4415Ab

Leaked Signing Key

docker/enclave-key.pem on taikoxyz/raiko

Attacker Wallets

• 0x7506DeA0c38ca0B55364B22424374c5A1ae1B76a
• 0xa98035081fb739ebe9c8f80904668fb11438a846

Major Drain Transactions

• 0x451423923ab3df56ce436a921d34d782681cf698b72ca61ad6b8a8b2aeee53b7
• 0x017292a7de5fef52a3274e37dda5ace4c4d0cdafe91b7b4ac9c700f02fae35ee

Conclusion

Taiko's SGX trust model depended entirely on one RSA key staying private. It did not. A .pem file sitting in a public hotfix branch let an attacker forge prover registration, fake L2 state, and walk a forged message through retryMessage()'s missing proof check. No hardware was broken, no cryptography was defeated. A leaked secret and a retry path that trusted status over proof did the rest. The fix was secret hygiene, not new cryptography.