Worked example · 2026-07

Verus ⇄ Ethereum Bridge, second time — the May attacker returns the funds, the team redeposits them into the unfixed contract, and a different attacker takes them out through the same import path — Verus / Ethereum — 2026-07-23

Loss: ~$7.54M drained from the bridge's Ethereum-side reserves across seven assets — ETH, tBTC, USDC, USDT, EURC, MKR, and scrvUSD. This is the second exploitation of the same contract, the same entry path, and the same vulnerability class in 66 days, taking cumulative losses across the two events to roughly $19.1M. The critical antecedent: after the 2026-05-18 exploit, the May attacker returned 4,052.4 ETH having retained a 25% white-hat bounty, and those recovered funds were redeposited into the bridge on 2026-07-08 — into a contract whose defect had not been closed. They were drained again fifteen days later.
OAK Techniques observed: OAK-T10.002 (Message-Verification Bypass — primary, confirmed mechanism, the same economic-value-binding sub-class OAK anchored on the May event. The attacker used the bridge's import path (submitImports) to trigger Ethereum-side payouts not backed by matching assets on the source side. Per Blockaid, this is the same bridge contract, the same entry path, and the same vulnerability class as May. See techniques/T10.002-message-verification-bypass.md). OAK-T10 (Bridge / Cross-Chain parent). OAK-T9.004 (cross-referenced, consistent with how OAK records the May event: the underlying defect is a missing validation predicate, a contract-correctness flaw rather than a key or consensus failure).
Attribution: pseudonymous, and — importantly — a different actor from May. Public analysis identifies a new wallet and a different attacker from the one who executed the 2026-05-18 exploit and subsequently returned funds under a white-hat arrangement. Nothing links either operator to a tracked OAK actor. Blockaid identified the repeat and published the same-vulnerability-class finding.
Key teaching point: Returning the money is not remediation, and re-funding an unpatched contract converts a recovered loss back into a live one. The May incident ended in what the industry treats as the best available outcome — the attacker negotiated, kept 25%, and sent 4,052.4 ETH back. That outcome resolved the balance sheet and left the defect exactly where it was. When the recovered funds went back into the bridge on 2026-07-08, they were placed behind a verification gap that Blockaid had already publicly root-caused in May, and a second, unrelated attacker collected them. Two rules follow. First, a returned-funds settlement must be treated as a countdown, not a conclusion — the window between disclosure and patch is now a published, widely-read exploit specification, and every party who read the post-mortem can execute it. Second, redeposit is a deployment decision requiring the same gate as any other: funds should not re-enter a contract until the specific predicate that failed is demonstrably present, and "the attacker gave it back" is not that demonstration.

Summary

The Verus ⇄ Ethereum bridge releases Ethereum-side assets against cross-chain imports authorised by a notary-signed Verus state root. OAK's examples/2026-05-verus-ethereum-bridge-source-amount-validation.md documents the original defect: the contract verified the notarised root, the Merkle proof, and the hash binding between the committed hash and the decoded transfer blob — every cryptographic check it was designed to perform — but never verified that the source-chain export's economic totals actually backed the payouts being released. On 2026-05-18 an attacker used this to extract approximately $11.58M for about $10 in source-chain fees.

That incident resolved unusually well by industry norms. The attacker returned 4,052.4 ETH, retaining a 25% white-hat bounty. The recovered funds were redeposited into the bridge on 2026-07-08.

The vulnerability had not been closed. On 2026-07-23 at 03:45 UTC, a different attacker, operating a new wallet, called the same import path and triggered the same class of unbacked Ethereum-side payouts, removing approximately $7.54M across ETH, tBTC, USDC, USDT, EURC, MKR, and scrvUSD from bridge reserves.

Blockaid, which had published the original root-cause analysis in May, identified the second event as using the same contract, the same entry path, and the same vulnerability class. Across the two exploits — 66 days apart — the bridge lost roughly $19.1M. The July incident landed inside a roughly six-hour window that also contained the AFX Trade and B² Network compromises.

Timeline (UTC)

When	Event	OAK ref
2026-05-18	First exploit: ~$11.58M drained via unbacked payouts through the import path; Blockaid publishes root-cause analysis	T10.002 (see May example)
after May	Attacker returns 4,052.4 ETH, retaining a 25% white-hat bounty	(negotiated partial recovery)
2026-05-18 → 2026-07-23	Vulnerability class remains exploitable on the same contract and entry path	(unremediated defect)
2026-07-08	Recovered funds redeposited into the bridge	(re-funding an unpatched contract)
2026-07-23 03:45	Second exploit by a different attacker on a new wallet: same contract, same import path, same vulnerability class; ~$7.54M removed across ETH, tBTC, USDC, USDT, EURC, MKR, scrvUSD	T10.002 exploitation
2026-07-23	Blockaid identifies the repeat; cumulative two-event loss reaches ~$19.1M over 66 days	(analysis)

What defenders observed

Pre-event (the disclosure clock started in May). Once Blockaid published a precise root cause, the defect was a public specification. Every day the contract stayed unpatched was a day any reader could execute it — which is what happened, by a party with no connection to the original attacker. Post-incident disclosure is correct and necessary; it also means the remediation deadline is set by publication, not by internal planning (M23, M35).
Pre-event (redeposit had no gate). Placing 4,052.4 ETH of recovered funds back into the bridge on 2026-07-08 was a value-at-risk decision made without the defect being closed. A minimal control here is a written re-funding gate: funds do not re-enter a contract until the specific failed predicate is present in deployed bytecode and independently verified. That check is cheap and would have held $7.54M out of reach.
Pre-event (goodwill recovery masked an open exposure). The May outcome was reported as a recovery, and the reporting frame plausibly reduced perceived urgency. Risk teams should score an incident by whether the defect is closed, not by how much came back — the two are independent, and only the first predicts recurrence.
At-event (identical entry path, trivially detectable). The second exploit called the same function the first one did, in the same shape. A rule matching the known-exploited call pattern on the known-vulnerable contract — the crudest possible signature, derivable directly from the May post-mortem — would have fired. When a specific exploit path is publicly documented against your own contract, monitoring for that exact path is the minimum viable interim control while the fix is built (M04, M05).
Response (a different attacker is the structurally important fact). Had the same operator returned, this would read as a negotiation breaking down. A new party executing from a new wallet demonstrates the defect was generally accessible — the exposure was to the entire population of people who read Blockaid's analysis, and the size of that population is what made 66 days an unaffordable delay.

Public references

[theblockverus2026] — The Block, "New Verus-Ethereum bridge attack drains $7.5 million through flaw used in May: Blockaid" (Blockaid's same-vulnerability-class finding, same contract and entry path, different attacker on a new wallet): https://www.theblock.co/amp/post/409489/new-verus-ethereum-bridge-attack
[newsbitcoinverus2026] — Bitcoin.com News, "Verus Bridge Suffers Second Exploit in 66 Days as Flaw Pushes Total Losses to $19.1M" (the 66-day interval and ~$19.1M cumulative figure; the 4,052.4 ETH return with a 25% white-hat bounty; the 2026-07-08 redeposit of recovered funds): https://news.bitcoin.com/verus-bridge-suffers-second-exploit-in-66-days-as-flaw-pushes-total-losses-to-19-1m/
[cryptotimesverus2026] — The Crypto Times, "Verus Ethereum Bridge Exploited Again for $7.54M in Repeat Attack" (2026-07-23 03:45 UTC timing, the seven drained assets, the submitImports import path and unbacked-payout mechanism): https://www.cryptotimes.io/2026/07/23/verus-ethereum-bridge-exploited-again-for-7-54m-in-repeat-attack/
[coindeskbridges0723] — CoinDesk, "Bitcoin, Ethereum-linked protocols lose $35 million in multiple attacks hours apart" (the July 23 cohort with AFX Trade and B² Network; the logic-flaw-versus-compromised-key framing): https://www.coindesk.com/tech/2026/07/23/bitcoin-ethereum-linked-protocols-lose-usd35-million-in-multiple-attacks-hours-apart
[cryptonomistverus2026] — The Cryptonomist, "Verus Ethereum Bridge Exploit Drains $7.54M in Latest Attack" (independent confirmation of the loss figure and repeat framing): https://en.cryptonomist.ch/2026/07/23/verus-ethereum-bridge-exploit-2/

Discussion

OAK now holds two worked examples of the same contract, and the second one contributes almost nothing new about the mechanism — the May entry remains the canonical treatment of the economic-value-binding sub-class of T10.002. What July contributes is a clean, unusually well-instrumented case study in remediation failure as an attack surface in its own right, with an exact interval (66 days), an exact re-funding date (2026-07-08), and the confirmation that the second exploiter was a different party.

That last detail is what elevates this above an operational anecdote. The standard mental model of a returned-funds settlement treats it as a bilateral resolution: the attacker is identified as cooperative, terms are agreed, the matter closes. But the defect is not bilateral. Publishing a root cause converts a private exploit into common knowledge, and from that moment the protocol is exposed to everyone who read it — a set that grows with the quality of the disclosure. Verus received good security analysis in May and was harmed by the delay in acting on it, which is an uncomfortable but real dynamic that the industry's disclosure norms have not fully priced.

The comparison worth drawing inside OAK is with examples/2026-07-allbridge-core-solana-flash-loan-pool-ratio-manipulation.md, which is also a repeat — Allbridge's second flash-loan exploit after April 2023. The two differ in the interval that matters. Allbridge's recurrence came after more than three years, across a different deployment, and reads as a class of risk the protocol never fully engineered out. Verus's came after 66 days, on the identical contract, against a published analysis, with the funds having been voluntarily returned in between. Contributors documenting repeat exploits should record the interval between public root-cause disclosure and re-exploitation as a distinct field; it separates "this class keeps finding us" from "we knew precisely what to fix and had not fixed it."