~$4.1M Lost: Taiko, SecondFi Exploits

During the past week (2026/06/22 - 2026/06/28), 2 notable security incidents were identified, resulting in approximately $4.1M in confirmed losses.

Date	Incident	Type	Estimated Loss
2026/06/22	Taiko	Key Compromise & Improper Validation	~$1.7M
2026/06/23	SecondFi	Cryptographic Implementation Flaw	~$2.4M

Taiko: The attacker combined an exposed SGX enclave signing key with an incomplete attestation policy to register a malicious prover as an authorized instance, demonstrating that valid attestation alone is insufficient without comprehensive attribute enforcement.
SecondFi: A cryptographic implementation flaw enabled attackers to recover address-level signing keys using only public transaction data, demonstrating how a seemingly minor deviation from the Ed25519 specification can lead to complete key compromise.

Weekly Highlight: Taiko Incident

The Taiko incident is highlighted because the attack combined two independent security failures (an exposed enclave signing key and an incomplete attestation policy) to compromise an SGX-based proof verification system. The incident demonstrates that each layer of a TEE trust chain must independently enforce its security properties; a valid attestation signature chain does not compensate for unchecked runtime attributes.

On June 22, 2026, Taiko's SGX-based proof verification flow was exploited on Ethereum, resulting in approximately $1.7M in losses [1]. The attacker used an exposed enclave signing private key, which had been committed to a public GitHub repository, to sign the SIGSTRUCT for a prover enclave launched in DEBUG mode. Because the on-chain attestation contract did not reject DEBUG enclaves, the attacker registered as an authorized instance, submitted forged proof data, and caused the L1 contracts to accept a non-existent L2 state and release bridge funds.

Background

Taiko is an Ethereum Layer-2 rollup with a bridge that relies on a proof system to decide whether a given L2 state or cross-chain message should be accepted. As part of this proof system, Taiko uses SGX provers: off-chain programs running inside SGX enclaves on physical machines that sign proof results with keys protected by the enclave.

Off-chain (physical machine)                On-chain (Ethereum)
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX Prover Enclave     │                │  SgxVerifier                       │
│  - generates proofs     │── DCAP quote ─→│  ├─ registerInstance()             │
│  - holds instance key   │                │  │  └─ AutomataDcapV3Attestation   │
│                         │── signed proof→│  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

SGX & DCAP Overview

The core SGX concept is the enclave: a program environment isolated by the CPU. MRENCLAVE is the measurement of the enclave's initial code, data, page layout, and related metadata; it can be approximated as the hash of the enclave build. MRSIGNER is the hash of the enclave signing public key and represents the publisher identity.

The enclave signing private key signs the SGX SIGSTRUCT, which contains enclave metadata such as MRENCLAVE, ISVPRODID, ISVSVN, and ATTRIBUTES. This signature is not verified by the on-chain contract; it is verified by SGX hardware during the EINIT phase when the enclave is initialized. The CPU checks that the SIGSTRUCT signature is valid and that the MRENCLAVE inside it matches the measurement of the enclave actually loaded. Only after this verification succeeds can the enclave be initialized and produce subsequent reports and quotes.

An Intel SGX DCAP v3 quote is a remote attestation package containing three parts:

header: metadata such as the quote version, attestation key type, QE/PCE SVN, and vendor.
localEnclaveReport: the attested application enclave's identity, including MRENCLAVE, MRSIGNER, ATTRIBUTES, ISVPRODID, ISVSVN, and reportData. reportData is a 64-byte value written by the enclave when generating the report. Taiko stores the prover instance address in the first 20 bytes of reportData.
v3AuthData: authenticity proof for the quote, including the quote signature, attestation key, QE report, QE report signature, and PCK certificate chain.

On-Chain Attestation

The on-chain attestation contract (AutomataDcapV3Attestation, responsible for remote attestation) validates the quote authenticity through the Intel DCAP certificate chain. Although the issuer public keys in the certificate chain are supplied as part of the externally submitted quote, the contract verifies the chain step by step and requires the final issuer public key hash to match the Intel SGX Root CA public key hash fixed in the contract [2]. Through this chain, the contract confirms that the localEnclaveReport covered by the quote signature was not arbitrarily modified in calldata.

Taiko Prover Registration

An SGX prover instance must first be registered through SgxVerifier.registerInstance(). During registration, the caller submits a DCAP quote. SgxVerifier delegates quote validation to AutomataDcapV3Attestation.verifyParsedQuote(). If the quote passes, SgxVerifier reads the first 20 bytes of localEnclaveReport.reportData as the instance address and adds it to the authorized instance set.

The signature verification flow can be simplified into three layers:

The SGX CPU verifies the SIGSTRUCT signature during EINIT, confirming the enclave's MRENCLAVE and signer identity.
The DCAP certificate chain and QE report authenticate the quote signing key. AutomataDcapV3Attestation then uses that key to verify the quote signature and establish trust in localEnclaveReport.
Taiko's proof verifier uses the registered instance address to verify later proof signatures and decide whether to accept the corresponding L2 state or cross-chain message.

Vulnerability Analysis

The root cause of this incident is a combination of an operational failure and a contract-level vulnerability. Both were necessary for the attack to succeed.

Operational failure: exposed enclave signing key. The enclave signing private key used by Taiko/Raiko to sign SGX SIGSTRUCT was committed to a public GitHub repository. MRSIGNER is the hash of the corresponding signing public key. Anyone who obtains this private key can sign a prover enclave's SIGSTRUCT, causing the MRSIGNER in the resulting quote to match Taiko's allowlist.

Contract vulnerability: missing ATTRIBUTES check. With a matching MRSIGNER (passing the allowlist via the exposed key), the attacker could launch the same approved enclave in DEBUG mode without changing MRENCLAVE (the DEBUG flag is not part of MRENCLAVE). The attestation policy should have caught this, but AutomataDcapV3Attestation (0x5e46...dd72) did not check the application enclave's localEnclaveReport.attributes. A DEBUG enclave allows the host or debugger to read or modify enclave memory, meaning the instance signing key that should have been protected by the SGX enclave is no longer secure.

Together, these two conditions mean that any party can launch the same prover enclave code in DEBUG mode (producing the same MRENCLAVE as the legitimate build) and, using the exposed signing key, sign a SIGSTRUCT that makes MRSIGNER match Taiko's allowlist. The resulting quote satisfies both the MRENCLAVE and MRSIGNER allowlists while carrying the unchecked DEBUG attribute. Because AutomataDcapV3Attestation does not reject the DEBUG attribute, such a quote passes verifyParsedQuote(), after which SgxVerifier registers the instance address in the authorized instance set.

A DEBUG-mode enclave does not protect its memory from the host or debugger. The instance private key generated inside the enclave can therefore be extracted. With that key, the holder can sign arbitrary proof data that the L1 contracts would accept, enabling forged L2 state transitions and unauthorized release of bridge funds from the vault (0x9962...15ab).

Attack Analysis

The attacker submitted multiple transactions. The following analysis is based on two representative transactions: the first registered the attacker as an authorized instance (0x2f44dc...277260), and the second executed the forged proof to steal assets (0x017292...ae35ee).

Step 1: Use the exposed enclave signing key to sign SIGSTRUCT, making the quote's MRSIGNER match the allowlist.
Step 2: Run the enclave with the DEBUG attribute. DEBUG does not change MRENCLAVE, but it is reflected in localEnclaveReport.attributes.
Step 3: Call registerInstance() and submit a real SGX quote. The quote had attributes = 0x07..., which includes the DEBUG bit (0x02), but AutomataDcapV3Attestation did not check this field, so verifyParsedQuote() returned true.

Step 4: Extract the instance private key from SGX enclave memory (possible because DEBUG mode disables memory protection) and use it to sign malicious proof data.
Step 5: Submit the crafted proof to make the L1 contracts accept a non-existent L2 state and steal assets from the vault.

Conclusion

A complete SGX attestation policy should at least:

Reject SGX_FLAGS_DEBUG in production deployments.
Check MRENCLAVE, MRSIGNER, ISVPRODID, and ISVSVN.

If DEBUG quotes are accepted, the hardware may still be functioning correctly, but it no longer provides the expected memory protection semantics. Enclave signing keys must also never be committed to public repositories. An exposed signing key allows any party to produce binaries with a matching MRSIGNER, reducing the attestation policy's remaining barriers to MRENCLAVE and attribute enforcement.

More broadly, for any system that relies on TEEs, attestation cannot stop at confirming that the signature chain is valid and the measurement is allowlisted. Each layer of the trust chain must independently enforce its security properties.

References

[1] Phalcon Alert: Taiko Bridge Exploit Detection
[2] Intel SGX Developer Guide

More Incidents This Week

SecondFi Incident

On June 23, 2026, SecondFi (formerly Yoroi), a Cardano wallet developed by EMURGO, disclosed a critical vulnerability in its Ed25519 signing implementation [1]. The wallet's signing implementation computed the signing nonce from only the public transaction message, omitting a required secret input. This reduced the digital signature to a single-equation problem, allowing attackers to recover address-level private keys from public on-chain data. Two separate attackers exploited the flaw, draining approximately $2.4M (16M ADA) from 374 wallets [2].

Background

SecondFi is a self-custody wallet for the Cardano blockchain, rebranded from Yoroi in April 2026. Originally developed by EMURGO, one of Cardano's three founding entities, Yoroi previously served over one million users.

Ed25519 is the digital signature scheme used by Cardano for transaction authorization. The signer holds a signing scalar $k_{L}$ (the private key for a specific address) and a secret nonce prefix $k_{R}$ associated with the same key material. For a given message $M$ (the transaction payload), the signing nonce is computed as $r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L$ . Because $k_{R}$ is secret, $r$ remains unknown to observers even though $M$ is public after broadcast.

The nonce point $R = r \cdot B$ (where $B$ is the fixed Ed25519 base point) and the signature scalar $s \equiv r + H \cdot k_L \pmod{L}$ (where $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ binds the nonce, public key, and message) form the final signature $(R, s)$ . The security of the scheme depends on $r$ being unpredictable: if an observer can compute $r$ , the signature equation becomes a single-unknown linear equation solvable for $k_{L}$ .

Vulnerability Analysis

This vulnerability is in SecondFi's wallet signing software, not in a smart contract.

Combining existing analysis [2] with our own investigation, we found that versions v10.0.3 through v10.0.6 (live from June 8, 2026; fixed in v10.0.6.2) are affected. The vulnerable implementation computed the signing nonce as:

r = \operatorname{SHA-512}(M) \bmod L

instead of the correct:

r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L

This removed the only secret input ( $k_{R}$ ) from nonce derivation. Since $M$ is public, anyone can recompute $r$ for any transaction signed by an affected address.

With $r$ known, the signature equation $s \equiv r + H \cdot k_L \pmod{L}$ becomes solvable:

k_L \equiv (s - r) \cdot H^{-1} \pmod{L}

All values on the right side are either public or computable from the on-chain signature and transaction data. This is not reversing a hash or solving the discrete logarithm from $A = k_L \cdot B$ ; the flawed implementation directly exposed $r$ , reducing key recovery to straightforward modular arithmetic.

The impact is address-scoped key compromise. Any address that produced a signature through the vulnerable implementation should be treated as compromised.

Importing the same mnemonic into a patched wallet does not protect the already-exposed address; funds must be moved to a newly generated key that has never signed through the vulnerable signing implementation.

Attack Analysis

This attack does not follow a typical on-chain exploit sequence with traceable smart contract interactions. Because the vulnerability exposes a deterministic relationship between public data and the signing key, key recovery is performed offline.

Step 1: Identify target addresses that signed transactions using SecondFi v10.0.3 through v10.0.6.
Step 2: For each target, retrieve the transaction's public signature components ( $R$ , $s$ ) and reconstruct the message $M$ from the on-chain transaction payload.
Step 3: Compute the signing nonce $r = \operatorname{SHA-512}(M) \bmod L$ , exploiting the fact that the vulnerable signing implementation omitted the secret nonce prefix $k_{R}$ .
Step 4: Compute the challenge scalar $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ .
Step 5: Solve for the signing scalar: $k_L \equiv (s - r) \cdot H^{-1} \pmod{L}$ .
Step 6: Use the recovered $k_{L}$ to sign arbitrary transactions from the compromised address and transfer funds to attacker-controlled wallets.

Two separate attackers exploited this vulnerability independently. One compromised 171 wallets in two waves, while a second drained 203 wallets in a separate sweep, collectively extracting approximately 16M ADA (~$2.4M) [2]. EMURGO subsequently rescued a further 129M ADA before the attackers could reach those funds.

Conclusion

The root cause was a cryptographic implementation flaw that removed the secret nonce prefix from Ed25519 nonce derivation, reducing the signing nonce to a deterministic function of public data. Every affected signature became a single-equation key recovery problem.

This incident underscores that wallet developers should use well-audited, standard Ed25519 libraries rather than custom signing implementations. Any deviation from the specification, even one that appears minor such as omitting a single hash input, can compromise the entire key. Production signing software should undergo independent cryptographic audit before deployment, particularly when handling key derivation and signing operations.

References

[1] SecondFi Post-Incident Disclosure
[2] Tibane Labs: SecondFi Cardano Forensic Analysis

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.