The Taiko bridge exploit is a trust-model failure, not a TEE failure

On June 22, an attacker drained roughly $1.7M from Taiko’s L1 bridge and ERC20 vault. There is no evidence of an Intel SGX break in this incident; the hardware appears to have behaved as specified. The failure was architectural. Taiko had made a single application signing key the root of trust for its SGX prover path, and that key was sitting in a public GitHub repository long enough for an attacker to find and use it.

The lesson most people will take from the headline is “TEEs got hacked.” They didn’t. A team made one key the deciding authority on which provers counted as real, then leaked it. The same mistake is just as possible on other TEEs. The hardware is not the variable that matters here. The real lesson is narrower and older than TEEs: where possible, avoid making a single private key or signature your only anchor of trust. The durable fix is to anchor trust in what the code provably is, not in who signed it.

A note on sourcing before we start: Taiko has not yet published a full post-mortem, and has said in a June 23rd update that full technical detail will follow in that report. The account below is assembled from the firms that analysed the incident in real time, and we have tried to separate confirmed facts from reasonable inference.

What actually happened

The forensics are consistent across the firms that looked at it. Blockaid detected the attack as it happened. BlockSec, through its Phalcon arm, traced the likely root cause to the exposed key and named the specific entry point (SgxVerifier.registerInstance). Independent estimates put the loss at approximately $1.7M. Ledger CTO Charles Guillemet gave the cleanest architectural read of why it worked.

The chain of events, reconstructed in technical breakdowns by The Defiant and thirdweb:

1. Taiko’s Raiko proving stack uses Intel SGX enclaves to generate attestations that Taiko’s L1 bridge contracts accept as proof that L2 state transitions are valid.
2. An RSA-3072 private key, committed as a file called enclave-key.pem, was left publicly readable in the taikoxyz/raiko repository on GitHub. It was downloadable by anyone with a GitHub account, and it sat there long enough for an attacker to find and use it.
3. With that key, the attacker registered their own SGX prover. Taiko’s contracts accepted it because their MRSIGNER check derived from the same public key.
4. The attacker’s prover signed forged attestations for fake L2 state. The forged proofs let processMessage() mark fraudulent withdrawals as RETRIABLE, and the follow-up retryMessage() calls released funds from the L1 Bridge and the ERC20Vault with minimal additional checks.

Taiko’s response was fast. They caught and froze the incident within hours, activated its Security Council multisig to pause the bridge, halted block production, and has said in a June 24th update that no user will lose funds and that they will fully recollateralise the bridge so every balance is backed 1:1 before reopening. The containment was fast and the damage was bounded. The architectural lesson stands regardless.

The mechanism here is simple: in SGX, MRSIGNER is a hash of the signing key’s public part, so trusting a given MRSIGNER identity means trusting whoever holds the corresponding private key. Once that key is public, anyone can stand up their own hardware and present it as a certified, trusted prover, and the verifier has no way to tell it apart from a legitimate one.

The pattern: app keys as roots of trust

Taiko’s version was extreme, but the underlying mistake is common. A team stands up a TEE-based component (a prover, oracle, sequencer, or bridge verifier), generates an enclave signing key, and writes logic that says “if it is signed by this key or matches this identity, trust it.” That user-controlled key becomes the de facto root of trust.

From that point on, every nice property of the TEE is downstream of one artifact the team created. Git history, CI logs, misconfigured storage, an insider: any of these collapses the entire trust structure. Guillemet made the same point about the Taiko incident, that the underlying problem is any architecture that rests on a single privileged key. Leave a way to shoot yourself in the foot, and given a long enough time horizon, someone eventually will.

The same mistake shows up in two subtler forms:

Equating “hardware attested” and “signed by a key” with “correct code is running”. Attestation tells you “this is an enclave on vendor X” and “it was signed by this key”. It does not, on its own, tell you the binary inside is the code you reviewed. If the attested measurement is not tied back to a verifiable build from an inspectable source, you have left room for swapped binaries and loader games that still produce clean attestation. For the most technical audience: this is exactly akin to writing an attestation condition that only checks PCR8 (the developer’s signing certificate) while completely ignoring PCR0, PCR1, and PCR2 (the actual code, kernel, and application hashes).

Centralising trust in one path. If one prover, one enclave flavour, or one vendor can unilaterally authorise a withdrawal, then compromising that one path is enough. This is the part of the Taiko story that usually gets glossed over.

The fix: anchor trust in the build

The way we go about using TEEs at Caution is different. When TEEs are used to secure bridges, custody, and other high-value infrastructure, the root of trust cannot be “a particular signing key controlled by a team”. We anchor it in hardware-backed attestation plus a fully verifiable build.

In this model, enclave identity comes from the build itself. The code is built from source using a reproducible, full-source toolchain (StageX and EnclaveOS) that produces deterministic software. When an enclave produces an attestation, verifiers check that its measurement matches an allowed build manifest, recomputed from source, rather than asking whether it was signed by a particular key. Tamper with the build, and the measurement changes and verification fails. Anyone, not just the operator, can rebuild the image from a published source and confirm the measurement they see in production matches what they computed locally.

Under this model, the same incident plays out very differently: There is no application signing key to leak. The entity interacting with the node does not decide which code to trust by checking who signed it. It checks the measurement: a hash of the deterministic build. An attacker can stand up their own enclave, but it produces a different measurement, so it matches no approved build and the attestation is rejected.

The astute reader will notice that we are still trusting the AWS CA in this case, something we are actively working towards mitigating via multi-hardware attestation. To be precise about scope: Caution runs on AWS Nitro Enclaves today, with multi-hardware support for Intel TDX, AMD SEV-SNP, and TPM 2.0 in active development.

What a verifiable-deployment design changes

Picture the same prover stack built around verifiable deployments instead of a blessed signing key:

• Registering a prover requires a published build manifest tying a measurement to a specific source commit and configuration. The verifier only accepts attestations whose measurements match those manifests.
• A leaked signing key would no longer be enough on its own. The attacker’s forged enclave would not match any trusted measurement, so its attestations would be rejected.
• Malicious changes become visible. Any change to the prover code or build that affects behaviour changes the measurement, and independent verifiers can detect that production no longer matches what they expect, even without controlling the infrastructure.

The failure mode shifts from “a key leaked in a Git repo, game over” to “someone has to ship a malicious build and get it explicitly trusted”, a much higher bar that is harder to clear without being noticed.

Practical guidance, even if you never touch Caution

There are concrete lessons here for anyone running TEEs in production, especially in bridges, rollups, oracles, and custody:

Do not make a team-generated key your ultimate arbiter of trust. An enclave signing key used for signing MRSIGNER or PCR8 can leak. Where possible, design your system to rely on code integrity rather than a user-controlled signing key.

Keep your TCB small and your interfaces tight. Minimise what runs inside the enclave. Larger trusted computing bases and complex trust boundaries are harder to reason about and audit, a point that recurs across the TEE security literature, including a survey of TEE (in)security and a study of TEE pitfalls specific to blockchain applications.

Make redundancy conjunctive. Multiple provers or vendors only help if no single one can unilaterally authorise.

Make verification possible for others, not just for you. Publish enough (build manifests, measurement lists, source) that users, partners, and auditors can verify your claims instead of taking your word for it.

Where Caution fits

We built Caution because we kept seeing TEEs marketed as confidential compute but deployed as opaque black boxes, where everyone trusts the operator, an opaque binary, or a handful of poorly managed keys. Our answer is to make verifiable compute the default: a reproducible full-source stack down to the kernel (and in fact the compiler), attestations checked against builds anyone can reproduce, so that trust rests on the build itself rather than on the operator or a signing key.

That does not prevent every bug or attack, but it does essentially remove an entire class of supply chain attacks that target modifying the code before or after it has made it into its final destination where it is meant to be running. If you are running TEEs today in a context where a single mistake is not tolerable, the question to ask is whether your root of trust is a reproducible build that others can check, or one more key you are hoping stays secret.

References

Incident reporting and analysis:

• Blockaid, real-time detection of the attack: post on X
• BlockSec Phalcon, root-cause analysis (quoted, including SgxVerifier.registerInstance): Decrypt
• PeckShield, loss estimate: post on X
• Charles Guillemet (Ledger CTO), single-key critique and validity-proofs alternative: Incrypted
• Technical breakdown of the enclave-key.pem leak and the forged-proof path: The Defiant, thirdweb
• MRSIGNER as a hash of the signing key’s public half: TechTimes

Background on TEE security:

• M. Muñoz et al., a survey on the (in)security of trusted execution environments: Computers & Security, 2023
• Lessons learned from blockchain applications of TEEs: arXiv:2203.12724

Caution and the verifiable-deployment stack:

• How Caution verifies attestations against reproducible builds: Attestations, Verifiability
• StageX (full-source bootstrapped, reproducible toolchain) and EnclaveOS