MultiversX Says Sept. 19 Attack Is Contained as Hard Fork Takes Shape
MultiversX is preparing a coordinated hard fork from a known-good blockchain checkpoint after an attacker exploited a virtual-machine-level atomicity flaw that produced invalid state changes and forced the network to stop progressing.
The blockchain said in its September 21 incident update that the attack has now been contained, attacker-linked accounts have been identified and frozen in cooperation with major exchanges, and law enforcement has been brought into the investigation.
The update substantially clarifies the recovery path following the VM-level exploit MultiversX confirmed over the weekend.
The incident began on September 19, when MultiversX first disclosed that it was investigating a potential mainnet problem. What initially appeared to be a broadly defined network issue was later confirmed as an attempted exploitation of an atomicity flaw inside the network’s virtual machine.
The attack resulted in invalid state changes. MultiversX then paused network progression to prevent additional activity from building on top of a state that could no longer be assumed to be correct.
The project now says the root cause was an order-of-operations mistake affecting edge cases. A software fix was prepared on the same day as the incident, while validators helped contain the impact.
Before the exploit was confirmed, Coinbase had already reported delays involving EGLD transfers, providing one of the first external signs that MultiversX-dependent infrastructure was experiencing problems.
The recovery procedure has since moved beyond simply patching the vulnerability. MultiversX says validators will coordinate a hard fork beginning from a known-good checkpoint. The process is being rehearsed on Testnet and Devnet before deployment to mainnet, while the relevant code has been made public and remains under testing.
Users are still being told not to submit new transactions or rebroadcast previous ones. MultiversX has also warned against sending or withdrawing EGLD or ESDT assets through exchanges and cross-chain bridges until the recovery process is complete.
Exchanges and bridges are expected to reopen in stages after the network restart.
The Biggest Recovery Question Is What Happens After the Checkpoint
One crucial detail remains unresolved: MultiversX has not yet explained exactly what state will be discarded when the hard fork begins from the selected checkpoint.
Earlier in the incident, the project described its preferred recovery as targeted. The stated aim was to preserve confirmed transaction history and legitimate user state while removing only invalid changes associated with the exploit.
The September 21 update now describes the mechanism more specifically as a coordinated hard fork from a known-good checkpoint, but it does not explain how the two concepts will be combined.
That distinction matters.
If the chosen checkpoint predates legitimate transactions that were finalized before network progression stopped, simply restarting from that state could remove valid activity alongside the attacker-generated changes. MultiversX has not said whether any such transactions exist, whether they would be automatically replayed, manually reconstructed or preserved through another state-migration mechanism.
It has also not published the checkpoint height or timestamp, identified the affected balances or smart contracts, or disclosed the complete set of invalid state changes that the recovery will remove.
Those questions are likely to be central to the full technical incident report MultiversX has promised after recovery.
The issue resembles a broader problem increasingly appearing in blockchain incident response: fixing vulnerable code can be easier than deciding what the blockchain should consider legitimate after an exploit has already modified state.
Osmosis recently confronted a similar governance dilemma when it considered using a software upgrade to seize attacker-controlled assets following the Nomic exploit. The technical circumstances differ, but both cases force validators and developers to draw a line between preserving blockchain history and repairing state created through a vulnerability.
MultiversX Has Not Named the Exchanges That Froze Attacker Accounts
Another unresolved detail concerns the attacker.
MultiversX says the relevant accounts have been identified and frozen with assistance from major exchanges, while specialized law enforcement is involved. However, neither the project nor its co-founder Beniamin Mincu has publicly named the exchanges that froze the attacker-linked accounts.
That should be distinguished from publicly announced EGLD restrictions.
Kraken, for example, has paused EGLD deposits and withdrawals and placed EGLD trading pairs into cancel-only mode during the incident. Upbit has also suspended MultiversX deposits and withdrawals and placed EGLD under a trading-caution designation.
Those measures show that exchanges are actively responding to the network disruption, but they do not establish that Kraken or Upbit are among the unnamed platforms holding or freezing attacker-linked funds.
The difference is important because freezing assets at a centralized exchange can significantly change recovery prospects if an attacker has already moved assets away from the original blockchain.
Other recent attacks have shown the value of rapidly tracing funds across infrastructure providers. In the separate Fetch.ai and NuNet incidents, researchers were able to link two attacks through a common destination wallet, illustrating how on-chain attribution can help exchanges and investigators react before stolen assets disappear through additional layers.
The Hard Fork Is Now a Test of MultiversX’s Credibility, Not Just Its Code
The vulnerability itself is only one part of the problem MultiversX now has to solve.
The harder challenge is proving that the recovered blockchain state is correct.
A protocol bug can be patched. But once invalid execution has changed balances, contract storage or other state, recovery becomes a question of accounting, governance and trust as much as software engineering.
That is particularly sensitive for a blockchain because users normally treat finalized transactions as irreversible. A recovery mechanism that changes previously finalized state may be technically justified after an exploit, but it needs an unusually transparent explanation of what was changed and why.
The good news for MultiversX is that the network was paused before the problem was allowed to continue indefinitely. The team also appears to have moved quickly enough to coordinate with validators, exchanges and law enforcement while testing the recovery before deployment.
But speed should not be the main metric from here.
The stronger test is whether MultiversX can demonstrate that every invalid change associated with the exploit is removed without unintentionally erasing legitimate activity.
This is also why the exact checkpoint matters more than the phrase “hard fork.” A well-defined recovery that restores a demonstrably correct state is very different from a broad rollback that simply rewinds the chain until the exploit disappears.
MultiversX’s earlier commitment to preserve legitimate user state suggests it is aiming for the former. Until the team publishes the implementation details, however, investors cannot yet verify how that promise will be achieved.
The incident also comes only days after the September 10 activation of Supernova, MultiversX’s major network upgrade that reduced block times to roughly 600 milliseconds. The timing will inevitably raise questions, but MultiversX has not linked the atomicity flaw to Supernova, and there is currently no evidence establishing that the upgrade caused the vulnerability.
That makes the promised post-mortem especially important. It will need to explain not only how the order-of-operations flaw worked, but when the vulnerable code entered production, what state it allowed the attacker to create and exactly how the hard fork removes that state.
Until those details arrive, the incident can reasonably be described as contained, but the recovery is not finished.
For MultiversX, restarting block production will be the first visible sign of progress. Restoring confidence will require showing that the chain which comes back online is not merely operational, but that its balances, transaction history and application state can once again be trusted.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.