Between 24 and 26 October 2026, a bug in the XCM executor on Polkadot Asset Hub was used to reduce the recorded issuance of dotUSD without changing underlying account balances. The recorded issuance is expected to equal the sum of all account balances. By reducing the recorded issuance without changing any account’s balance, the attacker broke this assumption within the protocol.
This discrepancy affected pricing in the Hub’s DOT/dotUSD pool on the decentralised exchange and enabled trades at an artificial exchange rate. The estimated loss was approximately $1.381 million in DOT value. At the time of the attack, the Polkadot Treasury was the only liquidity provider in the pool. No users lost any funds.
The available on-chain evidence has not established that the attacker who exploited the XCM vulnerability also profited from the subsequent arbitrage. Furthermore, the bug did not remove dotUSD from account balances, but the understated recorded issuance restricted redemption capacity pending a correction.
What happened
XCM programs are meant to be transactional. That is, when a program fails, none of the state changes from that program are applied. There was a bug present that did not follow this behavior in certain circumstances.
The issue was first reported to Parity through its Bug Bounty programme in June 2026 and subsequently fixed in the codebase through PR#11910. At the time, it was classified as medium severity, based on the potential impact understood then. However, this assessment did not account for the interactions with dotUSD, which had not yet launched, or the potential implications for OpenGov.
Following the incident, the vulnerability was re-classified as critical. Although the code fix had been available since June, it missed the stable-2606 release cut-off, was not included in the affected production runtimes and was subsequently incorporated into the stable-2609 release.
On 20 October, Parity became aware of a public comment on the Polkadot forum referencing PR#11910, which contained a fix for a vulnerability. The comment was published by the same researcher who had reported the issue through Parity’s Bug Bounty programme in June. This public disclosure breached the programme’s terms and conditions, which are published on Parity’s website and were known to the reporter. The same reporter deleted the comment a few hours after we raised this infraction under the program terms. Parity believes the comment may have provided attackers with sufficient context to identify and exploit the vulnerability through other vectors in the days that followed.
An attacker crafted a program with the WithdrawAsset instruction that correctly reverted account debits when the program encountered an error, but persisted the corresponding change to the recorded total supply. Repeating this sequence reduced reported dotUSD supply while the balances held by accounts remained unchanged.
The messages arrived from Ethereum through Snowbridge, but the underlying bug was in the XCM executor, not Snowbridge. We also reproduced the behaviour without using the bridge.
The Hub’s decentralised exchange used the minimum of the pool’s balance and the asset’s recorded supply to cap the amount of dotUSD treated as available in the pool. Under normal circumstances, the holdings of a single account should always be less than or equal to the total supply of an asset. With that assumption broken, once reported supply fell below the pool’s actual balance, its pricing became distorted.
That created an arbitrage opportunity to swap dotUSD for DOT at an artificial rate. Importantly, dotUSD remained fully backed throughout the incident, and the Peg Stability Module (PSM) continued to support minting and redemption at a fixed 1:1 ratio with USDT. The Peg Stability Module (PSM) guarantees a 1:1 conversion ratio between dotUSD and USDT, meaning arbitrageurs could exploit the price difference between the PSM and the Hub’s pool.
Response and remediation
On 24 October, ecosystem partners alerted us to suspicious activity and within hours we investigated and independently reproduced the issue. At the same time, Snowfork halted its own consensus relayers, which effectively delayed further messages from the attacker. This temporarily stopped the attack.
Runtime 2.5.1, containing the XCM fix, was proposed through OpenGov on 24 October.
On 26 October, the attacker was able to run its own consensus relayer and to continue its attack. This was ~6h before the runtime upgrade was applied on-chain. After the runtime upgrade was applied on-chain, we executed a transaction to rescue the remaining liquidity in the pool. This left the DOT/dotUSD pool with minimal liquidity.
Runtime 2.5.2 was approved and enacted through OpenGov on October 30. The upgrade corrected dotUSD’s recorded supply using existing account balances, without changing individual balances. This also fixed a weight issue with Snowbridge, which we knew about when preparing 2.5.1, but we attributed it to the XCM fix. We accepted the risk of stalling Snowbridge given the fix’s importance.
The recovered dotUSD was returned to the Treasury.
What we learned and what we will change
The incident highlights areas where Parity’s security and release processes need to improve. Although the vulnerability was identified and a fix merged in June, that fix had not reached the affected production runtimes. The potential impact also changed as new functionality was introduced, reinforcing the need to reassess security findings as systems evolve.
We are focusing our improvements on three areas:
- Detection
We will strengthen how we assess security findings, including how vulnerabilities might interact with new or existing functionality. This includes more comprehensive testing of XCM failure scenarios and their effects within the system. To detect vulnerabilities prior to deployment, we leverage an automated agentic framework designed to analyze pull requests and existing codebases. We are actively refining this testing tooling to uncover potential exploits earlier in our development cycle.
- Speed
We are improving how security fixes move from deployment into production. This means simplifying release and backport processes, strengthening checks across release versions, and verifying that fixes have reached deployed runtimes.
- Monitoring and response
We are expanding monitoring to identify unusual changes in asset issuance earlier, alongside clearer incident-response procedures to support faster and more effective containment. We have also begun reassessing the existing security reports to determine whether their potential impact on dotUSD warrants a change in severity classification.
We continually review security developments within and beyond the Polkadot ecosystem, including emerging risks from increasingly sophisticated AI-assisted attacks. We were already working to strengthen our security processes, but this incident exposed weaknesses before those improvements were in place.
The incident had real consequences for the Polkadot Treasury, and we take those consequences seriously. Now, our priority is to accelerate practical improvements that strengthen prevention, detection and response times.