MultiversX Says Funds Safe, Attacker Accounts Frozen After Exploit

MultiversX paused block production after an attacker targeted a VM-layer atomicity flaw The co-founder says the incident is contained and the attacker’s accounts have been frozen with exchange help A recovery patch is in shadow-fork testing, with execution expected within one to two days EGLD rebounded from its halt-day lows and trades back around its moving averages MultiversX said the attack which forced it to pause its mainnet is now contained, with the attacker’s accounts identified and frozen through coordination with major exchanges and a recovery patch expected to run within one to two days. The chain remains halted while engineers validate the fix in a shadow fork environment. The underlying fault was an atomicity bug at the virtual machine layer, a flaw that let invalid changes settle onto the ledger before the team stopped block production to contain it. Users were told to sit still: no new transactions, no resubmitting old ones, and no EGLD or ESDT deposits and withdrawals through exchanges or bridges until the all-clear. Update: We have confirmed that a actor attempted to exploit a VM-level atomicity issue. The attempt caused invalid state changes, and network progression remains paused to prevent any further impact. Engineering has prepared a fix and will validate it on a shadow fork.… https://t.co/iyi1aYzkMJ — Multiversᕽ (@MultiversX) September 19, 2026 A credit without a debit: how the atomicity bug forged state Atomicity is one of the load-bearing guarantees in any transaction system. A transaction with several internal steps has to either complete in full or fail in full, with nothing left half-done. When you send tokens, one balance goes down and another goes up in the same indivisible operation. There is no valid state in between. The attacker found a way to break that guarantee at the VM level. By exploiting the atomicity handling, they forced the network to record invalid state changes, the kind of outcome where a credit lands without its matching debit, or a step commits that should have reverted. On a chain that runs parallel processing lanes across shards, a defect this deep is more dangerous than an ordinary bug, because the corrupted state can propagate before anyone isolates it. That is the reason the response was a full stop rather than a quiet patch. Why the team stopped the chain instead of patching it live Stopping block production looks alarming, but here it functioned as a circuit breaker. Halting the chain stops new transactions from stacking on top of records that may already be wrong, and it blocks any repeat attempt using the same method while engineers map which balances and contract entries were touched. The freeze does not reverse anything.