Le 18 octobre 2026, Qubic a annoncé une compromission de 1 404 portefeuilles et le détournement d'environ 2 940 milliards de QU, évalués autour de 1,3 à 1,4 million de dollars au moment de l'incident. Pour limiter les mouvements des fonds, les opérateurs de son réseau ont interrompu la production de nouveaux ticks.
Le cas est particulièrement instructif : les premiers éléments ne désignent pas une faille du consensus ou des signatures, mais la génération des secrets qui permettent de signer. Le correctif du wallet officiel, publié le jour même, permet de vérifier une partie essentielle du problème dans le code source.
Pour GLOV Secure et Snow-Fall, cette affaire relie deux sujets souvent étudiés séparément : la sécurité initiale des clés privées et la gouvernance opérationnelle d'une blockchain confrontée à une urgence.
Ce qui s'est passé les 17 et 18 octobre
Selon le bilan publié par Qubic, les transferts frauduleux ont eu lieu entre le 17 octobre à 23 h 42 UTC et le 18 octobre à 1 h 26 UTC, soit environ 104 minutes.
La liste communautaire établie à partir des transactions recense 1 404 adresses vidées, pour un total de 2 939 606 531 944 QU dirigés vers sept adresses de collecte. Ces données sont cohérentes avec les ordres de grandeur communiqués par Qubic, même si elles ne constituent pas à elles seules un rapport forensique complet.
L'équipe Qubic attribue les compromissions à des seeds générées avec une quantité insuffisante d'aléa. Les transactions ont donc pu être signées depuis les identités concernées : une signature cryptographiquement valide ne permet pas de distinguer le détenteur légitime d'un attaquant ayant retrouvé son secret.
Il faut ici éviter un raccourci : rien dans les éléments publiés ne démontre une rupture de la cryptographie de Qubic ou de son mécanisme de consensus.
Le code confirme l'emploi d'un générateur inadapté
Le 18 octobre, l'équipe a publié la version 4.26.4 de son wallet officiel. Les notes de version indiquent que la génération des seeds utilise désormais un mécanisme cryptographiquement sûr.
L'examen du correctif publié sur GitHub apporte une preuve technique directe : dans deux parcours de création de seed, l'ancien code utilisait Math.random() pour sélectionner chacune des 55 lettres du secret.
Or Math.random() est un générateur pseudo-aléatoire généraliste JavaScript. Son contrat de sécurité ne garantit pas l'imprévisibilité exigée pour la création d'une clé privée.
Le correctif centralise désormais cette opération dans une fonction qui fait appel à crypto.getRandomValues(), l'interface de génération aléatoire cryptographique du navigateur. Il ajoute également :
- un tirage avec rejet de certaines valeurs pour éviter un biais de distribution entre les 26 lettres ;
- des tests sur le format et la distribution des seeds ;
- un échec explicite si la source cryptographique sécurisée n'est pas disponible, plutôt qu'un retour silencieux à une source plus faible.
C'est une modification de sécurité importante et vérifiable. En revanche, le diff ne démontre pas à lui seul comment l'attaquant a retrouvé les seeds, ni le nombre réel de combinaisons accessibles sur chaque appareil. Ces éléments demandent un post-mortem technique spécifique.
Quels utilisateurs Qubic peuvent être concernés ?
Le périmètre provisoire communiqué par Qubic porte sur des seeds créées :
- avant le 18 octobre 2026, depuis un iPhone ou un iPad, quel que soit le navigateur ;
- avant le 18 octobre 2026, depuis Safari sur Mac ;
- avant juillet 2025, avec l'application Qubic pour iOS.
La date et l'environnement de création de la seed sont déterminants. Le fait d'utiliser aujourd'hui un autre appareil ou une autre application ne change pas les propriétés du secret initial.
Qubic utilise des seeds de 55 lettres minuscules, et non les phrases de récupération BIP39 classiques de 12 ou 24 mots. Le problème étudié ici concerne donc son propre mécanisme de création des identités.
Un portefeuille absent de la liste des 1 404 victimes n'est pas automatiquement sûr. La liste couvre les transferts déjà identifiés, pas toutes les seeds potentiellement fragiles.
Pourquoi mettre à jour le wallet ne suffit pas
La version 4.26.4 sécurise le mécanisme de génération pour les nouvelles seeds. Elle ne rend pas imprévisible une seed créée précédemment.
Cela signifie que plusieurs actions courantes ne corrigent pas le risque :
- changer le mot de passe local du coffre ;
- réimporter la même seed dans une version récente du wallet ;
- transférer cette seed vers un autre logiciel ;
- l'importer dans un hardware wallet.
Un hardware wallet peut protéger le stockage et l'usage d'une clé, mais il ne peut pas corriger rétroactivement une mauvaise génération. La protection matérielle ne remplace pas la qualité cryptographique du secret d'origine.
Pour un utilisateur relevant du périmètre à risque, la mesure à préparer est une migration vers une identité entièrement nouvelle, créée avec une source d'aléa fiable. Les transferts doivent toutefois attendre les instructions officielles et le rétablissement confirmé du réseau.
Aucune vérification de sécurité ne nécessite de saisir sa seed dans un formulaire tiers. Les propositions de « récupération » par message privé constituent un risque supplémentaire.
Pourquoi les Computors ont arrêté la blockchain
Pour contenir l'incident, les Computors de Qubic ont coordonné un arrêt protecteur au tick 85 371 949. Le réseau a ainsi cessé de traiter normalement de nouvelles transactions.
Qubic indique que 87,1 % des fonds détournés sont restés sur la chaîne et que les 12,9 % restants ont été envoyés vers MEXC, dont l'équipe aurait bloqué le compte destinataire.
Une vérification indépendante des adresses de collecte, publiée par Trenchbook, corrobore la présence d'environ 2 560 milliards de QU sur les adresses suivies. En revanche, l'attribution du solde à MEXC et le gel du compte reposent pour l'instant principalement sur les déclarations de Qubic.
Le 19 octobre, des vérifications du RPC officiel et de l'explorateur rapportaient toujours le tick d'arrêt. Une immobilisation des fonds ne signifie pas leur restitution. Les modalités de récupération restent liées aux décisions à venir des Computors et à leur exécution.
Une réponse d'urgence qui pose une question de gouvernance
L'arrêt coordonné a pu limiter la circulation des actifs contestés. Mais il rappelle qu'un réseau blockchain doit aussi être évalué à travers sa capacité à rester disponible et la manière dont les opérateurs peuvent prendre des décisions d'exception.
Les questions à documenter après cet incident sont concrètes :
- Qui peut demander un arrêt d'urgence, et selon quelle procédure ?
- Combien d'opérateurs indépendants ont effectivement participé ?
- Qui autorise le redémarrage et selon quels critères ?
- Une redistribution, un gel durable ou une autre mesure sur les soldes sera-t-elle proposée ?
- Les votes et les opérations correctives pourront-ils être vérifiés publiquement ?
Les Computors de Qubic ne doivent pas être confondus avec les validateurs d'une blockchain Proof-of-Stake classique. Les mécanismes diffèrent, mais le sujet transversal reste le même : la concentration possible du pouvoir opérationnel en période de crise.
Pour un opérateur d'infrastructure tel que Snow-Fall, la réponse à incident ne se réduit donc ni au redémarrage d'un nœud ni à un indicateur de disponibilité. Elle doit intégrer les dépendances de consensus, les procédures d'urgence, les accès de signature et les responsabilités des opérateurs.
Les enseignements pour la self-custody
Cet incident confirme un principe régulièrement défendu par GLOV Secure : une architecture non-custodial est aussi robuste que son secret le plus fragile.
Une bonne politique de sécurité doit contrôler la génération des clés, leur conservation, les opérations de signature, les sauvegardes et les procédures de migration. La présence de protections matérielles ou d'un code de chiffrement solide ne suffit pas si l'identité cryptographique a été créée avec une source prévisible.
Il faut également pouvoir remplacer rapidement un secret, sans réutiliser son origine compromise et sans perdre la traçabilité des opérations.
Pour approfondir, consulter nos analyses sur l'entropie des seed phrases, la migration d'un wallet potentiellement compromis et les limites des mises à jour face aux clés déjà créées.
Ce qui reste à établir au 19 octobre
Qubic a rendu public un résumé de l'incident et un correctif vérifiable. Mais plusieurs points doivent encore être considérés comme inconnus ou provisoires :
- la méthode exacte de recherche ou de prédiction des seeds utilisée par l'attaquant ;
- le degré réel de perte d'entropie selon les environnements ;
- le nombre total de portefeuilles encore exposés ;
- la validation indépendante du gel des fonds hors chaîne ;
- les modalités définitives de restitution et de redémarrage ;
- les contrôles qui auraient dû empêcher cette faiblesse d'atteindre la production.
Un rapport technique complet reste nécessaire pour répondre à ces questions.
La leçon dépasse Qubic : la self-custody commence au moment où le secret est généré, et la résilience d'une blockchain se mesure aussi à la transparence de ses décisions de crise.
Analyse GLOV Secure / Snow-Fall — situation connue au 19 octobre 2026. Cet article pourra être complété par de nouvelles publications si l'enquête révèle des éléments importants.
Sources
- Qubic — déclaration officielle sur l'incident du 18 octobre 2026
- Qubic — publication du wallet v4.26.4
- Qubic — correctif officiel de génération cryptographique des seeds
- Qubicmap — liste communautaire des adresses affectées et consignes du projet
- Trenchbook — vérification des adresses et du tick d'arrêt
- Cointelegraph — enquête publiée le 19 octobre 2026