A $3,000 server nearly unlocked $70 billion in Aptos assets

iEXExchanger
A $3,000 server nearly unlocked $70 billion in Aptos assets

Hexens found a critical type-confusion flaw in Aptos's Move VM: a $3,000 attack with near-90% success could have seized Wormhole, LayerZero, and USDC minting controls. Systemic risk: $70 billion. Patched in February.

Here is what the numbers look like: a $3,000 rented server, a near-90% success rate, and potential access to infrastructure carrying $70 billion in assets. That is what security firm Hexens documented in February 2026 and made public on July 4, describing a critical flaw it found in the Aptos blockchain.

The bug lived inside the Move virtual machine — the execution layer that runs smart contracts on Aptos. Hexens called it a stale-cache bug: faulty caching caused the VM to confuse data types, letting attacker-controlled code treat another contract's storage as its own. The researchers compared its severity to an Ethereum bug that allows arbitrary code to write directly into any contract's storage.

The list of reachable targets makes the stakes concrete. Circle's Cross-Chain Transfer Protocol for USDC — which controls minting rights — was accessible. So were the administrative keys for the LayerZero and Wormhole bridges, liquid-staking vaults, and the deposit-crediting pathways at major centralized exchanges. Aptos-native TVL stood at roughly $250 million at the time; counting bridge-connected networks and cross-chain flows, Hexens put the broader systemic exposure at $70 billion.

The attack cost was remarkably low. Hexens ran the simulation on a $3,000 server replicating about one-third of the Aptos validator network. Seventeen or eighteen out of roughly twenty runs succeeded — close to 90%. No special permissions or insider access required.

The firm reported the flaw through emergency channels on February 25. A patch hit the public repository by February 27. No funds were lost — the vulnerability was closed before any attacker could reach it.

The four-month gap between fix and disclosure is standard responsible-disclosure practice: full technical details stay private until the patch is confirmed stable across the network.

For Aptos, the story is uncomfortable even with a clean outcome. The network's security pitch centers on Move, a language built specifically to make whole classes of asset-management bugs structurally impossible. A cache-level flaw in the VM layer hits the foundation, not a user's contract. Sui, Movement, and other Move-based networks run different implementations of the same VM architecture — whether similar caching logic exists there is now an open question for security researchers across the industry.

Questions and answers

Frequently asked questions about this article

What is a stale-cache bug in the Move VM?

The Move VM caches resource type information to speed up transaction processing. Because of the bug, this cache was not properly invalidated when state changed, so the VM kept using stale type data. Attacker code could exploit this to masquerade as a different resource type and claim permissions it was not supposed to have — including stablecoin minting rights and bridge administrative controls.

Did anyone lose money because of this vulnerability?

No. Hexens reported the vulnerability on February 25 through emergency security channels, and the patch was deployed by February 27. Until the public disclosure on July 4, only the Aptos and Hexens teams knew about the bug. No real-world attacks were recorded.

Why is the systemic risk $70 billion if Aptos TVL was only $250 million?

The vulnerability affected not just assets inside Aptos but the administrative keys controlling bridge protocols like LayerZero and Wormhole that route assets across many blockchains. It also reached USDC's CCTP, which can mint the stablecoin on any connected network. The combined flow through those channels accounts for tens of billions of dollars, producing the $70 billion systemic exposure estimate.

Does this mean Move networks like Sui and Movement are also vulnerable?

Not necessarily — each Move network runs its own VM implementation. The specific caching logic in Sui, Movement, and Aptos may differ. But the fact that the bug was found at the VM cache layer rather than in a user contract raises ecosystem-wide questions. Security researchers are already examining similar patterns across other implementations.