Blockchain security firm CertiK has noted that on July 23, 2026, an attacker successfully targeted the Ethereum cross-chain bridge of the Verus Protocol, extracting roughly $7.44 million in assets that included ETH, tBTC, various stablecoins, and MKR. The exploit hinged on a fundamental difference in how Verus and Ethereum processed notarization data.
CertiK added that by embedding malicious duplicate state-root entries within otherwise valid notarizations that were signed by legitimate Verus notaries and then forwarded to Ethereum, the attacker overwrote the trusted state root.
This allowed submission of a forged bridge import proof that authorized large withdrawals, even though the original export involved only a negligible 0.01 VRSC transfer.
A Verus notarization functions as a signed cross-chain checkpoint that sets the reference root used to validate subsequent transaction and export proofs.
It records details such as the system or currency involved, the notarization height, one or more proof roots (including system ID, chain height, state or proof root, block hash, accumulated power, and currency or converter state), a link to the prior notarization, and proposer or node information.
These roots draw from publicly available Verus and Ethereum chain data.
While anyone can propose or relay a candidate notarization, acceptance requires spending the correct notarization-thread UTXO and providing necessary consensus evidence.
Notary signatures form part of the public evidence that can be retrieved and relayed.
The attack unfolded in several stages. First, the attacker poisoned notarizations on the Verus network.
Starting from a genuine notarization, successive transactions spent the previous accepted output while secretly incorporating extra malicious state-root entries.
Verus processed the serialized roots by loading them into a vector and inserting them into a map, effectively overlooking the duplicates in its own view.
Legitimate notary software then validated the initial legitimate roots, after which notaries signed the full raw data—including the ignored malicious entries.
The attacker harvested these signatures via RPC calls and packaged them for use on Ethereum.
On the Ethereum side, the attacker relayed the notarizations through calls to the bridge’s setLatestData function.
During deserialization, the proof roots were processed in a loop that overwrote the state root for every matching system ID entry.
Consequently, the genuine Verus root was replaced by the attacker-controlled value.
With this compromised root in place, the attacker initiated a minimal 0.01 VRSC export request through the Bridge.vETH contract, which the converter and associated pool processed into a batch transfer.
Finally, a crafted submitImports call on Ethereum used a fabricated hashtransfers value matching the desired large drains, along with adjusted input counts and selectively reused proof components.
The remaining elements of the Merkle Mountain Range proof were constructed so that the final root matched the previously injected malicious state root.
The core vulnerability stemmed from inconsistent cross-chain semantics: Verus interpreted the notarization bytes as containing a valid genuine checkpoint, while Ethereum treated the same data as establishing an attacker-controlled one.
Once Ethereum accepted the false root, any export proof derived under it passed verification.
CertiK further explained that an additional shortcoming in the Ethereum bridge contract was the absence of checks confirming that the requested payout amount matched the value actually exported on Verus.
A fabricated hashtransfers field proved sufficient to clear the relevant verification.
After the drain, the attacker converted the stolen assets into approximately 2,778.87 ETH through a relay service and deposited the proceeds into Tornado Cash.
Blockchain security firm CertiK also mentioned that the episode underscores the risks inherent in cross-chain systems where subtle differences in data interpretation between chains can enable significant losses, highlighting the need for stricter consistency checks and amount-validation logic in bridge designs.