Executive summary
On 18 May 2026, the Verus Ethereum Bridge was exploited for approximately $11.58 million, 103.6 tBTC, 1,625 ETH, and 147,000 USDC. The bridge verified Merkle proofs from the Verus chain, but did not validate whether the claimed source-side value was backed by a legitimate deposit. An attacker used a forged cross-chain import payload to satisfy the proof check and trigger funds release without a real corresponding deposit.
The stolen assets were swapped and consolidated into approximately 5,402 ETH. The attacker wallet was initially funded through Tornado Cash, obscuring its origin.
Key concepts: This analysis covers private key, bridge operator, smart contract security, custody and related blockchain security topics.
What happened
Cross-chain bridges face a fundamental challenge: the destination side must decide whether to trust a claim that something happened on the source side. The most common mechanism is a Merkle proof, a cryptographic commitment that a specific event (typically: a deposit) was included in a source-chain block and is therefore real.
The Verus Bridge appeared to verify that a cross-chain import payload was structurally consistent with the Merkle proof. What it did not verify was whether the claimed value in the import actually corresponded to a genuine source-side deposit. The distinction matters: a forged payload can be constructed to be Merkle-valid, committed to a real block, without the underlying deposit ever having occurred, if the source-side commitment logic can be manipulated.
The attacker exploited this gap, submitting a crafted import payload that satisfied the bridge's proof verification while triggering a payout on the Ethereum side that had no real backing. The three asset pools, tBTC, ETH, and USDC, were drained in the attack.
Why proof verification is not enough
Merkle proof verification confirms that data was committed to a block. It does not confirm what that data means or whether the underlying economic event is real. A bridge that verifies proof structure but does not independently confirm the economic intent of the source-side event is relying on an incomplete set of guarantees.
This is a known class of risk in cross-chain design. "Proof validity" and "economic validity" are different claims, and a bridge that conflates them is building its security on an assumption that the source chain's commitment logic is completely sound and unforgeable. That is a significant trust dependency.
The attacker's use of Tornado Cash for initial wallet funding is also significant for operational security teams: it signals pre-operational obfuscation, meaning the exploit was planned, not opportunistic. By the time the exploit transaction hits the chain, the preparatory footprint has already been obscured.
What defenders can learn
Proof validity and value validity are separate checks. Verifying that a Merkle proof is structurally correct proves that data was committed to a block, nothing more. Bridges must separately validate the economic claim: that a deposit of the exact assets and amounts being released was legitimately made on the source side. These are two different guarantees and require two different controls.
Watch for Tornado Cash funding of fresh wallets. Pre-exploit wallet preparation is a detectable signal in many real-world attacks. Monitoring for newly-funded wallets interacting with bridge contracts, particularly those sourced from mixers, is a practical early-warning tripwire. The signal is noisy, but it is real.
Multi-asset bridge pools amplify blast radius. A single exploit affecting three separate asset pools is a direct consequence of a shared vulnerability in the cross-chain import path. Isolating asset pools behind independent validation logic, or adding per-asset circuit breakers, limits the damage if one path is compromised.
Key details
- Date: 18 May 2026
- Loss: ~$11.58M (103.6 tBTC, 1,625 ETH, 147K USDC)
- Consolidated to: ~5,402 ETH
- Chain: Ethereum / Verus cross-chain bridge
- Attacker wallet:
0x5aBb91B9… - Drainer contract:
0x65Cb8b12… - Attacker funding source: Tornado Cash
Further reading
Bridge security is one of the most complex challenges in Web3. If you're running a cross-chain protocol or integrating bridge infrastructure, Security4Web3 can help you understand where your proof validation model ends, and where your economic validation needs to begin.
Private Key Security and Bridge Governance: Lessons from the Verus Exploit
The Verus Ethereum Bridge exploit is technically described as a forged import vulnerability — a failure to validate that a claimed source-side deposit actually occurred. But there is an operational layer to this incident that the technical postmortem alone does not capture: the attacker used Tornado Cash to fund a fresh wallet before the exploit, which is a pre-operational obfuscation step that signals deliberate planning, not opportunistic discovery. By the time the attack transaction was submitted, the preparatory footprint had already been obscured.
This matters for how bridge operators think about their security posture. The threat is not a random scanner finding a bug — it is a deliberate actor who has already selected the target and prepared an exit path. The security controls need to match that threat model.
Bridge Operator Key Security Is an Operational Problem
Cross-chain bridges that rely on a small set of operator keys or signers to authorise fund releases are, at their core, key management systems. The security of the bridge is bounded by the security of those keys. Yet the key management practices in many DeFi bridge operations would not meet the minimum standards for a traditional financial institution handling equivalent value.
The relevant threat scenarios are not just external attackers finding a contract bug. They include: compromise of an operator's device or credential store; targeted phishing or social engineering of a key holder; insider action by a team member with key access; and supply chain attacks on the software used to generate or store keys. Each of these vectors bypasses smart contract security entirely — they grant the attacker legitimate signing authority.
- Hardware Security Modules (HSMs): HSMs store private keys in tamper-resistant hardware and enforce that signing operations occur only within the device, with no key material ever exposed to software. For bridge operator keys controlling significant TVL, HSM storage is the appropriate baseline, not a premium option.
- Multi-Party Computation (MPC): MPC key management splits the private key across multiple parties such that no single party ever holds or reconstructs the full key. Signing requires cooperation between threshold participants. This eliminates the single-key single-point-of-failure model while maintaining operational flexibility.
- Governance structure for signing authority: Who can authorise a bridge operation? Under what conditions? With what time delay or challenge mechanism? These are governance questions, and the answers need to be documented, enforced technically, and reviewed regularly — not assumed.
- Key rotation and revocation procedures: Operator key rotation schedules and defined procedures for emergency key revocation are operational controls that significantly reduce the window of exposure if a key is suspected to be compromised.
Building Governance Around Bridge Operations
The most robust bridges treat their governance structure as a primary security control, not an afterthought. This means making explicit decisions about who holds signing authority, implementing technical thresholds that enforce those decisions, and designing operational procedures that make collusion or unilateral action detectable and difficult.
Our private key storage and HSM/MPC advisory service helps bridge operators and protocol teams design key management architectures that match their threat model — from basic HSM integration through to full MPC governance frameworks. For bridges that require multi-party authorisation, our multisig governance and key ceremony service establishes the procedural and technical foundations for signing operations that hold up under adversarial pressure.
The Verus exploit drained $11.58 million. The smart contract vulnerability was the mechanism. The real question every bridge operator should be asking is: if an attacker already has your keys, what stops them?