3-year-old bug triggers $1.3 million drain and forces 10-day blockchain halt

A routine Radix code refactor created a vault flaw that enabled a roughly $1.3 million theft and later forced validators to halt the blockchain.

The Radix Foundation said Sept. 17 that an RDX Works development team introduced the defect during a June 2023 cleanup of the Radix Engine, the software layer that executes transactions and enforces asset ownership across the network. The vulnerability remained undetected for more than three years before an attacker exploited it on Aug. 31.

A community reconstruction of the ledger shows the attacker withdrew about 458,915 USDC, 72,420 USDT, 61.08 ETH, 6.35 wrapped Bitcoin, 536.16 SOL and 32.91 BNB across 26 transactions. The assets were worth roughly $1.26 million using Aug. 31 market prices, and the attackers took another 13,000 XRD from a vault to pay transaction fees. The two stablecoins alone accounted for about $531,335.

The stolen assets were sent through Hyperlane to Ethereum, BNB Chain, and Solana, then sold for ETH, Radix said. Hyperlane itself operated as designed: the attacker had already obtained the assets through the Radix Engine before using the bridge to move them elsewhere. No private keys were compromised.

However, the immediate loss understated the potential exposure. Radix investigators concluded the flaw could have been used against any vault on the network, putting tokens and other assets beyond the bridged holdings targeted by the attacker at risk.

As a result, network validators deliberately took enough stake offline to prevent it from reaching consensus and stopping additional transactions while developers worked on a fix.

Radix audit miss turns maintenance bug into systemic failure

The vulnerability had already survived an independent security review before the attacker found it.

Zellic audited the Radix protocol in 2024, including the engine kernel containing the defect. The review did not detect the authorization flaw, even though the vulnerable code had been introduced during the previous year's refactor.

The bug changed how the engine handled vault references. A transaction could identify another user's vault by its internal address and pass that reference into purpose-built smart-contract code. The engine then allowed ordinary withdrawal functions to be called without properly enforcing the ownership boundary that should have rejected the request.

That gave the attacker access to assets held by user accounts, applications and liquidity pools without obtaining the owners' signatures.

The Foundation said the attacker completed 26 exploit transactions between 16:02 and 16:57 UTC on Aug. 31. Once investigators determined the vulnerability existed in the execution layer rather than a single application, validators coordinated to stop transaction finalization.

The halt lasted more than 10 days. A protocol fix added checks preventing a restricted vault reference from being used for an ordinary withdrawal, and user transactions resumed Sept. 11, according to the community ledger reconstruction.

The incident also produced secondary losses in liquidity pools after the attacker removed bridged assets from one side of trading pairs. The distorted prices allowed another account to extract millions of XRD from affected pools, showing how an execution-layer failure can keep causing economic damage even after the initial assets have left the network.

Radix said it is adding regression tests, strengthening its security review process, and formalizing the emergency procedure validators used to break network liveness.

The Foundation also said future security work must account for increasingly capable AI-assisted code-analysis tools, which it believes may have helped the attacker identify the years-old defect.

For developers and validators, the next challenge is preventing similarly routine maintenance work from silently altering security assumptions that external audits may miss.

That task extends beyond repairing the exploited code. Radix now has to strengthen the review process around changes to authorization logic while restoring confidence among users and liquidity providers whose assets ultimately depend on the engine enforcing those boundaries correctly.