Un bug dans staking means depositing a proof of stake coin with a protocol that stakes it for you and issues a transferable token (such as Lido stETH or rETH) representing the deposit plus rewards, which you can use or sell while the coins stay staked.">Reth, le client d’exécution d’Ethereum développé par Paradigm, pouvait faire calculer à un nœud une mauvaise racine d’état (state root), et les réseaux qui l’utilisent ont publié des correctifs entre le 4 et le 6 novembre 2026. Base, BSC-Reth de BNB Chain et la blockchain Tempo ont sorti des versions corrigées, et le directeur technique de Paradigm a demandé aux opérateurs d’op-reth, le client d’Optimism, de mettre à jour eux aussi. Base affirme avoir vérifié sa racine d’état actuelle et que « les utilisateurs n’ont pas été touchés ». Aucune source ne fait état d’une perte de fonds, d’une exploitation de la faille ou d’une panne.
Les premiers titres parlaient d’un bug d’Ethereum. C’est trop large. La faille se trouvait dans un seul client, dans le chemin que la note de version de BNB Chain appelle le calcul « legacy » de la racine d’état. Elle n’était ni dans le protocole Ethereum ni dans Geth, le client d’exécution le plus utilisé. Aucune source ne cite Arbitrum, qui fait tourner son propre logiciel Nitro fondé sur Geth, parmi les réseaux touchés, et Arbitrum n’a fait aucune déclaration.
Les effets en cascade ont été des mesures de précaution. LayerZero a suspendu certaines routes entre blockchains, et le gestionnaire de risque Gauntlet a limité les dépôts dans certains vaults, selon la presse. Au 7 novembre à 07 h 30 UTC, LayerZero n’avait publié aucune déclaration de sa part sur la pause ni sur la date de reprise des routes.
Le bug Reth : un nœud pouvait se tromper sur la racine d’état (state root)
Chaque bloc d’Ethereum, et des réseaux de couche 2 bâtis dessus, s’engage sur une racine d’état : un hash unique qui résume le solde de chaque compte et le stockage de chaque contrat une fois les transactions du bloc exécutées. Chaque nœud la recalcule. Un nœud qui obtient un autre résultat n’est plus d’accord avec la chaîne. smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il peut cesser de la suivre ou, s’il produit des blocs, en proposer un que les autres nœuds rejettent. Notre guide sur le rôle d’un nœud blockchain détaille les vérifications en jeu.
La page d’état de Base indique que le bug de Reth pouvait, « dans certains cas, faire calculer à un nœud une racine d’état incorrecte ». La note de version de BNB Chain le situe dans le chemin de calcul « legacy », « dans des conditions précises de l’arbre de Merkle (trie) ». CryptoSlate est allé plus loin le 6 novembre : selon le média, certaines structures de stockage de contrats intelligents pouvaient le déclencher, une transaction forgée pouvait l’activer dans des conditions précises, et les logiciels de construction de blocs employaient la méthode vulnérable sur du matériel modeste et dans les réseaux OP Stack. Aucun document primaire ne confirme le point de la transaction forgée. On ignore si quelqu’un aurait pu exploiter la faille volontairement.
L’inquiétude dépassait le cas d’un nœud qui décroche. Les systèmes de preuve et certains ponts s’appuient sur les racines d’état pour établir ce qui s’est passé sur une chaîne, d’où l’avertissement de Konstantopoulos, qui citait les ponts DeFi et les « systèmes adossés à des preuves d’état ». Il a aussi affirmé, selon CryptoSlate, que la plupart des ponts reposent sur des racines de reçus ou sur une validation par multisignature plutôt que sur le calcul touché. La page d’état de Base précise que son système de preuve vérifie chaque racine d’état avec une implémentation indépendante. TokenPost a décrit la faille comme « un problème de justesse du client, pas une attaque connue ».
Un correctif qui ne disait pas ce qu’il corrigeait
Le changement de code est venu en premier, et discrètement. La pull request n° 28264 sur le GitHub de Reth, intitulée « fix(trie): tighten iterator seek boundary », a été ouverte à 20 h 13 UTC le 3 novembre et fusionnée à 21 h 00 UTC. Elle modifie un seul fichier, avec 79 lignes ajoutées et 12 supprimées. Sa description explique comment un itérateur décide où chercher à la frontière d’une branche en cache, et elle ajoute un test de non-régression. Aucune étiquette, aucun mot sur la sécurité.
La page d’état de Base date la découverte du 4 novembre, et Base dit avoir appliqué ce jour-là une parade à tous ses constructeurs de blocs. Le 5 novembre, trois versions sont sorties en 70 minutes environ. Paradigm a présenté Reth v2.10.0 comme une « version de durcissement » (hardening release), avec une priorité de mise à jour élevée pour tous les types de nœuds, et a rangé le correctif sous Engine & Trie. Les notes n’emploient jamais les mots « racine d’état » ni « sécurité ».
| Heure (UTC) | Qui | Quoi |
|---|---|---|
| 3 nov., 21 h 00 | Paradigm (Reth) | Pull request n° 28264 fusionnée |
| 4 nov. | Base | Bug repéré, parade appliquée à ses constructeurs de blocs |
| 5 nov., 15 h 10 | Optimism | op-reth v2.8.1 publié |
| 5 nov., 16 h 01 | Base | Nœud v1.5.3 : « Prévient une divergence de racine d’état » |
| 5 nov., 16 h 18 | Paradigm (Reth) | Reth v2.10.0, « version de durcissement » |
| 5 nov., 17 h 52 | Base | La page d’état demande aux opérateurs de mettre à jour |
| 5 nov., 22 h 17 | Georgios Konstantopoulos | Alerte publique sur X |
| 6 nov., 02 h 53 | BNB Chain | BSC-Reth v0.1.4-hotfix |
| 6 nov., 18 h 13 | Tempo | v1.18.2, priorité haute pour les validateurs |
| 6 nov., 18 h 53 | Paradigm (Reth) | Version de maintenance v2.10.1, bug non mentionné |
Unchained a compté environ 43 heures entre la fusion et l’avis public de Base. Au 7 novembre, aucun avis de sécurité GitHub n’existait sur le dépôt de Reth, aucune source ne citait de numéro CVE, et Paradigm n’avait publié aucun post-mortem.
L’alerte de Konstantopoulos, et des notes de version muettes
L’alerte publique est arrivée tard le 5 novembre. À 22 h 17 UTC, Georgios Konstantopoulos, directeur technique de Paradigm, a publié sur X un message d’information : un correctif avait été diffusé dans tout l’écosystème Reth, de sorte que les nœuds basés sur Reth, les ponts DeFi et les systèmes adossés à des preuves d’état « sont tous sûrs ». Il a demandé à quiconque dépend de Reth de passer à Reth v2.10.0, OP Reth v2.8.1 et Base v1.5.3.
CryptoSlate rapporte que, dans le même fil, il a décrit un cas limite dans l’ancien code de calcul de la racine d’état de Reth, s’est excusé pour la perturbation, a dit que les systèmes de retrait de Base et des autres chaînes OP Stack n’étaient pas exposés, et qu’Optimism avait reçu un correctif. Coindaro n’a pas pu lire le fil en entier : ces points reposent donc sur le récit de CryptoSlate.
Un détail ne colle pas. Les notes d’op-reth v2.8.1 demandent à tous les opérateurs de nœuds de mettre à jour, mais ne décrivent que la correction d’un appel RPC, eth_capabilities. Elles ne disent rien des racines d’état, alors que la version couvre 153 commits depuis la v2.8.0. L’affirmation selon laquelle elle embarque le correctif de l’arbre de Merkle repose donc sur le message de Konstantopoulos et sur la presse. Nous n’avons trouvé non plus aucun avis d’état côté Optimism ; notre fiche sur OP Mainnet et le Superchain explique qui maintient ce logiciel.
Base, BNB Chain et Tempo : qui a corrigé, et ce qu’ils ont dit
Base : pas de resynchronisation, et le risque d’arrêt écarté
La version v1.5.3 du nœud Base indique qu’elle « prévient une divergence de racine d’état » et classe la mise à jour comme recommandée, sans échéance ni changement incompatible. La page d’état de Base a ouvert une entrée de maintenance à 16 h 19 UTC le 5 novembre et, à 17 h 52 UTC, a demandé aux opérateurs de mettre leurs nœuds à jour dès que possible. Elle précise qu’aucune resynchronisation n’est nécessaire et que la version écarte le risque d’arrêt des validateurs de Base face à une racine d’état invalide.
« Nous avons vérifié que la racine d’état actuelle est correcte et que les utilisateurs n’ont pas été touchés », a écrit Base. L’entrée affiche une fenêtre courant jusqu’à 16 h 19 UTC le 7 novembre et aucune mise à jour de clôture. Un retard d’inclusion des transactions le 2 novembre, et la mise à niveau Denim du 5 novembre, ne sont pas liés à ce bug.
BNB Chain : un correctif d’urgence pour tous les opérateurs de BSC-Reth
BNB Chain a publié BSC-Reth v0.1.4-hotfix à 02 h 53 UTC le 6 novembre. Les notes disent qu’il intègre le correctif de Reth en amont et qu’il n’exige ni migration de base de données ni hard fork. Elles demandent aux validateurs, aux constructeurs MEV, aux nœuds complets et aux sentinelles qui font tourner reth-bsc de mettre à jour. Dans un message sur X cité par crypto.news, BNB Chain a écrit : « opBNB n’utilise pas op-reth, et l’impact sur BSC-Reth est limité. »
Tempo : l’équipe qui l’aurait trouvé
Tempo, la blockchain de paiements en stablecoins incubée par Stripe, a livré la v1.18.2 à 18 h 13 UTC le 6 novembre, avec une priorité haute pour les validateurs et une ligne indiquant qu’elle met Reth à jour avec un correctif sur les recherches de l’itérateur de l’arbre. Tempo est une chaîne de couche 1, pas une couche 2 ; notre explication sur la différence entre couche 1 et couche 2 montre pourquoi cela compte.
CryptoSlate rapporte que l’équipe de Tempo a trouvé le bug par fuzzing, une méthode de test qui injecte un grand nombre d’entrées aléatoires dans un logiciel pour le faire planter. Aucune autre source consultée ne le dit, et la page de Base consigne la découverte au 4 novembre sans nommer son auteur.
LayerZero a suspendu des routes, et les ponts se sont crispés
LayerZero, le protocole de messagerie que de nombreux ponts de jetons utilisent, a suspendu « certaines routes entre blockchains par précaution », routes qui « devraient reprendre bientôt », selon un message de Frax sur X cité par Unchained le 5 novembre. Frax l’a depuis supprimé. TokenPost écrivait le 7 novembre que LayerZero avait suspendu une partie de son infrastructure hors chaîne pour certains réseaux EVM et que les messages étaient retardés, pas perdus. Aucune déclaration de LayerZero ne donne d’heure de début, de liste de routes ni de reprise. CryptoSlate note que la pause ne prouve pas que les contrats de LayerZero étaient vulnérables.
Gauntlet, le curateur de risque, a limité les dépôts dans ses vaults V1, suspendu les allocations et réduit son exposition aux actifs transférés via LayerZero, selon The Defiant, dont le résumé indique qu’aucune exploitation n’avait été signalée à la connaissance de Gauntlet. Unchained, qui relaie cet article, ajoute que les retraits sont restés ouverts. Le message de Gauntlet sur X a été supprimé : ces détails reposent donc sur les deux médias.
Les ponts ont de quoi être nerveux. En avril, l’exploitation de 292 millions de dollars du pont rsETH de Kelp DAO, que LayerZero a attribuée au groupe nord-coréen Lazarus, a rendu la tuyauterie entre blockchains suspecte. Unchained a fait le parallèle ; aucune source ne relie les deux événements. Notre fiche projet LayerZero détaille ce que le piratage de Kelp a changé. Le projet d’ApeChain de faire passer ses actifs de LayerZero à Chainlink CCIP a été annoncé le 4 novembre, avant les alertes sur Reth, a rapporté crypto.news.
Le deuxième bug de state root de Reth en 14 mois
Reth a déjà connu cela. Le 2 septembre 2025, un autre bug de racine d’état a bloqué certains nœuds du mainnet Ethereum qui faisaient tourner Reth 1.6.0 et 1.4.8, comme l’a rapporté The Block le lendemain. Konstantopoulos avait alors lui aussi partagé des commandes de récupération. The Block citait des données d’Ethernodes situant Reth à 5,4 % des clients de la couche d’exécution à l’époque, et disait que seule une petite part des nœuds semblait touchée. Aucune source ne donne de chiffre actuel.
Cette petite part est ce qui permet au mainnet Ethereum d’absorber un bug dans un seul client : les nœuds sous Geth et sous les autres clients continuent de calculer la bonne racine et la chaîne avance. Une couche 2 dont tous les constructeurs de blocs utilisent le même client n’a pas ce coussin, ce qui explique que Base ait mis en avant son implémentation de preuve indépendante pour dire que les utilisateurs n’étaient pas touchés.
Les logiciels de preuve ont eu leurs propres frayeurs cet automne. En octobre, Succinct a corrigé un bug de SP1 qui laissait passer des preuves invalides dans son vérificateur Rust, sans effet sur les vérifications en chaîne.
Ce qu’on ignore encore, et ce qu’il faut surveiller
Paradigm n’a publié ni post-mortem, ni avis de sécurité, ni description technique du déclencheur exact. Personne n’a dit si le bug avait été touché un jour sur un réseau en production, combien de nœuds faisaient tourner les versions affectées, ni si des chaînes OP Stack comme Unichain ou Ink ont été touchées ou simplement corrigées.
Les prochains repères sont un post-mortem ou un avis de sécurité de Paradigm, et un mot de LayerZero annonçant que ses routes fonctionnent de nouveau. La fenêtre de maintenance de Base se ferme à 16 h 19 UTC aujourd’hui.
Les nœuds restés sur l’ancien code sont le risque qui demeure. Blockaid a averti, selon Unchained, qu’ils pouvaient se figer ou renvoyer des preuves d’état erronées. Les projets ont demandé aux opérateurs de passer à Reth v2.10.0 ou plus récent, op-reth v2.8.1, Base v1.5.3, BSC-Reth v0.1.4-hotfix ou Tempo v1.18.2.