During the past week (2026/05/18 - 2026/05/24), BlockSec identified multiple attack incidents across several blockchain ecosystems. The table below lists 5 notable incidents with total estimated losses of approximately $104.6M.
| Date | Incident | Type | Estimated Loss |
|---|---|---|---|
| 2026/05/18 | Verus Incident | Business Logic Flaw | ~$11.7M |
| 2026/05/18 | EchoProtocol Incident | Compromised Private Key | ~$76.7M |
| 2026/05/20 | RetoSwap Incident | Business Logic Flaw | ~$2.7M |
| 2026/05/22 | Polymarket Incident | Compromised Private Key | ~$700K |
| 2026/05/24 | StablR Incident | Compromised Private Key | ~$12.8M |
Two incidents are selected for in-depth analysis:
- Verus: the attacker exploited a type-validation failure in the Verus-Ethereum Bridge by submitting a handcrafted supplemental export output that the bridge misclassified as a valid primary export. Cross-chain message semantics are part of the attack surface.
- RetoSwap: a protocol-level authentication flaw in the P2P trade flow allowed an attacker to hijack the arbitrator role by sending a forged ACK message. The attacker compromised multisig wallet creation entirely off-chain.
Best Security Auditor for Web3
Validate design, code, and business logic before launch
Weekly Highlight: Verus
This incident is highlighted because the attacker deliberately abused a specialized cross-chain export type, indicating deep understanding of the Verus chain's internal design. The exploit shows that cross-chain message formats, including supplemental data fields and encoding boundaries, are part of the attack surface and require the same rigor as cryptographic proof verification.
On May 18, 2026, the Verus-Ethereum Bridge, a cross-chain bridge connecting the Verus L1 chain and Ethereum, was exploited for approximately $11.7M in ETH, tBTC, and USDC [1][2]. The root cause was a type-validation failure in the Ethereum-side import path: the bridge contract accepted a handcrafted supplemental export output and misclassified it as a valid primary export, allowing the attacker to supply matching transfer data and drain funds. As of May 23, approximately 75% of the stolen funds had been returned.
Background
The Verus-Ethereum Bridge releases assets on Ethereum after someone proves that a qualifying Verus-side export exists under a notarized Verus state. Ethereum does not directly observe Verus transactions; it relies on submitted proof data plus a notarization that anchors what Verus state is trusted.
Three bridge objects are relevant to this incident: a primary export, which is the object Ethereum imports and uses for payouts; a supplemental export output, which is extra data attached to the primary export and is not intended to be treated as a standalone active export for payout purposes; and a notarization, which lets Ethereum prove that a specific Verus-side object existed in finalized bridge state.
Vulnerability Analysis
The buggy Ethereum-side bridge contracts are deployed at 0xa045...6fc87f and 0x08f0...d0107d.
The root cause was a type-validation failure in the Ethereum import path. The bridge proved that a real Verus-side object existed but did not verify that the proven object was a valid primary export before using it to release funds. Instead, it accepted a handcrafted supplemental output and parsed it as if it were a normal active export.
At a high level, the vulnerable flow is:
proveImports(...)
-> verify proof
-> verify keccak256(serializedTransfers) == committed transfer hash
processTransactions(...)
-> execute payouts on EthereumNo check in this flow rejects objects with FLAG_SUPPLEMENTAL set. The fix explicitly checks for this flag and reverts when the proven object is supplemental:
Attack Analysis
The following analysis is based on the Ethereum transaction 0x6990f0...87eb321 and the Verus transaction f899e698...b9f5a733.
-
Step 1: On May 17, the attacker funded the Ethereum address
0x5aBb...9D5777with 1ETHvia Tornado Cash. On May 18, the attacker obtained 0.02VRSCfrom the Verus faucet for the addressRW9vEW...B3g6zd. -
Step 2: The attacker submitted four Ethereum-destined export transactions on Verus containing crafted supplemental export outputs. These supplemental outputs were encoded to be parseable without error and contained a
hashReserveTransferscommitment matching the fraudulent payouts the attacker intended to execute later. -
Step 3: After a cross-chain notarization advanced far enough on Ethereum, the attacker submitted a forged import transaction on Ethereum. The proven Verus-side object was the supplemental output from the Verus transaction above.
-
Step 4: The Ethereum bridge accepted the proof but did not reject the proven object as supplemental data. Instead, it parsed the crafted output as if it were a valid active export. Because the attacker also supplied
serializedTransferswhose hash matched the committedhashReserveTransfersvalue, the bridge proceeded through the import flow. -
Step 5: With the supplemental output misinterpreted as a valid export, the fraudulent transfers passed the Ethereum-side checks. The attacker drained approximately $11.7M in
ETH,tBTC, andUSDC. -
Step 6: Shortly after the malicious import succeeded, Verus nodes encountered an invalid-state assertion caused by the coexistence of the fraudulent export thread and a real export thread, which halted further bridge progression and limited follow-on exploitation.
Conclusion
The incident was caused by a type-validation failure in the Verus-Ethereum Bridge: the Ethereum contract accepted a real cryptographic proof, but the proven object was a supplemental export output, not a valid primary export for payouts.
Cross-chain message formats are part of the attack surface. Supplemental data, optional fields, compact encodings, and parser offsets should be treated with the same rigor as signature or Merkle-proof checks. When an object does not match the expected type for the action being executed, the bridge should reject it outright rather than attempting to parse it.
References
More Incidents This Week
RetoSwap
On May 20, 2026, RetoSwap, a decentralized P2P exchange on Monero forked from Haveno Protocol, was exploited for approximately $2.7M (7,000 XMR) [1]. The root cause was a protocol-level authentication flaw: the client accepted a forged, out-of-order ACK message and overwrote the arbitrator's stored Tor address with an attacker-controlled one without verifying the sender against the arbitrator's known public key. This allowed the attacker to hijack multisig wallet creation and steal funds as soon as they were deposited.
Background
RetoSwap is a decentralized P2P exchange on Monero, forked from Haveno Protocol. Its trading protocol relies on a 2-of-3 arbitrator multisig model to secure trades and coordinates trades off-chain over Tor.
A normal trade proceeds in three phases: first, the buyer, seller, and arbitrator complete off-chain message exchanges to establish a multisig wallet; second, funds are locked into the multisig wallet only after it has been fully created; third, the buyer and seller co-sign a payout transaction to settle, or the arbitrator steps in to resolve disputes. All communication runs over Tor, and each node is identified solely by its .onion address.
Vulnerability Analysis
On May 20, the Haveno project opened a pull request titled "core: refuse to update node address before multisig created" [2]. By then, RetoSwap was already under exploit.
The patch revealed a vulnerability in TradeProtocol.java:onAckMessageAux(...). The client identified peers using a message-supplied senderNodeAddress without cryptographically verifying that the sender matched the expected arbitrator's public key. An attacker could send a forged ACK message carrying an attacker-controlled .onion address, and the client would overwrite the stored arbitrator address with it.
Since this occurred during Phase 1 (before multisig wallet creation), the attacker's address replaced the real arbitrator's address. The attacker therefore held both the trader's key and the arbitrator's key of the multisig wallet, enabling theft of the entire balance once funds were deposited.
The fix addresses this in two ways: it verifies the sender against the peer's known public key, rejecting messages from unverified peers; and it gates address updates behind trade.isDepositRequested(), preventing overwrites before the multisig wallet is created.
Attack Analysis
No on-chain attack transaction has been identified for this incident. RetoSwap operates entirely over Tor with off-chain message handling, so the critical actions occur outside any public ledger. The following reconstruction is based on the publicly available patch and official communications.
-
Step 1: The attacker joined an existing trade as either a buyer or a seller.
-
Step 2: The attacker sent a forged, out-of-order ACK message appearing to come from the arbitrator, carrying an attacker-controlled
.onionaddress as thesenderNodeAddress. -
Step 3: The victim's client accepted the message and overwrote the arbitrator's stored address without verifying the sender against the arbitrator's known public key.
-
Step 4: All subsequent communication intended for the arbitrator, including multisig wallet creation, was routed to the attacker, who obtained the third multisig key.
-
Step 5: Once the buyer and seller deposited funds into the compromised multisig wallet, the attacker stole the wallet's entire contents. The total profit amounted to approximately 7,000
XMR(~$2.7M).
Conclusion
The incident was not a cryptographic failure but a protocol-level authentication flaw: messages were validated as well-formed, but the sender was not cryptographically bound to a known public key before address updates were applied. As a result, the client treated an unverified senderNodeAddress from a forged ACK message as the arbitrator's new contact point before the multisig wallet was created, allowing the attacker to hijack the arbitrator role.
The key lessons are: (1) any message that updates peer identity must be cryptographically verified against the peer's known public key before the update is applied, and (2) identity-critical state such as counterparty addresses should be immutable once the security-sensitive phase (e.g., multisig wallet creation) has begun.
References
About BlockSec
BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.
BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.
-
Official website: https://blocksec.com/
-
Official Twitter account: https://twitter.com/BlockSecTeam
-
🔗 Phalcon Compliance
