The $11.5M Forged Transfer in the Verus-Ethereum Bridge Hack
Incident Overview
The $11.5M Forged Transfer in the Verus-Ethereum Bridge Hack
Incident Overview
On May 17, 2026, an attacker drained $11.5M from the Verus-Ethereum Bridge with a single forged cross-chain import payload that passed verification and unlocked assets on Ethereum.
Background
The Verus-Ethereum Bridge connects the Verus blockchain to Ethereum. It lets users move ETH and ERC-20 tokens in both directions by locking value on the source chain and releasing equivalent value on the destination chain.
Bridges of this type process two main operations. Exports lock tokens on one side and generate a proof or event that the other side can import. Imports verify that proof and mint or release tokens. The verification step sits at the center of security. Any flaw there turns the bridge into an unguarded vault.
The Verus-Ethereum Bridge uses a structured import payload called a cross-chain event, or CCE. This payload carries the source transaction hash, sender address, destination address, token type, and amount. A dedicated function named checkCCEValues inspects these fields before the contract proceeds to asset release. The function confirms signatures from notaries, checks for replay, and performs basic sanity tests. One test was absent. The code never confirmed that the amount listed in the payload matched an actual locked amount on the source chain.
Without that link, a carefully assembled payload could claim any quantity of tokens. The contract would treat the claim as legitimate and transfer assets from its reserve. This design choice existed in the deployed bytecode and had survived initial development because the team assumed source-chain proofs would always carry truthful amounts. That assumption proved incorrect once an adversary supplied the data directly.
Turning Micro Pennies into Millions via Missing Validation
The $11.5M drain of the Verus-Ethereum Bridge was not caused by an ECDSA bypass, a compromised notary key, or signature forgery. The signatures used in the attack were 100% authentic. Instead, the incident represents a classic case of missing input validation, where a cryptographically secure envelope was manipulated to deliver a fraudulent financial instruction.
Rather than fabricating a cross-chain transfer from scratch, the attacker initiated a genuine outbound transaction on the Verus blockchain with a near-zero asset amount (~$0.01). Because the transaction was legitimate on the source chain, Verus bridge notaries processed it normally, generating a valid state proof and authentic notary signatures for the Cross-Chain Event (CCE) payload.
The critical breach occurred when constructing the final import payload for Ethereum. Exploiting a structural vulnerability in how the payload components were bound together, the attacker took the validly signed CCE but injected vastly inflated token amounts and a controlled destination address while retaining the genuine cryptographic proof.
When the attacker submitted this altered payload to the bridge’s import function on Ethereum, execution entered checkCCEValues. The function was designed under the flawed assumption that any payload carrying valid signatures must inherently contain honest data. It focused entirely on cryptographic authenticity while completely failing to perform economic input-output validation. Because the cryptographic components were real, all checks passed, and the contract blindly honored the inflated financial fields.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract VerusBridgeVulnerable {
struct CCE {
bytes32 txHash;
bytes signatures;
uint256 sourceInputAmount; // The actual small amount locked on Verus (e.g., $0.01)
uint256 destinationAmount; // The inflated amount claimed on Ethereum (e.g., $11.5M)
}
mapping(bytes32 => bool) public replayed;
function checkCCEValues(CCE memory cce) internal view {
// STEP 1: Cryptographic check passes because signatures are 100% real
require(validNotarySignatures(cce.signatures), "Bad sig");
// STEP 2: Replay protection passes because it's a fresh transaction
require(!replayed[cce.txHash], "Already used");
// ❌ CRITICAL VULNERABILITY:
// Missing economic binding check between source chain input and destination payout.
// MISSING: require(cce.sourceInputAmount == cce.destinationAmount, "Value mismatch");
}
function validNotarySignatures(bytes memory sigs) internal pure returns (bool) {
return true; // Validates authentic notary signatures
}
}
By omitting a single equality check between the actual value locked on the source chain and the value claimed on the destination chain (sourceInputAmount == destinationAmount), the bridge allowed fiction to become fact.
Control passed directly to the asset release logic, which swiftly drained 1,625 ETH, 103.57 tBTC, and approximately 147K USDC from the bridge reserves into the attacker’s hands.
Impacted Assets and Follow‑Up Effects
The exploit resulted in a total loss of approximately $11.5M, directly draining 1,625 ETH, 103.57 tBTC, and roughly 147K USDC from the bridge’s Ethereum reserve contracts without impacting external user deposits. Within hours of the attack, the exploiter routed these assets through DEX aggregators, consolidating the entire loot into 5,402 ETH inside the drainer wallet 0x65Cb8b128Bf6e690761044CCECA422bb239C25F9.
Because the Verus-Ethereum Bridge functions as a standalone transfer rail rather than a lending platform, the ecosystem fallout remained contained. No connected DeFi protocols recorded bad debt, and liquidity pools experienced no cascading liquidations or forced unwinds, despite brief price pressure on tBTC and bridge-reliant Verus tokens.
Following external alerts from security firms, bridge operations were paused to prevent further exploitation. The Verus team quickly acknowledged the incident, clarifying the logical flaw within checkCCEValues to the community.
Moving forward, security researchers note that the fix requires roughly ten lines of Solidity code to enforce strict input-output equality, an update that can be deployed efficiently via the bridge’s straightforward upgrade path.
The Key Lesson Why Every Field Must Be Verified
Bridge builders must treat every field in a cross-chain payload as attacker-controlled. In this incident, the source amount arrived from an untrusted payload but received no equality check against the actual locked amount on Verus. One missing comparison allowed the bridge to release $11.5 million. Developers should enforce a strict input-output equality check before any assets are transferred from reserves. Without it, bridges remain vulnerable to a trivial bypass that requires neither private keys nor forged signatures.
메타데이터
- post_id
- 5c716cfb77ae
- slug
- the-11-5m-forged-transfer-in-the-verus-ethereum-bridge-hack-5c716cfb77ae
- url
- https://blog.onesavie.com/the-11-5m-forged-transfer-in-the-verus-ethereum-bridge-hack-5c716cfb77ae
- canonical_url
- https://blog.onesavie.com/the-11-5m-forged-transfer-in-the-verus-ethereum-bridge-hack-5c716cfb77ae
- author_url
- https://medium.com/@Alice_Hsu
- status
- ok
- fetched_at
- 2026-07-17 18:06:46