On the night of October 17–18, 2026, an attacker drained 1,404 Qubic wallets. Nothing was wrong with Qubic's consensus or smart contracts. The wallets fell because their seeds could be predicted. This is one of the oldest failures in crypto, and it keeps coming back.

What happened

01:42–03:26 CEST, Oct 18 (23:42–01:26 UTC): about 2.94 trillion QU, roughly $1.3M at the time, leaves 1,404 wallets. A community-compiled list puts the total at 2,939,606,531,944 QU, swept into seven collecting wallets.

Computors halt the network at tick 85,371,949, freezing the ledger in place.

About 87.1% of the stolen QU never left Qubic and is stuck on the halted chain. About 12.9% reached MEXC, which froze the receiving account. Bitget paused QUBIC deposits and withdrawals.

05:28 CEST: a commit titled "fix: use cryptographically secure seed generation" lands in Qubic's open-source web wallet. Wallet v4.26.4 ships at 06:22 CEST.

Qubic says it also secured other exposed funds before the attacker reached them. Staking (QEARN) was not affected. Whether victims are compensated is up to the Computor quorum. Qubic says a full technical report will follow once a recovery plan is in place.

According to Qubic, the affected seeds are those created before October 18, 2026 in any browser on iPhone or iPad, in Safari on a Mac, or in the Qubic iOS app before July 2025.

How the attack worked

A Qubic seed is 55 lowercase letters. If each letter were truly random, that would be about 258 bits of entropy, far beyond any brute-force attack. But the strength of a seed depends on the random source that picks the letters, not on how long the string is.

The public diff for v4.26.4 shows what changed. Before the fix, the web wallet chose each letter with Math.random(). After the fix, it uses crypto.getRandomValues() with rejection sampling to remove modulo bias, and it fails closed if Web Crypto is unavailable.

Math.random() is not a cryptographic generator. It is built for speed and statistical spread, and it was never meant to be unpredictable to an adversary. So the real security of each seed came down to the internal state of the browser engine's generator.

Why Apple environments? On iOS and iPadOS, Apple's App Store rules have long required every browser (Chrome, Brave and Firefox included) to use WebKit and its JavaScript engine. Alternative engines are now allowed only under entitlements in the EU and Japan. That explains "any browser on iPhone/iPad" together with "Safari on Mac." In WebKit's public source, the Math.random generator (xorshift128+) is seeded with a single 32-bit value for each JavaScript global object. If that holds for affected versions, a fresh page can produce at most about 4.3 billion distinct random streams, whatever the seed length.

Note: this mechanism is our analysis of public code and fits Qubic's list of affected platforms. Qubic has not yet published its full root-cause report.

Once the effective key space is that small, the attack is simple to describe. Rebuild the candidate seeds, derive each one's public identity, check which identities hold funds, then sweep them. No phishing and no malware are needed. The victim never has to interact. Funds in "cold" storage are just as exposed if the seed was weak from the start.

The pattern: this has happened before

Android SecureRandom (2013): a flaw in Android's random generator let attackers recover keys from Bitcoin wallet signatures. Bitcoin.org told users to rotate keys.

Randstorm (2011–2015 wallets, disclosed 2023): BitcoinJS-era code quietly fell back to Math.random() in browsers, leaving many web-generated wallets with weak keys.

Profanity (2022): a vanity-address tool seeded 256-bit keys from 32 bits. Wintermute lost about $160M days after 1inch disclosed the issue.

Trust Wallet browser extension (CVE-2023-31290): a Mersenne Twister seeded with 32 bits. Exploited in the wild, with about $170K in losses.

Milk Sad (CVE-2023-39910): Libbitcoin Explorer's bx seed used 32 bits of system time. Exploited before it was publicly disclosed.

The pattern is hard to ignore. Weak-entropy key spaces tend to be found, enumerated quietly, and harvested by whoever maps them first, often before any disclosure. A 32-bit space is small enough to precompute and then watch. When funded wallets appear, the attacker can choose the moment. The Qubic drain began late on a Saturday night (UTC). We are not claiming anything about who did it. The point is that patient key-space harvesting is a documented practice, and assuming "nobody would bother" has failed every time.

What affected users should do now

What the free version won't cover

Patching one wallet fixes one bug. The bigger question is how you verify, before you trust a seed with real value, that it came from a sound entropy source. In the advancedsecurity Academy we go deeper: checking where wallet software actually gets its randomness, air-gapped seed generation workflows, auditing wallet code and builds before you trust them, and designing key setups where one weak link doesn't empty everything.

The Academy waitlist is open. Join it at advancedsecurity.club to be first in when it launches.