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

On 2026-05-18, approximately $11.58M was drained from the Verus-Ethereum cross-chain bridge. The root cause was that the bridge did not mandate verification that the “input amount on the Verus side” matched the “payout amount on the Ethereum side” — the checkCCEValues function on the Ethereum side lacked source-amount verification. The attacker’s cross-chain import payload composed an $11.58M-equivalent payout (in ETH / tBTC / USDC) against only $0.01-equivalent of VRSC on input, but each component of the blob (state root, hashes, Merkle Proof) was valid, so the Verus notary accepted and approved it. A Merkle Proof being cryptographically valid is a separate question from the value claim (input vs. payout amount) being semantically correct. The case is a recent representative example of the detection–proof gap in Pillar 01’s bridge-config-trust category: cross-chain value claims accepted without an independent verification layer.

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

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 that the cross-chain value claim (“source side contributed this much value for this import”) 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 (see The Last Layer Left for Cyber Defense in the AI Era (Lemma, 2026-05) for the thesis on detection vs. pre-execution attestation).

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 the integrity of “value actually contributed on the source side” against “payout amount” is verified as a proof. Even if a Merkle Proof is formally valid, if the value-claim proof signals input/payout inconsistency, the payout is rejected before it executes. The design thinking of “cryptographically valid ≠ semantically correct” — the core of the verifiable-origin category — is shown in the verifiable-origin proof sample (GitHub) reference implementation. 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 background see What the 2026 Bridge Incidents Are Showing — On the Verifiable-Origin Category (Lemma, 2026-04) and Proof-as-Auth: Sign In Without Sending Your Key (Lemma, 2026-05).

Sources

About distribution

Lemma Critical Brief is a threat intelligence brief published by Lemma. It is structured analysis of public information — not an audit, assessment, or recommendation directed at any specific organization. For decision-support use, please consult your Lemma Critical contact directly.

Discovery Call → Whitepaper → ✉️ Newsletter →

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

Related Briefs
See all 4 in Bridge Config Trust
No. 023 · 2026-06-05

The Alephium TokenBridge Exploit ($815K)

Guardian Keys Intact, But No Verification of the Provenance of the Events They Signed

Bridge Config Trust Identity & Auth
Brief →
No. 002 · 2026-05-29

Stake DAO vsdCRV Unauthorized Mint

LayerZero v2 Trust Source Rewriting via Deployer Key

Bridge Config Trust Identity & Auth
Brief →
No. 001 · 2026-05-29

KelpDAO / rsETH Unauthorized Unlock

RPC Manipulation Attack on the DVN Observation Layer

Bridge Config Trust Identity & Auth
Brief →
No. 036 · 2026-06-08

12.8 Billion Training Images Contained Passports, Résumés, and Faces

The Provenance and Consent of Training Data Were Never Verified at Collection

Training Data Provenance Data ProvenanceAttribute Proof Bypass
Brief →
No. 030 · 2026-06-06

Stripe's Trusted API Infrastructure Repurposed to Deliver Card-Skimming Code and Store Stolen Data

Allowlists Trust the Domain's Identity, Not the Provenance of What It Carries

Code Provenance Identity & AuthData Provenance
Brief →
No. 028 · 2026-06-05

The npm Dependency-Confusion Recon Campaign

33 Packages Impersonating Internal Scopes Exploit the Build Environment's Provenance Assumptions

Code Provenance Identity & Auth
Brief →

Lemma Critical Monthly

The structural analysis of real-world risk incidents (Critical Brief) at its core, plus insight on the proof needed beyond detection, once a month.

Subscribe to the newsletter
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/