Home / Critical Brief / No. 016

The Verus-Ethereum Bridge Hack ($11.58M)

A Valid Merkle Proof, But No Verification That the Source Amount Matched the Payout

Pillar 01 · Verifiable Origin Bridge Config Trust Identity & Auth
Incident date
2026-05-18
Published
2026-05-31
Authors
Lemma Critical Team
Related Pack
Pack AIncident Response

TL;DR

In May 2026, about $11.58M was drained from the Verus-Ethereum bridge. The attacker composed a blob directing a massive payout against a $0.01-equivalent input, but its components — state root, Merkle Proof, and the rest — were all valid, so signature verification passed. Missing was a check that input matched payout, and anomaly detection firing afterward cannot stop an accepted payout. A valid Merkle Proof attests only inclusion, not that the value claim is correct. Detection and pre-execution attestation are complements, not substitutes.

Incident Overview

  • Affected: the Verus-Ethereum cross-chain bridge operated by the Verus Protocol
  • Loss: approximately $11.58M (in ETH / tBTC / USDC)
  • Date: 2026-05-18
  • Root cause: both sides of the bridge performed their own verification, but no mandatory step verified that the source-chain input amount matched the Ethereum-side payout. The checkCCEValues function on the Ethereum side lacked this verification
  • Core of the abuse: the transfer blob carried a fundamental mismatch between input and payout ($0.01-equivalent VRSC input vs. $11.58M-equivalent ETH / tBTC / USDC payout), but the blob’s components (state root, related hashes, Merkle Proof) were all valid, so the Verus notary accepted and approved it
  • Analysis: Halborn published a technical root-cause explanation
  • Aftermath: under a negotiated bounty arrangement, the attacker returned about 75% of the proceeds (4,052.4 ETH) and kept about 1,350 ETH (~$2.8M) as a bounty
  • Context: 2026 bridge-related exploits cumulatively reached ~$300M, per aggregate reporting

Timeline

  • 2026-05-18: ~$11.58M drained from the Verus-Ethereum bridge. The attacker composes a massive payout against a $0.01-equivalent input
  • 2026-05-18 onward: the attacker swaps the exfiltrated assets to ETH (reportedly about 5,402 ETH total). Reports describe an ongoing attack
  • 2026-05-22 around: a negotiated bounty arrangement is reached. The attacker returns about 4,052.4 ETH (~75%) and keeps about 1,350 ETH as a bounty
  • 2026-05 (same period): Halborn publishes a root-cause technical explanation

Note: proper nouns and CVE identifiers are based on primary sources (research labs, the GitHub Advisory Database, NVD, and the like); each implementation’s remediation status varies over time, so consult the latest information.

Attack Vector

  1. Composing a mismatched payload: the attacker composes a cross-chain import payload directing an $11.58M-equivalent payout against a $0.01-equivalent VRSC input
  2. Valid cryptographic components: the state root, hashes, and Merkle Proof corresponding to that blob are all valid. Cryptographic verification passes
  3. Missing value-integrity check: checkCCEValues on the Ethereum side lacks source-amount verification, so the input/payout mismatch is not caught
  4. Acceptance by the notary: with the blob’s components valid, the Verus notary accepts and approves the payload
  5. Realization of the massive payout: exploiting the absent integrity check, $11.58M-equivalent payout is realized against $0.01-equivalent input
  6. Asset movement: the exfiltrated assets are swapped to ETH and other tokens. Approximately 75% is later returned under negotiation

Structural Argument

The incident belongs to the bridge-config-trust category of Pillar 01 (Verifiable Origin). The central failure primitive is “the cross-chain value claim was not independently verified as the integrity of input vs. payout amount, apart from the validity of the cryptographic components (Merkle Proof and so on).” A valid Merkle Proof shows “this blob is included in the state root”; it does not show “the payout amount matches the source-side input amount.” identity-auth is noted as a secondary category.

The same bridge-config-trust category as Brief 001 (KelpDAO / rsETH) and Brief 002 (Stake DAO / vsdCRV), but a different primitive. Brief 001 was RPC manipulation of the DVN observation layer; Brief 002 was rewriting the trust source via the deployer key; this incident is the absent integrity check on the value claim. All three share the structure that “claims passed between chains are accepted while decoupled from a layer that independently verifies them.” This case concretely illustrates the verifiable-origin category’s core thesis — “cryptographically valid ≠ semantically correct” — with the extreme gap of $0.01 input → $11.58M payout.

The detection–proof gap

Bridge monitoring, anomaly detection, and post-hoc root-cause analysis (such as Halborn’s) are indispensable for understanding impact, containment, recurrence discussion, and negotiated asset recovery. This Brief does not deny their role; about 75% was in fact recovered through post-hoc analysis and negotiation.

But detection does not change what the receiving side (the Ethereum-side contract, the notary) actually accepts. The blob’s cryptographic components were all valid, so signature and Merkle Proof verification passed. What was missing was verification of “is the value claim semantically correct (does the input amount match the payout)?” — a separate question from cryptographic validity. Anomaly detection firing after a payout does not stop the payout that checkCCEValues accepted at the time. For regulatory reporting and audit, the validity of a Merkle Proof alone is not an independent evidentiary trail that “this cross-chain import was a legitimate value claim.”

Pre-execution attestation takes the design choice of receiving the cross-chain value claim as an independently verifiable cryptographic proof on the receiving side, before execution, and verifying the integrity of “value actually contributed on the source side” against “payout amount.” If the proof signals “input and payout amounts are inconsistent,” the payout is blocked before it executes. Inclusion proofs via Merkle Proof (detection-style: “this blob exists”) and pre-execution attestation of the value claim (“this payout matches the source-side input”) are complementary rather than substitutes.

For the detection-vs-attestation thesis, see “The last layer left for cyber defense in the age of AI” (Lemma, 2026-05); for verifying before the action, see “Proof-as-Auth: sign in without ever sending your key” (Lemma, 2026-05).

Response and Industry Response

  • Verus Protocol: after the drain, reached a negotiated bounty arrangement with the attacker and received the return of about 4,052.4 ETH (~75%). The attacker retains about 1,350 ETH as a bounty
  • Halborn: published the technical explanation of the root cause (missing source-amount verification in checkCCEValues) and the exploit procedure, surfacing the issue across the industry
  • Cross-industry framing: 2026 bridge-related exploits cumulatively reached ~$300M per aggregate reporting, with attacks on cross-chain infrastructure continuing. Among bridge and lending operators, the realization re-emerged that verifying the validity of Merkle Proofs / signatures alone cannot guarantee value-claim integrity

How to independently verify the integrity of cross-chain value claims — as input/payout consistency, separate from the validity of cryptographic components — is the open question moving forward.

Lemma’s Analysis

Against the detection–proof gap exposed here (the cross-chain value claim was not independently verified for input/payout integrity separately from the cryptographic validity of Merkle Proofs), Lemma proposes a design in which cross-chain value claims are received as independently verifiable cryptographic proofs on the receiving side, before execution, and verified for integrity.

  • Pre-execution attestation of the value claim: receive the cross-chain value claim as an independently verifiable cryptographic proof on the receiving side, before execution.
  • Input/payout integrity check: verify the integrity of “value actually contributed on the source side” against “payout amount” as a proof.
  • Rejection before execution on mismatch: even if a Merkle Proof is formally valid, if the value-claim proof signals input/payout inconsistency, the payout is rejected before it executes.
  • Design thinking: it implements the core of the verifiable-origin category — “cryptographically valid ≠ semantically correct.”

This incident is a case in which the failure mode anticipated by the existing reference implementation (pre-execution attestation of bridge provenance) has materialized as a recent real-world loss.

For the design and its scope, see Pillar 01 — Verifiable Origin and Trust402.

Sources

About distribution

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

(c) 2026 FRAME00, INC. — Built for decisions that matter.

Related Briefs
See all 7 in Bridge Config Trust
No. 074 · 2026-06-23

Taiko Bridge: Forged Withdrawals Passed as Valid After a Prover Signing Key Leaked

a prover signing key leaked to a public repo, splitting a proof's formal validity from independent verification of prover identity (BlockSec / Blockaid)

Bridge Config Trust Code ProvenanceIdentity & Auth
Brief →
No. 067 · 2026-06-19

Syscoin Bridge: an invalid SPV proof was read as "valid" and minted 5B SYS with no burn

a parsing flaw in SPV proof verification

Bridge Config Trust Identity & Auth
Brief →
No. 045 · 2026-06-11

When One Laptop Meets the Multisig Threshold

Distributed Approval Collapses to a Single Custody Point (Humanity Protocol)

Bridge Config Trust Identity & Auth
Brief →
Citation

Cite this Brief

Lemma Critical Team. (2026).
"The Verus-Ethereum Bridge Hack ($11.58M) — A Valid Merkle Proof, But No Verification That the Source Amount Matched the Payout".
Lemma Critical Brief No.016. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/016-verus-ethereum-bridge/