Hack Database

Polkadot: A Bug Fix From June Missed the Release, and the Network's Treasury Lost $1.38M

A researcher reported a Polkadot bug in June and a fix was written, but it never shipped. In October the Treasury lost about $1.38M. No user lost money.

Polkadot, and Parity, the company that builds most of its software.

Key numbers

  • ~$1.38M

    Lost by Treasury

  • None

    User funds lost

  • June to Oct 26

    Fix written, not shipped

  • Unidentified

    Attacker

A bug report arrived at Parity Technologies in June 2026. Parity is the company that builds most of the software behind Polkadot, a network of linked blockchains. The report went through Parity's bug bounty programme, the scheme in which outsiders are paid to find flaws and tell the company privately. Parity rated the bug medium severity. A fix was written and merged into the code, listed as PR#11910. Then the fix missed the cut-off for the next software release, known as stable-2606, and so it never reached the live network.

On 24 October, ecosystem partners told Parity that something odd was happening on Polkadot's Asset Hub. The cost of the missing fix was about to land on an unlikely victim: the Polkadot Treasury, the network's own community-owned pot of money.

The number

Parity's post-mortem, published on the Polkadot forum on 2 November 2026 by Parity's Bastian Köcher, puts the loss at about $1.381 million, counted in the value of DOT, Polkadot's main coin. The Treasury is a shared fund, a bit like a town's budget, spent on projects when DOT holders vote for it. It was the only liquidity provider in the pool that was hit. Parity says no users lost any funds.

That sentence needs a careful reading. The Treasury lost money. Nobody holding the affected stablecoin lost any. The Defiant and TechFlow, two crypto news outlets, reported the same figure.

How the trick worked

Three pieces of vocabulary matter here. A stablecoin is a digital dollar: a coin meant to stay worth one dollar. This one, dotUSD, lives on Asset Hub, a Polkadot chain that handles tokens. Parity says it stayed fully backed, and that a Peg Stability Module, a mechanism that swaps it for the dollar-linked coin USDT at a fixed 1 to 1, kept working throughout. A liquidity pool is a shared pile of two coins that lets people swap one for the other automatically, like a currency kiosk with no staff. The prices it quotes come from the balance of the pile, and whoever puts coins in is a liquidity provider. Here the pile held DOT and dotUSD, and the Treasury was the only one who had filled it.

XCM, short for Cross-Consensus Messaging, is Polkadot's messaging language. It lets one chain send another a short program, such as "take these coins from this account and move them there". XCM programs are meant to be all or nothing: if a program fails halfway, every change it made should be undone, as with a bank transfer that either completes or does not happen.

The bug, according to Parity, broke that promise in one place. An attacker built a program around a withdrawal instruction called WithdrawAsset and made it fail on purpose. The failure undid the change to the account balances but kept the change to the recorded total supply of dotUSD. Run it again and again and the official count of dotUSD in existence kept shrinking while every account still held the same amount.

That mattered because of how the Hub's exchange priced the pool. It treated the dotUSD available for trading as the smaller of two numbers: what the pool actually held, and the recorded total supply. Once the recorded supply fell below the pool's real holdings, the pool misjudged what its dotUSD was worth and quoted prices that no longer matched the market. Anyone swapping against it could pocket the difference, a trade known as arbitrage. Because the Treasury was the only provider, its DOT was what flowed out.

Not Snowbridge

The attack messages reached Asset Hub from Ethereum through Snowbridge, a bridge between Ethereum and Polkadot, which pointed some early attention at the bridge. Parity is clear that the flaw was in the XCM executor, the part of Polkadot's code that runs these messages, and says it also reproduced the problem without any bridge. Snowfork, the team behind Snowbridge, halted its consensus relayers on 24 October. Relayers are the servers that carry messages across the bridge, and halting them briefly stopped the attack.

Six days of scramble

Parity says it reproduced the problem within hours of the alert on 24 October. A fix, Runtime 2.5.1, went to a Polkadot governance vote known as OpenGov, as referendum 1960. Polkadot cannot be patched by a company pushing an update. Changes to the network's core software must be approved by a vote of DOT holders, which takes time.

On 26 October the attacker ran a relayer of its own and restarted the attack, about six hours before 2.5.1 was applied on chain. Once the upgrade landed, Parity ran a transaction to rescue what was left in the pool, leaving it with minimal liquidity. The recovered dotUSD went back to the Treasury. On 30 October a second upgrade, Runtime 2.5.2 (referendum 1961), corrected dotUSD's recorded supply using the existing account balances, without changing anyone's balance. That release also fixed a separate Snowbridge problem. Parity says it knew of that problem while preparing 2.5.1 but attributed it to the XCM fix, and it "accepted the risk of stalling Snowbridge given the fix's importance". The bug was afterwards reclassified as critical, and the fix is in stable-2609.

Who profited, and the researcher's comment

The post-mortem does not say who the attacker was. Parity also says the on-chain evidence has not shown that the person who used the bug also profited from the arbitrage. So the $1.38 million is the Treasury's loss, not a sum proven to have ended up with one person. Parity does not say who else traded against the broken pool.

The second dispute is about the original reporter. Parity says that on 20 October, four days before the attack, the same researcher who reported the bug in June published a public forum comment that referred to PR#11910. Parity says this broke the bounty programme's published terms, raised it with the researcher shortly afterwards, and the comment was deleted a few hours later. Parity believes it "may have provided attackers with sufficient context to identify and exploit the vulnerability". That is Parity's account and its belief. The researcher is not named in the post-mortem, the forum thread had no replies when read on 5 November, and no public reply from the researcher was found.

Parity also concedes that its June rating missed context. The medium score did not account for dotUSD, which had not yet launched, or for what OpenGov implies for slow fixes.

The aftermath

Parity lists three areas for change. On detection, it plans better checks of how a bug interacts with new features such as dotUSD, more testing of what happens when XCM programs fail, and an automated framework for scanning code changes. On speed, it wants simpler release and backport processes and a check that every fix actually reaches the deployed network. On monitoring, it plans earlier alerts on unusual changes in how many coins exist, clearer incident procedures, and a fresh look at older security reports for dotUSD impact. Parity says the incident "exposed weaknesses before those improvements were in place".

The Treasury's loss stands at about $1.381 million, and the recovered dotUSD has been returned to it.

What this teaches

  • A fix that is merged is not a fix that is live. The June patch protected nobody until a release carried it into the network.
  • A bug's severity depends on what else is running. Parity's medium rating predated dotUSD, which turned a supply-count quirk into a pricing flaw.
  • A pool with a single liquidity provider puts all the risk on one party, here the community's own Treasury.
  • Software that can only be changed by a public vote is slow to fix, and a public hint about a patch is a head start for attackers.