Home / Critical Brief / No. 107

Verus-Ethereum bridge

the same entry path was hit again two months later, paying out $7.54M without backing

Pillar 01 · Verifiable Origin Bridge Config Trust Data ProvenanceIdentity & Auth
Incident date
2026-07-23
Published
2026-07-24
Authors
Lemma Critical Team
Related Pack
Pack AIncident Response

TL;DR

The Verus-Ethereum bridge was attacked again on 2026-07-23, paying out roughly $7.54 million worth of assets with no backing. Blockaid noted that this incident is “the same bridge contract, the same entry path, the same class of bug” as the May exploit of the same year (Brief No.016). The May incident was detected, Halborn’s technical analysis was published, and negotiation returned about 75% of the funds — and yet, about 66 days later, the same entry path again let a valid payout through. What this exposes is a gap: detection and after-the-fact analysis do not amount to independently verifiable proof that “the structural gap has been closed.” Detection and pre-action proof are complementary, not substitutes.

Incident Summary

  • Subject: Verus Protocol’s Verus-Ethereum cross-chain bridge. The affected contract is identical to May’s (0x71518580f36feceffe0721f06ba4703218cd7f63).
  • Amount lost: roughly $7.54 million worth. The drained assets were about 1,137 ETH plus tBTC, USDC, USDT, EURC, MKR, and scrvUSD. Based on Etherscan’s valuation of the principal drain at the time.
  • Date and time: 2026-07-23. On-chain records show an exploit transaction interacting with the bridge contract executed at 03:45 UTC.
  • Method: the attacker exploited the bridge’s import handling and generated a payout on the Ethereum side without corresponding backing assets on the source side (Blockaid).
  • Relation to May: Blockaid described this as “appearing related to the May Verus-Ethereum bridge incident,” explaining it as “the same bridge contract, the same entry path, the same kind of bug.” However, the confirmed technical cause of this incident is unpublished, and the exact root cause is under investigation.
  • Cumulative: together with May (about $11.58 million), the combined loss across both incidents is on the order of $19.1 million.
  • Same-day context: this is one of several bridge/protocol attacks that occurred in quick succession on 7/23; on-chain tracking (Lookonchain) tallied that day’s AFX Trade (about $24.15 million), Verus (about $7.55 million), and B² Network (about $3.86 million) at roughly $35.55 million combined.

Timeline

  • 2026-05-18: about $11.58 million was drained from the Verus-Ethereum bridge (Brief No.016). Verification of consistency between the value posted on the source side and the payout amount on the Ethereum side was missing.
  • around 2026-05-22: through negotiation the attacker returned about 4,052.4 ETH (about 75%, roughly $8.5 million at the time) and kept about 1,350 ETH as a bounty. Halborn published a technical root-cause analysis.
  • 2026-07-23 03:45 UTC: an exploit transaction against the same bridge contract was executed, and about 1,137 ETH and other assets were moved to an attacker-controlled address (0xCFd0…2D54).
  • 2026-07-23: Blockaid detected the attack on Ethereum, describing it as “the same contract, the same entry path, the same kind of bug” as May. However, the confirmed technical cause is under investigation, and the status of asset freezes/returns/recovery and any new fix plan or operational-change timeline are unconfirmed as of this writing.

Note: the technical facts are based on Blockaid’s detection report and reporting by established media (crypto.news, news.bitcoin.com, AMBCrypto, and others). The exact root cause of this incident is under investigation as of this writing, and whether it was a residual of the May flaw, a related but distinct weakness, or a different path through the same import handling cannot be established from the outside. Consult the latest primary sources.

Chain of Events

  1. Reaching the same entry path: the attacker reaches the import handling of the same bridge contract as May (the path that converts a cross-chain deposit into a payout on the Ethereum side).
  2. Generating an unbacked payout: exploiting the import handling, the attacker generates a payout on the Ethereum side without corresponding backing assets on the source side. As in May, the consistency between the input (the value actually posted on the source side) and the output (the payout on the Ethereum side) is not independently verified.
  3. Draining of assets: about 1,137 ETH and multiple tokens move to an attacker-controlled address.
  4. Repetition of the structure: even after May’s detection, disclosure, and technical analysis, about 66 days later the same entry path and the same kind of bug again reach a valid payout.

Structural Analysis

This incident belongs to the bridge-config-trust category of Pillar 01 (Verifiable Origin). The central failure primitive shares its root with May (Brief No.016): a cross-chain value claim is connected to a payout on the Ethereum side without being independently verified as the consistency of input and output amounts. As secondary categories we add data-provenance, for the authenticity of the deposit data underlying the payout, and identity-auth, for the path that authorizes the payout.

What is specific to this incident is that the same structural gap recurred about 66 days later, even after detection, disclosure, and third-party technical analysis. In the May incident, on-chain monitoring detected the drain, Halborn published the root cause, and negotiation recovered about 75%. The detection-and-response sequence functioned. And yet in July, in Blockaid’s words, “the same contract, the same entry path, the same kind of bug” again reached a payout. What is at issue is less the individual implementation bug itself than whether the once-detected-and-analyzed structural gap had been brought into a state that could be independently verified from the outside as “closed.” The exact cause this time is under investigation, and whether the May flaw remained or it was an adjacent, distinct path cannot be asserted. But in either case, the fact that “the same entry path again let an unbacked payout through” shows that detection is not proof of structural closure.

As the direct follow-up to Brief No.016 (this bridge’s May incident), it connects with Brief No.067 (Syscoin bridge, where a fake proof was interpreted as “valid”), Brief No.001 (KelpDAO / rsETH), Brief No.023 (Alephium), and Brief No.085 (Secret Network, where unbacked wrapped tokens were minted) through the structure in which the consistency and backing of a claim being handed over is accepted without independent verification. It is adjacent to the recent Brief No.103 (Ostium) in that a path where external input connects directly to asset payout is missing one step of verification.

The Detection–Proof Gap

Blockaid’s detection this time, Halborn’s root-cause analysis in May, and the asset recovery through negotiation are indispensable to grasping, containing, and discussing prevention of the harm, and this Brief does not deny that role. In the May incident this sequence recovered about 75%. Detection and after-the-fact analysis do play their part.

At the same time, detection and after-the-fact analysis do not provide material to independently establish — at the moment the next payout occurs — that “this structural gap is now closed, and no unbacked payout will pass through the same entry path.” May’s technical analysis made visible “what happened,” but whether the bridge’s criterion for accepting a payload was actually updated as input-output consistency, and in an independently verifiable form, could only be learned from the outside by awaiting the result of a payout. The fact that this time the same contract, the same entry path, and the same kind of bug again reached a payout exposes exactly that gap. As material for an audit or regulatory report to establish “was this bridge’s cross-chain payout a legitimate one whose backing consistency was verified?”, the mere history that “the past incident was detected and analyzed” is not an independent trail of the current payout’s consistency.

Pre-execution attestation adopts a design in which the receiving side accepts the cross-chain value claim as a cryptographic proof it can independently verify before execution, and verifies the consistency between “the value actually posted on the source side” and “the payout amount on the Ethereum side” as a proof. If the proof reports an inconsistency, the payout is blocked up front. Because this verification sits in a layer independent of the fix for any specific implementation bug, even “a different path through the same entry” does not pass a payout unless the consistency is satisfied. After-the-fact detection and analysis (the detection-side “what happened”) and pre-payout attestation of consistency (“is this payout consistent with the source?”) are a complement, not a substitute.

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 Context

  • Verus / detection (Blockaid): Blockaid detected the attack on Ethereum and pointed out its relation to the May incident (same contract, same entry path, same kind of bug). However, the confirmed technical cause this time is under investigation and the full technical report is unpublished. The status of asset freezes/returns/recovery and any new fix plan or operational-change timeline are unconfirmed as of this writing.
  • The course since May: in the May incident, negotiation returned about 4,052.4 ETH (about 75%) and Halborn published the root cause. This recurrence arose after that detection and analysis.
  • Cross-industry point: this case is positioned as one of the bridge/protocol attacks (AFX Trade, B² Network, and others) that occurred in quick succession on 7/23, and shows that through 2026 the input and consistency verification of cross-chain infrastructure has remained a relatively soft target. The fact that the same structural gap can recur after detection and analysis is prompting a cross-industry reappraisal of the need to treat “detecting an incident” and “independently verifying structural closure” as separate matters.

“How to independently verify that a once-detected-and-analyzed cross-chain structural gap has actually been closed” is expected to advance, prompted by this incident, as a requirement for bridge operations.

Lemma’s Analysis

Against the detection–proof gap this incident exposed (detection and analysis were performed, but the same entry path again let an unbacked payout through about 66 days later), Lemma proposes a design in which the receiving side takes the cross-chain value claim as a cryptographic proof it can independently verify before execution, and verifies consistency as a proof.

  • Pre-action proof of the value claim: take the cross-chain value claim, before payout, as a cryptographic proof that can be independently verified. Do not make “it was detected and analyzed in the past” the basis for acceptance.
  • Verification of input-output consistency: verify the consistency between “the value actually posted on the source side” and “the payout amount on the Ethereum side” as a proof. If the consistency is not satisfied, the payout is rejected up front.
  • A verification layer independent of implementation bugs: by placing consistency verification outside any specific implementation path, do not pass a payout unless the consistency is satisfied — even for “a different path through the same entry.”
  • Design principle: apply the core of the Verifiable Origin category — “cryptographically valid / previously analyzed ≠ semantically consistent” — to a case that surfaced it in the form of a recurrence of the same gap.

This incident is one in which the failure mode assumed by an existing reference implementation (pre-action attestation of bridge provenance) surfaced as a reality that recurs even after detection and analysis.

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

Sources

About this Brief’s distribution

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

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

Related Briefs
See all 14 in Bridge Config Trust
No. 108 · 2026-07-24

AFX Trade

compromised validator keys met the two-thirds quorum "validly" and released $24.15M

Bridge Config Trust Identity & Auth
Brief →
No. 085 · 2026-06-30

Secret Network: Deposits From a Forged Channel Went Unverified, Letting Unbacked Wrapped Tokens Be Minted Without Limit

On the IBC bridge connecting Secret Network and Axelar, about $4.67 million in assets was withdrawn despite there being …

Bridge Config Trust Identity & AuthData Provenance
Brief →
No. 081 · 2026-06-26

Bybit: a "legitimate" multisig approval signed by trusting the UI drained a supposedly secure Ethereum wallet

JavaScript injected into the Safe{Wallet} frontend left signers no way to verify what they were signing (Bybit / Mandiant)

Bridge Config Trust Identity & Auth
Brief →
Citation

Cite this Brief

Lemma Critical Team. (2026).
"Verus-Ethereum bridge — the same entry path was hit again two months later, paying out $7.54M without backing".
Lemma Critical Brief No.107. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/107-verus-ethereum-bridge-repeat-exploit/