Public Incident Report

Radix Engine vault-authorisation vulnerability and loss of network liveness, 31 August 2026

1. Executive summary

On 31 August 2026 an attacker exploited a previously undetected vulnerability in the Radix Engine, the execution layer of the Radix network, to withdraw assets from third-party vaults without the owners’ authorisation. The stolen assets were routed off the network through the Hyperlane bridge and sold on external chains.

The vulnerability was not a bridge failure, a validator failure or a compromise of any user’s private keys. It was a defect in how the Radix Engine enforced ownership of vaults when a vault reference was passed into smart-contract code. That defect was introduced during a code tidy-up carried out in June 2023 by RDX Works Limited, the Foundation’s contracted protocol development partner at the time, and was not detected by the subsequent independent security audit conducted by Zellic in August 2024.

Within approximately three hours of the first report, the Foundation, Hyperlane and members of the Radix validator community had shut down the Hyperlane routes and, by taking sufficient validator stake offline, deliberately broken the network’s liveness so that no further transaction could be committed. This stopped any further exploitation. A fix to the Radix Engine and accompanying node software has since been written, independently reviewed and tested by audit firms and other trusted security parties. The matter has been reported to the States of Jersey Police and to UK law enforcement, and the Foundation has supplied extensive forensic evidence.

This report sets out what happened, why, how it was contained, how it has been fixed, and what the Foundation is doing to ensure a safe return to normal operation.

2. Background: audit history of the Radix Engine

The Radix Engine is the component of the Radix node that executes transactions and enforces the ownership and access rules for every asset on the network. Its security history relevant to this incident is as follows.

The Foundation’s assessment, shared by the external forensic team, is that the attacker used AI-assisted code-analysis tooling to locate the vulnerability in the publicly available Radix Engine source code. The exploit was highly targeted and left a minimal footprint, which is consistent with automated discovery followed by a deliberately engineered attack. The wider industry should expect AI tooling to surface latent defects that conventional audits have missed; this is discussed further in Section 9.

3. The vulnerability

3.1 Plain-language description

Every asset on Radix is held in a vault. A vault can only be withdrawn from by the account or component that owns it. The Radix Engine is responsible for enforcing that rule.

The defect allowed a transaction to name any vault on the network by its internal address, pass that address into a purpose-built piece of smart-contract code, and call the vault’s ordinary withdraw function. The engine should have rejected the call because the caller did not own the vault. Because of the defect, the engine treated the reference as if it were a normal, authorised reference and permitted the withdrawal.

3.2 Technical summary

Internal vault addresses supplied in a transaction manifest are classified by the engine as “direct-access” references, intended only for explicitly direct operations such as recall. When such a reference was passed into a package call frame and the package then invoked ordinary methods (get_amount and take) on the vault, the engine permitted those calls to proceed even though take is not a direct-access method and should not have been callable through a direct-access reference. The visibility check that should have blocked the ordinary method call did not recognise the borrowed direct-access origin of the reference, so the withdrawal proceeded, subject only to the resource’s withdrawer role, which is, correctly, set to allow all for ordinary transferable assets on the assumption that vault ownership is enforced by the engine.

In summary: the exploit was carried out entirely by the attacker’s own package acting on the Radix Engine. The Hyperlane package played no part in the exploit mechanism; it was used purely as the destination to which the withdrawn assets were sent. The affected resources and their role configurations were correct. The engine was not enforcing the ownership boundary those configurations relied upon.

3.3 What was not affected

• No user, validator or Foundation private keys were compromised.
• Radix consensus operated correctly throughout, both in validly including the malicious transactions (which were not authorised by the vault owners) and, later, in ceasing to make progress once validator stake was taken offline.
• The Hyperlane bridge, its validators and its message verification operated correctly. Every release on a destination chain matched a legitimately committed burn on Radix; the theft occurred on Radix before the bridge was used.
• No admin, recall or clawback badge was used or abused.

4. Incident timeline

All times are UTC on 31 August 2026 unless stated. Local Jersey time (BST) is one hour ahead.

5. Detection and containment

5.1 Detection

The unauthorised withdrawals were first noticed by members of the Radix community operating validator nodes, who saw bridged assets being drained through the Hyperlane bridge. They escalated immediately to the Radix team, which contacted Foundation leadership. The Foundation established within minutes that the Hyperlane bridge itself was functioning correctly and that the problem lay on the Radix side.

5.2 Shutting down the bridge

The Foundation contacted Hyperlane directly. Hyperlane disabled its Radix validator, relayer and scraper operations and coordinated with its independent validator operators to take their Radix signers offline. In parallel, the Foundation executed a multi-signature transaction to pause the routes at the contract level. Together these steps ensured that no further Radix-originated bridge messages could be delivered.

5.3 Breaking network liveness

Once the investigation established that the root cause was in the Radix Engine rather than in any single application, it was clear that the bridged assets had been targeted simply because they had liquidity on other chains; in principle, any vault on the network was exposed. The Foundation convened an emergency call with key validators and board members and took the decision to stop the network committing transactions.

The Radix network cannot be paused or switched off by any single party, and it was not halted in that sense. Instead, validator node operators voluntarily and in coordination took sufficient stake offline that the remaining validators could no longer reach the majority of stake that consensus requires. Nodes continued to run and to attempt normal operation, but without enough stake participating no further transaction could be committed: liveness was broken while the network itself remained intact. This is the intended behaviour of a proof of stake network, consensus is designed to stop rather than proceed without sufficient stake and it was the code doing exactly what it is programmed to do that allowed the network to be protected. Liveness was lost within approximately three hours of the initial report, and from that point no further transaction has been committed.

The Foundation wishes to record its thanks to the community validators, SEAL 911, Zellic, Hacken and Hyperlane, all of whom responded within minutes and worked through the night.

5.4 Other containment measures

• All Foundation market making on centralised exchanges was stopped and exchanges were asked to pause XRD deposits, withdrawals and trading.
• The malicious package, transaction manifests, receipts, affected vault lists and bridge operator logs were preserved for forensic analysis before any clean up activity.

6. Impact

The attacker withdrew Hyperlane-bridged representations of ETH, WBTC, USDT, USDC, BNB and SOL, together with a small quantity of XRD used to pay transaction fees, from vaults owned by a number of ecosystem packages and accounts, including liquidity pools. The assets that reached destination chains were sold for ETH shortly afterwards. Although the attacker targeted bridged assets for their liquidity on other chains, any package or account holding vaults was at risk.

Because network liveness was broken before the vulnerability could be applied more widely, the Foundation is not aware of any unauthorised withdrawals beyond those identified in the timeline above.

7. Remediation

7.1 The fix

A fix to the Radix Engine was developed within 48 hours of the liveness break. The fix enforces the receiver capability before a method call frame is constructed: an ordinary method call on a vault is now rejected when the caller holds only a direct-access reference, while intentional direct access operations continue to work as designed. Defence in depth changes ensure that a direct access reference retains that classification across borrows and cannot be used as an ordinary receiver by any call path.

Regression tests have been added at both the unit level (proving the classification defect is closed) and the integration level (proving that an unauthorised take on a third-party vault, with no intent signers, is now rejected). Positive tests confirm that legitimate recall, and normal calls on owned and global objects, are unaffected.

7.2 Node software updates

Applying the fix required a coordinated protocol upgrade of every validator node. Significant additional engineering has been undertaken on the node software to allow the network to be restarted safely from the state at which liveness was lost, to ensure that all nodes apply the corrected engine at the same state version, and to prevent any transaction prepared against the vulnerable engine from being executed after restart.

7.3 Independent verification

The Foundation has not relied on its own testing. The fix and the updated node software have been reviewed and tested by the audit firms engaged during the incident and by other trusted parties. In addition, a number of trusted security parties have independently deployed their own test networks running the patched code and conducted their own adversarial testing against it.

Their collective conclusion is that, while no software can be guaranteed free of defects, no critical security issues were identified in the patched Radix Engine or node software. The Foundation is satisfied that the network can be safely restored on that basis.

8. Law enforcement

The Foundation has reported the incident as a crime to the States of Jersey Police and to UK police through Action Fraud. Both have been supplied with extensive forensic evidence, including the complete ledger of exploit transactions, the malicious package code, the attacker controlled addresses on Radix and on each destination chain, the liquidation trail, and a full technical account of the vulnerability and how it was introduced.

The Foundation will continue to cooperate fully with law enforcement and with any exchange or analytics provider tracing the proceeds. Exchanges that receive or have received funds associated with the attacker-controlled addresses are asked to contact the Foundation.

9. Root cause analysis and lessons learned

9.1 Root cause

The vulnerability was introduced in June 2023 during a routine code tidy up of the Radix Engine. Three individually reasonable behaviours in the call frame reference model combined into an unsafe path. The change was not caught by internal review at the time and was not detected by Zellic’s independent audit in August 2024, despite that audit covering the kernel in which the defect sat.

9.2 Lessons

• Refactoring is a security event. Code tidy ups and refactors of security critical components must be treated with the same rigour as new features: separate reviewers, explicit threat modelling of the reference and capability model, and a dedicated regression suite for authorisation boundaries.
• Audits are necessary but not sufficient. Zellic, a well-regarded firm, audited this code and passed it. Audits sample; they do not prove. The Foundation recommends supplementing audits with continuous automated analysis, including AI-assisted review of the kind the attacker is believed to have used.
• External development must be evidenced. Where development of protocol code is outsourced, the contracting entity must evidence its change control, review and testing processes, and the Foundation, as the commissioning party, must retain independent verification capability rather than relying on the contractor’s assurance.
• RDX Works Limited. RDX Works Limited were informed of the situation and the root cause and have yet to respond.
• Coordinated breaking network liveness capability worked and must be formalised. The liveness of the network was successfully broken through the loss of consensus by voluntary validator action within three hours. The Foundation will work with the validator community to document and rehearse this procedure so that it can be executed faster and with clearer authority in the future.