On 18 October 2026, Qubic reported that 1,404 wallets had been compromised and approximately 2.94 trillion QU diverted, worth an estimated $1.3–1.4 million at the time of the incident. To restrict further movements of funds, operators coordinated a halt to the network's normal tick progression.
The case is instructive because the first findings do not point to a failure in consensus or signature verification. Instead, they concern how the secrets used to produce those signatures were generated. A fix released for the official wallet on the same day provides directly inspectable code evidence for a critical part of that failure.
For GLOV Secure and Snow-Fall, this incident brings together two areas often assessed separately: the security of private-key generation and the operational governance of a blockchain during an emergency.
What happened on 17 and 18 October
According to Qubic's incident update, the unauthorised transfers took place between 23:42 UTC on 17 October and 01:26 UTC on 18 October — approximately 104 minutes.
A community-compiled transaction record identifies 1,404 drained addresses and 2,939,606,531,944 QU routed to seven collection addresses. The figures are consistent with those presented by Qubic, although an on-chain reconstruction is not a substitute for a complete forensic report.
Qubic attributes the compromises to wallet seeds generated with insufficient randomness. An attacker able to reconstruct an affected secret can sign transactions under that wallet's identity. The signature will verify mathematically even when it was not produced by the legitimate owner.
This distinction matters: the currently published evidence does not establish that Qubic's signature cryptography or its consensus mechanism was broken.
The code confirms an unsuitable random-number generator
On 18 October, the team published wallet version 4.26.4. Its release notes describe an improvement to cryptographically secure seed generation.
The official source-code patch provides direct technical evidence. In two seed-creation paths, the earlier implementation used Math.random() to select each of the 55 letters making up the seed.
JavaScript's Math.random() is a general-purpose pseudorandom-number generator. It does not provide the unpredictability guarantees required for generating private-key material.
The correction moves seed creation into a function based on crypto.getRandomValues(), the browser interface intended for cryptographically secure randomness. It also introduces:
- rejection sampling to avoid a distribution bias when mapping random bytes to 26 letters;
- tests of seed format and distribution;
- explicit failure when secure randomness is unavailable, rather than silently falling back to a weaker source.
The change is important and independently verifiable in the source code. However, the patch alone cannot demonstrate exactly how the attacker reconstructed the seeds, or establish the effective search space on every affected device. Those questions require a dedicated technical post-mortem.
Which Qubic wallets could be at risk?
Qubic's provisional affected-environment guidance includes seeds created:
- before 18 October 2026 on an iPhone or iPad, regardless of the browser used;
- before 18 October 2026 using Safari on macOS;
- before July 2025 with the Qubic iOS application.
The important factor is the device and software used when the seed was first generated. Accessing the same wallet today from a different device does not change the security properties of that original secret.
Qubic uses seeds containing 55 lowercase letters, rather than standard BIP-39 recovery phrases of 12 or 24 words. The issue must therefore be evaluated within Qubic's own identity-generation design.
A wallet missing from the list of the 1,404 observed victims is not necessarily safe: that list reflects transfers identified so far, not every seed that may have been generated with inadequate entropy.
Why installing the update is not enough
Wallet version 4.26.4 strengthens the generation process for new seeds. It does not make previously created secrets unpredictable.
Several apparently reassuring actions therefore do not fix the root cause:
- changing the local wallet password;
- importing the same seed into the updated application;
- importing the same seed into another software wallet;
- moving the seed into a hardware wallet.
A hardware wallet can protect the storage and use of a key, but it cannot retroactively fix a weakly generated secret. Hardware protection is not a substitute for strong entropy at key creation.
For users within the affected group, the appropriate plan is a migration to an entirely new identity, created using a trustworthy source of randomness. Transfers must still be coordinated with official guidance and the verified restoration of normal network operation.
No legitimate safety check requires entering a private seed into a third-party website or direct-message form. Fraudulent “recovery” offers add another layer of risk during an incident.
Why Qubic's Computors halted the chain
To contain the incident, Qubic's Computors coordinated a protective halt at tick 85,371,949. Normal network transaction processing was interrupted.
Qubic stated that 87.1% of the diverted funds remained on-chain and that the remaining 12.9% had been transferred towards MEXC, where the receiving account was reportedly frozen.
An independent review of collection addresses by Trenchbook supports the observation that approximately 2.56 trillion QU were still held in the tracked addresses. The attribution of the remainder to MEXC and the reported exchange-account freeze, however, primarily rely on Qubic's own statements at this stage.
Checks reported on 19 October still found the official RPC and explorer at the halted tick. Funds that can no longer move have not necessarily been returned to their owners. Recovery depends on subsequent decisions by the Computors and their implementation.
Emergency response is also a governance question
Coordinated interruption may have limited further movements of disputed assets. It also illustrates that blockchains must be assessed not only for availability, but for how exceptional powers are exercised during an emergency.
A transparent post-incident review needs to establish:
- Who is permitted to request an emergency halt, and under which rules?
- How many genuinely independent operators took part?
- Who authorises a restart, and against what safety criteria?
- Will a redistribution, extended freeze or other balance-related action be proposed?
- Can votes and corrective actions be independently verified?
Qubic Computors are not directly interchangeable with validators on a conventional Proof-of-Stake chain. Their selection rules and responsibilities differ. Yet the broader concern is shared: the distribution of operational authority when a decentralised system is under pressure.
For an infrastructure operator such as Snow-Fall, incident response cannot be reduced to restarting a node or tracking uptime. It must cover consensus dependencies, emergency procedures, signing access and operator accountability.
Lessons for self-custody
This incident reinforces a principle repeatedly emphasised by GLOV Secure: a non-custodial architecture is only as strong as its weakest secret.
A meaningful security programme should review how keys are generated, stored, used to sign transactions, backed up and eventually rotated or migrated. Hardware isolation and strong encryption cannot compensate for an identity produced using insufficient randomness.
Teams must also be able to replace a secret without reusing compromised material or losing the audit trail of their operations.
For more context, see our articles on seed phrase entropy, migrating a potentially compromised wallet, and the limits of seemingly valid hardware-wallet secrets.
What remains unresolved as of 19 October
Qubic has published an incident summary and a source-code fix that can be inspected. Several important elements, however, remain unknown or provisional:
- the precise method the attacker used to predict or search for seeds;
- the effective reduction in entropy across affected environments;
- the total number of wallets that may still be exposed;
- independent confirmation of any off-chain funds freeze;
- final restitution and restart procedures;
- which development and review controls failed to detect the problem before release.
A comprehensive technical post-mortem will be essential to answer these questions.
The lesson extends beyond Qubic: self-custody security begins with key generation, and the resilience of a blockchain also depends on transparent, verifiable decisions made in a crisis.
GLOV Secure / Snow-Fall analysis — information available as of 19 October 2026. Major subsequent findings may warrant separate follow-up articles.
Sources
- Qubic — official incident statement, 18 October 2026
- Qubic — wallet v4.26.4 release
- Qubic — official cryptographic seed generation patch
- Qubicmap — community record of affected addresses and project guidance
- Trenchbook — address and halt-tick verification
- Cointelegraph — report published 19 October 2026