Skip to content
Blockchain Posts

exploit

Aptos patched a Move VM stale-cache bug Hexens says risked ~$70B in cross-chain value

Security firm Hexens disclosed a stale-cache type-confusion in the Aptos Move VM in late February. Aptos patched within days; no funds lost. Coverage went public on July 4.

by 6 min read
exploitprotocolaptoshexensmove

Security firm Hexens disclosed a critical type-confusion vulnerability in the Aptos Move virtual machine — the execution environment for every Aptos smart contract — via emergency channels on February 25, 2026, and Aptos Labs patched it "within days," according to the disclosure timeline made public by CoinDesk on July 4, 2026. No funds were lost. Independent AI security lab Grego AI reproduced Hexens's proof-of-concept and estimated about $250M of Aptos-native TVL was directly at risk, with Hexens's own broader estimate of first-order systemic exposure — bridges, cross-chain messaging, stablecoin admin flows, exchange custodians touching Aptos — reaching ~$70B. The Aptos team disputed the practical exploitability of the bug in real-world conditions.

What Hexens found

Hexens's report characterises the flaw as a stale-cache bug in Move VM resource resolution that produces a type confusion — a state in which the runtime is tricked into treating a resource of one Move type as a different, attacker-chosen type. In a Move-family execution model, that primitive is powerful: resource types encode ownership and storage-slot layout, so type confusion generalises to writing attacker-controlled bytes into storage slots owned by unrelated contract accounts. In effect, the bug converts a limited caller into a wildcard that can rewrite the state of any Move module on the chain, including token admin, bridge admin, and validator-registry accounts.

The Move VM is the same execution model shared across Aptos, Sui and other Move-family chains, though the specific cache implementation implicated is Aptos's; there is no reporting to date of the same bug reaching other Move chains.

The attack simulation

The number that made the story publishable was cost. Per Hexens's methodology as reported:

  • ~$3,000 of commodity server hardware was enough to reproduce enough of the Aptos validator network — Hexens says roughly one-third of the validator set — to demonstrate the exploit at network conditions.
  • ~90% success rate at breaking a core safety property under those simulated conditions.
  • No insider access, no delegated authority, no privileged permissions were required to trigger the type confusion.
  • Grego AI independently verified the proof-of-concept on its own testbed and produced the ~$250M direct-TVL figure.

The reproducibility here is the point: a nation-state adversary is not the threat model. A well-provisioned single researcher is.

Numbers

- Chain                          : Aptos (Move VM)
- Bug class                      : stale-cache → type-confusion
- Emergency disclosure           : 2026-02-25 (Hexens → Aptos)
- Patch deployed                 : within days of disclosure
                                   (no CVE or advisory ID published)
- Public disclosure of the bug   : 2026-07-04 (CoinDesk)
- Attack simulation cost         : ~$3,000 (commodity server)
- Validator share simulated      : ~1/3 of the validator set
- Simulated success rate         : ~90%
- Aptos-native TVL directly at risk : ~$250M (per Grego AI PoC)
- Systemic first-order exposure  : ~$70B (Hexens estimate; bridges,
                                   stablecoin admins, CEX custodians,
                                   cross-chain messaging touching Aptos)
- Funds lost                     : $0

The two exposure figures answer different questions and should not be conflated. The $250M is the on-Aptos TVL Grego AI's PoC could have moved directly. The $70B is Hexens's estimate of assets whose control paths flow through Aptos-hosted accounts one hop away — bridged wrapped assets whose mint/burn authority is an Aptos account, stablecoin freeze/mint controllers, cross-chain messaging relayers using Aptos as a settlement layer.

Skeptical attribution — and Aptos's rebuttal

There is no attacker to attribute here: the bug was reported through Aptos's bug bounty program on Feb 25, patched, and no on-chain exploitation is known.

The material dispute is between the researchers and the vendor over how exploitable the bug was in practice. Hexens and Grego AI's position is that the ~90% success rate under simulation, combined with commodity hardware and no privileged access, describes a realistic threat model — the kind an adversary with far more than $3,000 could weaponise. The Aptos team's counter, as reported, is that its own analysis concluded the bug would have "extremely low exploitability in real-world conditions" — a claim that turns on differences between a simulated one-third validator quorum in a lab and a live, geographically distributed, economically incentivised Aptos mainnet with monitoring and slashing.

Both statements can be simultaneously true. Hexens has demonstrated a reproducible primitive; Aptos has argued that the surrounding operational surface would have caught it. There is no independent live-network test to arbitrate, and the patch means there will not be one.

What to watch

  1. Whether Hexens publishes a full technical write-up. As of the CoinDesk coverage, Hexens's own detailed advisory had not appeared on its research page. A write-up would let other Move-VM implementers (Sui, Movement, and Aptos forks) check whether their own resource-cache paths carry the same class of bug.
  2. Aptos's own post-mortem. No CVE, no GitHub Security Advisory, no changelog entry publicly ties the February patch to this vulnerability class. A dated advisory — even a redacted one — would let auditors of downstream Move contracts reason about which release lines are safe.
  3. Bug-bounty payout disclosure. Aptos runs its program on HackenProof; a public payout size on a bug rated at this severity would establish market pricing for future disclosures on the same primitive.
  4. Downstream Move ecosystem review. Sui, Movement Labs and other Move-family chains do not necessarily share the specific cache implementation, but they share the type-safety guarantees the bug undermines. Whether any of them publish an "us too / not us" statement is the first ecosystem signal.

Context — a bounty finding, not an exploit

This is a whitehat disclosure, not an on-chain incident. The comparable pattern is Numen Cyber's 2022 disclosure of the first critical Aptos Move VM 0-day, patched pre-launch and detailed in Numen's own technical write-up — bug found before the drain, patched by the vendor, followed by an eventual technical publication. The neighbouring pattern in the Move-family ecosystem has been bugs caught only by validators in production — Sui's recurring v1.7x halts, Aleo's early consensus stalls — not by researchers pre-drain. The delta between "caught by researchers, patched, disputed" and "caught by validators, halted, patched" is the industry-wide story worth tracking for Move-family L1s in 2026.

The value of the story is not that $70B moved. It is that a stale-cache bug in a production high-throughput chain was reachable by a $3,000 setup, and that the vendor's assessment of real-world exploitability diverges materially from the researchers'. Both facts should sit in the reader's model of what "type-safe by design" means for Move-family execution.

Sources:

Related stories