Qubic Wallet Drain: The Patch Cannot Fix an Old Seed

Bottom line: Qubic says an attacker drained 1,404 wallets holding about 2.94 trillion QU after some wallet seeds were generated with insufficient randomness. The project halted the network at tick 85,371,949 and released web-wallet version 4.26.4 with a cryptographically secure generator.

The patch prevents the web wallet from creating new seeds through the old code path. It cannot make an existing seed more random. If a Qubic seed was created through one of the affected Apple or Safari routes identified by the project, updating the wallet or changing its password is not enough. The funds need to move to a new identity generated with the fixed software once transfers safely resume.

This incident also reveals a second trade-off. Qubic’s Computors were able to stop finalizing transactions, containing most of the drained QU. That protected users in this emergency, but it also demonstrates how much operational power sits with the active Computor set.

The featured image is an AI-generated illustration of predictable seed outputs meeting a network barrier, not a Qubic wallet interface.

What Qubic says happened

In its official incident thread, posted October 18 and checked October 19, Qubic says the unauthorized transfers ran from 23:42 UTC on October 17 to 01:26 UTC on October 18. The attacker emptied 1,404 wallets of roughly 2.94 trillion QU.

Qubic attributes the compromise to seeds generated with insufficient randomness, not to a flaw in Qubic’s transaction-validation rules or smart-contract engine. It identifies three affected creation paths:

• Any browser on an iPhone or iPad before October 18, 2026
• Safari on a Mac before October 18, 2026
• The Qubic iOS app before July 2025

That scope is about where and when the seed was created, not the device currently used to open the wallet. Importing an affected seed into a new browser, desktop app or hardware wallet does not replace the underlying secret.

The team says Computors halted the network at tick 85,371,949. It reported that 87.1% of the drained funds remained frozen inside Qubic and that the other 12.9% reached MEXC, where the receiving account was frozen. Those percentages and the attribution remain Qubic’s incident findings, not an independent forensic conclusion.

At 12:03 HKT on October 19, Qubic’s official tick-info RPC still returned tick 85,371,949. Its latestTick endpoint returned 85,371,947. That is consistent with the network remaining halted at our publication check. Users should verify the current state through official channels before attempting a migration.

The public patch shows the vulnerable design

Qubic released web-wallet v4.26.4 on October 18. Its release notes say seed generation was updated to use cryptographically secure randomness.

The underlying official code change, checked October 19, is unusually clear. Before the patch, two wallet flows assembled the 55-character seed by repeatedly choosing a letter with JavaScript’s Math.random(). The new utility instead calls the Web Crypto API’s crypto.getRandomValues().

The replacement also uses rejection sampling. It accepts random byte values below 234 and maps them across the 26 lowercase letters, discarding the remaining values. Because 234 is divisible by 26, each letter receives the same number of accepted byte values. The tests make the generator fail closed when secure randomness is unavailable instead of quietly falling back to a weaker source.

This matters for two separate reasons:

1. Math.random() is not designed to create cryptographic secrets. Its output may be adequate for visual effects, games or randomized interfaces, but a wallet seed needs an operating-system-backed cryptographic random source.
2. Mapping can introduce bias even with secure bytes. A direct byte-modulo-26 operation slightly favors some letters because 256 is not evenly divisible by 26. Rejection sampling removes that bias.

The public diff confirms that the web wallet had a weak construction. It does not, by itself, disclose the attacker’s exact search method, the effective number of possible seeds on each affected platform, or whether every seed from those environments was practically recoverable. Qubic has not published a full technical post-mortem establishing those details.

Why installing v4.26.4 does not repair an old wallet

A seed is the input from which a wallet derives its private key and public identity. Software can change how the next seed is produced, but it cannot retroactively add entropy to a seed that already exists.

That makes this different from a routine app vulnerability where installing an update removes the exposure. Version 4.26.4 fixes the generator. It does not rotate an existing private key, change the address controlled by that key, or make copies of the old seed disappear.

Several actions therefore do not solve the core problem:

• Changing the wallet’s local password only changes access to the local vault; it does not change the seed-derived key.
• Importing the same seed into updated software recreates the same identity.
• Moving the seed onto a hardware device preserves the same compromised secret.
• Checking that an address was not among the first 1,404 drained wallets does not prove its seed was unpredictable.

The clean migration is to generate a fresh seed through a verified secure route, derive a new identity, and transfer assets from the old identity when the network and official instructions allow it. Users should never type the old seed into a third-party checker or send it to someone offering recovery help.

The halt contained losses—and exposed Qubic’s control surface

Qubic describes its active validators as Computors. Its official consensus documentation, checked October 19, says the network has 676 Computors and needs at least 451 aligned votes to validate an outcome. Its quorum documentation says the same group forms ticks and votes on proposals.

In this incident, coordination among operators stopped new ticks and trapped most of the disputed funds before they could leave the network. That is a meaningful containment capability. A conventional chain that continues finalizing transactions would not offer the same pause while investigators identify destinations.

But emergency usefulness should not be confused with neutral decentralization. If a sufficiently coordinated operator set can stop the ledger to contain theft, the same liveness dependency matters during governance conflict, regulatory pressure, operator outage or a disputed recovery proposal.

The relevant questions after restart are therefore broader than whether victims recover funds:

• Who requested the halt, and through which documented procedure?
• How many independent Computor operators participated?
• What objective conditions authorize a restart?
• Will any balances be reassigned, rolled back or left at their current addresses?
• Can users independently verify the vote and the final state transition?

Qubic says the Computor quorum will determine the resolution. Until that decision is final and implemented, users should treat claims of guaranteed reimbursement or a specific rollback as unconfirmed.

What affected users should do

The safest sequence depends on the network being operational and on Qubic publishing final migration instructions. Do not race into unofficial tools while transfers are paused.

1. Determine the seed’s origin. The important fact is the device, browser or app that originally generated it—not where it is stored today.
2. Treat listed creation paths as compromised. Do not wait for an address to appear on a victim list before planning a move.
3. Use official software and verify the version. For the web wallet, the public fix is in v4.26.4. Start from Qubic’s official website or repository rather than a sponsored search result.
4. Create a genuinely new seed. Do not import, transform, shorten or “upgrade” the old one. Record the new secret offline and never send it to support staff.
5. Wait for confirmed network and exchange status. A transaction signed during a halt may not execute as expected. Confirm the restart and any special recovery procedure through multiple official channels.
6. Move all assets tied to the old identity. A small test can verify the new destination after transfers resume, followed by the remaining balance and any supported assets or contract positions.
7. Retire the old seed. Once migration is complete, do not reuse it for a future wallet or service.

Users whose seeds were created outside Qubic’s listed environments should still watch the final post-mortem. The current scope is based on the project’s investigation and could change if new evidence appears.

Our view: wallet entropy needs the same scrutiny as smart contracts

Crypto security reviews often focus on consensus code, bridge contracts and signature verification. Yet a perfectly validated transaction is still theft if an attacker can reconstruct the key that signed it.

The Qubic patch is only a few lines at the point of use: replace a general-purpose pseudo-random generator with the browser’s cryptographic API, remove modulo bias, test failure cases, and refuse to generate a seed without secure randomness. Those lines sit upstream of every later security control.

The positive part of the response is that Qubic published the wallet source, shipped an inspectable fix and contained much of the disputed balance. The unresolved part is accountability: users still need a complete post-mortem explaining how the platform-specific weakness arose, how the affected population was bounded, why tests did not catch it earlier, and how emergency network control will be governed after the immediate crisis.

For users, the takeaway is concrete. A wallet update protects future key generation. It does not heal an old key. If the seed’s origin falls within Qubic’s affected scope, migration—not reassurance—is the security boundary that matters.

Qubic wallet incident FAQ

Was the Qubic blockchain itself hacked?

Qubic says the attacker reconstructed weak wallet seeds and signed transfers from affected identities; it has not attributed the theft to a consensus or smart-contract exploit. A full independent post-mortem has not yet been published.

Which Qubic wallets may be affected?

Qubic lists seeds created before October 18, 2026 in any browser on an iPhone or iPad, in Safari on a Mac, or before July 2025 in the Qubic iOS app. The creation environment matters even if the seed was later imported elsewhere.

Does updating to web-wallet v4.26.4 make an old seed safe?

No. The update changes how new seeds are generated. It cannot add randomness to an existing seed or change the identity derived from it. An affected user needs a newly generated seed and a transfer to the new identity.

Is the Qubic network running again?

At 12:03 HKT on October 19, Qubic's official RPC still reported the incident halt tick. Check Qubic's official RPC and announcements for the current state before signing or broadcasting a migration transaction.

Should users enter their seed into a wallet checker?

No. A legitimate balance or victim-list checker needs only a public identity. Never enter a seed or private key into a website, direct message, form or recovery service.

Sources and evidence limits

Primary sources checked October 19, 2026: Qubic’s October 18 incident thread; the official web-wallet v4.26.4 release and secure seed-generation commit; Qubic’s live tick-info and latestTick RPC endpoints; and Qubic’s consensus and quorum documentation.

Evidence limit: Qubic has published an incident summary and a code fix, but not a complete technical post-mortem. The public materials do not establish the attacker’s precise seed-search method, quantify the practical entropy loss for each platform, independently verify the frozen-fund percentages, or settle how the quorum will handle affected balances. Those points should remain provisional until Qubic publishes reproducible evidence and a final resolution.

Disclosure: This article is for general information and does not constitute financial or investment advice.