Qubic's Wallet Drain Traces Back to Predictable Randomness
Qubic halted its layer-1 chain after an attacker drained 1,404 wallets in 104 minutes. The seeds behind those wallets came from a generator built for animation timers and game loops, and the
TL;DR
- Qubic is a layer-1 blockchain that runs fee-free transactions and smart contracts on a consensus mechanism called Useful Proof of Work, which redirects mining energy into training artificial intelligence models.
- Between 23:42 UTC on 17 October and 01:26 UTC on 18 October 2026, an attacker drained 1,404 wallets of roughly 2.94 trillion QU, valued at about USD 1.4 million.
- The wallets fell because their recovery seeds came from a generator with insufficient randomness. The project states the fault sat in its wallet software and that the chain protocol itself was not compromised.
- Affected seeds were created in any browser on an iPhone or iPad, in Safari on a Mac until 18 October 2026, or in the Qubic iOS app before July 2025.
- Qubic halted the chain at tick 85,371,949; 87.1 percent of the drained funds stayed on the network and froze in place, and exchange MEXC froze the account that received the other 12.9 percent within about an hour.
- Web wallet version 4.26.4, dated 18 October, replaced JavaScript's Math.random() in seed creation with crypto.getRandomValues(). That fixes new seeds, and it leaves every seed already created in the old code as it was.
The 104-minute window and the wallets inside it
The attack ran for 104 minutes. Qubic's own statement puts the first drain at 23:42 UTC on 17 October and the last at 01:26 UTC on 18 October, and the count it published is 1,404 wallets holding roughly 2.94 trillion QU. Cointelegraph reports the haul at about USD 1.4 million.
A rate of roughly thirteen wallets a minute is the detail worth sitting with. As Netics reads it, once a seed can be derived, the work per wallet collapses to a computation. Wallet count then measures the size of the vulnerable population.
Qubic is a layer-1 chain that carries transactions and smart contracts without fees, built on a consensus design called Useful Proof of Work that repurposes mining energy for AI training workloads. Qubic halted the network at tick 85,371,949.
A seed generator built for animation timers
Qubic's account of the cause is one sentence long and it is the whole story: seeds were generated with insufficient randomness. crypto.news reports that the fix in web wallet version 4.26.4 replaced JavaScript's Math.random() in the seed-creation routines with crypto.getRandomValues().
Those two calls look interchangeable in a code review, and their guarantees differ. Math.random() is built for convenience: it produces a number that looks scattered, quickly, and it is specified without a promise of unpredictability. MDN's JavaScript documentation warns that it is not cryptographically secure and should not be used for anything related to security. crypto.getRandomValues() is built for unpredictability. It draws from the platform's cryptographic generator.
The distinction is old and it keeps costing money. crypto.news ties this incident to a class of failure researchers call Milk Sad, a faulty key-generation process that lets an attacker predict private keys, and Cointelegraph places it in a line that runs through Coldcard's July disclosure of wallets weakened by a firmware bug and, in 2023, Trust Wallet's browser extension and the Libbitcoin Explorer tool. Weak-seed failures form a recurring class, and Qubic is the latest case in it.
The three environments Qubic named
Qubic listed the affected seeds by where they were created: any browser on an iPhone or iPad, Safari on a Mac until 18 October 2026, and the Qubic iOS app before July 2025. That list is more specific than most incident notices and it says something about how the vulnerability behaved.
If the defect were purely in one function, every environment would be equally exposed and the list would be unnecessary. The list implies a dependency on the platform underneath: the same call may have produced output of different quality depending on the engine that implemented it, and every entry on the list is an Apple platform. This reading is Netics analysis, and no source confirms it. Whether the underlying weakness came from the generator's seeding on those platforms or from the wallet's own use of it, the practical lesson holds. A key generator inherits the entropy of the runtime it runs in, and a browser is the runtime with the least control over that.
For a user, this is the uncomfortable part: the notice does not say which seeds are safe. Consulting the release notes tells you that new seeds are generated correctly. Nothing in the published material so far establishes that seeds created in the old code became safe once the code changed, because a seed is stored data and a code change does not rewrite it. Rotation is the only remedy that does not depend on an assumption.
What a validator halt can and cannot undo
Qubic stopped the chain, 87.1 percent of the stolen tokens stayed where they were and froze, and MEXC froze the account holding the remaining 12.9 percent in about an hour. That is an unusually complete containment for a crypto incident, and it is worth being precise about why it worked.
It worked because the asset never became bearer cash. Theft on a chain is a state change that the network agrees on, so a coordinated halt converts a completed theft into a pending one, and a centralised exchange converts an off-chain exit into a frozen account. Both moves need something that a bearer asset does not have: an authority that can act after the fact. Qubic has a way to halt its chain, and MEXC was able to freeze the receiving account.
The trade-off is on the record too. A chain that can be halted to protect funds can be halted for reasons its holders do not endorse, and the recovery decision now sits with a vote of the Computors. Qubic says a full technical report follows once a recovery plan is settled. Anyone treating this containment as a property of the asset class should read that report before generalising it.
What to check before you trust a key generator
The useful question for anyone who ships software that creates keys, seeds or recovery phrases concerns three things: which function produces the value, in which runtime it runs, and whether the answer stays unpredictable to someone who can read the code.
Four checks catch this class of bug before an incident report does:
- Name the API in the code review. A seed that comes from Math.random(), a language's default shuffle, a timestamp, or a hash of the device name is predictable by construction, whatever entropy the surrounding system claims to have.
- Check the source on every platform. The same call can behave differently across browser engines and OS versions, which is exactly what Qubic's three-environment list describes. Confirm that crypto.getRandomValues() is the source on each target runtime. A distribution test cannot prove that a generator is unpredictable: Math.random() can pass one while staying predictable to anyone who models its internal state.
- Treat a generator fix as a rotation event. Patching the code protects future seeds. It says nothing about the keys already written down, exported or stored, and those are the ones an attacker can work on at leisure.
- Write down the blast radius before the incident. Qubic could contain 87.1 percent because a halt was available and an exchange answered in an hour. Most systems do not, which makes early detection the only containment they own.
For teams in France and Morocco building products on top of key material, the same four checks map onto a procurement question that is easy to ask a supplier: which API generates our keys, on which runtimes, and how do we know the output is not reproducible. A vendor that cannot answer that in writing is asking you to take on the entropy risk without a description of it. We build and review exactly that kind of boundary in our security work, and the first output of the exercise is usually the answer to a question nobody had asked before.
Sources
Source: Qubic freezes chain after attacker drains 1.4K wallets with weak seeds — Cointelegraph, by Felix Ng, published 19 October 2026, retrieved 2026-10-19 (the halt at tick 85,371,949, the USD 1.4 million figure and more than 1,400 accounts, the affected seed environments across iPhone and iPad browsers, Mac Safari and the Qubic iOS app before July 2025, 2.94 trillion QU, the 87.1 percent frozen on chain and the 12.9 percent sent to MEXC with the account frozen within about an hour, Coldcard in July and Trust Wallet's browser extension and Libbitcoin Explorer in 2023, the Math.random() to crypto.getRandomValues() change in web wallet version 4.26.4, the recovery vote by the Computors and the pending technical report, and Qubic's Useful Proof of Work design).
Source: Qubic hack leaves USD 1.4 million in stolen tokens frozen — crypto.news, 18 October 2026, retrieved 2026-10-19 (the core team's 18 October statement, insufficient randomness in recovery seeds leaving private keys vulnerable to discovery, reconstruction of private keys without the recovery phrase, the fault sitting in wallet software with the protocol uncompromised, the fix in web wallet version 4.26.4 dated 18 October and its cryptographically secure seed generation, the replacement of Math.random() in seed creation with crypto.getRandomValues(), MDN's warning that Math.random() is not cryptographically secure, the Milk Sad class of faulty key generation, and the advice to file police or cybercrime reports with the wallet ID and transaction link).
Source: qubic/wallet release notes, version 4.26.4 — Qubic, GitHub repository, release dated 18 October 2026, captured 2026-10-19 (the version number and date, and the fix line 'use cryptographically secure seed generation'), with the project's network explorer at explorer.qubic.org/network read in the same session.
Image credits: the release notes capture comes from the qubic/wallet repository on GitHub, the explorer capture from explorer.qubic.org/network, and the two diagrams are Netics editorial work. More analysis is published on neticslabs.com.