Aptos nearly broke from a $3,000 server. The code promise had a hole.
Move sells safety at the language level, but Hexens found the boring failure mode: stale VM state made the safety model lie.
CryptoVibe Desk · aptos · move · security
- →Hexens disclosed a patched Aptos Move VM bug reported on February 25, with no funds lost before public disclosure.
- →The issue matters because Move permissions live as on-chain resources, so type confusion could hit bridges, stablecoins, and DeFi controls.
- →Watch Aptos's next VM audit trail, because the patch is less important than proving this cache class is gone.
- Move VM → The Move virtual machine is the software that runs Move smart contracts on chains like Aptos.
- type confusion → Type confusion happens when software treats one kind of data as another kind and applies the wrong rules.
- TVL → TVL means the amount of crypto deposited in apps or protocols at a given time.
- on-chain resource → An on-chain resource is a stored object that represents ownership, permission, or state inside a blockchain.
Aptos patched this in February. Hexens disclosed the bug on July 4. Its CTO, Vahe Karapetyan, reported it through Aptos's bug bounty program on February 25. The bug sat in the Aptos Move VM. Aptos fixed it within hours of formal notice. No funds were lost.
The thesis is simple. Move's safety promise only works if the machine running it keeps its facts fresh. A stale VM cache made that promise break.
The scary part is not patch time. The scary part is the cost model. CoinDesk reported that Hexens simulated the exploit about 20 times under mainnet-like conditions. It worked 17 or 18 times. The setup cost about $3,000 and needed no validator access.
At the contract level, this cuts through Move's pitch. Move is supposed to make asset and permission types hard to fake. A stale-cache type-confusion bug means the VM can remember the wrong thing. Then it executes against bad assumptions. This is a cache invalidation problem, not a governance problem.
If you're building on Aptos, your bag was not just app risk. It was execution risk. Move stores permissions as on-chain resources, including mint rights, bridge controls, and lending admin roles. If the VM misreads those resources, every protocol trusting them inherits the mistake.
Hexens researchers estimated the unpatched bug could have put up to $70 billion in broader crypto infrastructure at risk, according to CoinDesk. Grego AI estimated about $250 million in Aptos-native TVL was directly exposed. Those are researcher estimates, not audited loss numbers. Aptos has not confirmed those figures.
Aptos disputes the practical severity. The team called real-world exploitability extremely low, according to the same report. That clashes with Hexens' roughly 90% simulation success rate. It also clashes with Mudit Gupta's independent proof-of-concept validation. The gap is probably live-mainnet constraints versus controlled testing. Still, Gupta said the conditions seemed like mainnet.
The Sui question stays open. Sui also uses Move, but this disclosure does not prove Sui shares the same VM path. Treat that as unknown until someone shows the code.
The code did what the safety story said, until the VM cache made it lie. Aptos handled the report fast, which matters. But the lesson is bigger than one chain. Type safety is not magic. It is only as strong as the machine executing it.
Aptos Labs' low-exploitability claim is weak without the VM patch diff and cache-invalidation tests. Hexens says the exploit worked roughly 90% of the time in simulation, and that's the only number that matters until Aptos shows otherwise.
Before August 15, watch whether Aptos publishes a technical post-mortem with reproducible tests for stale-cache type confusion and at least one independent reviewer name.
Primary links and supporting reads used by the desk for this story.
Forward this.
