protocol
Ethereum : des agents IA remontent CVE-2026-34219 dans libp2p-gossipsub
L'équipe Protocol Security de la Fondation Ethereum publie le 9 juillet un post détaillant comment des agents IA ont fait émerger un panic distant dans Rust libp2p-gossipsub, patché en v0.49.4.
L'équipe Protocol Security de la Fondation Ethereum a publié le 9 juillet 2026 un billet intitulé « The triage is the product » qui documente une campagne d'audit du code protocole conduite par un essaim d'agents IA coordonnés. Le retour matériel de l'exercice : CVE-2026-34219, un panic déclenchable à distance dans l'implémentation Rust de libp2p-gossipsub — la couche de propagation P2P utilisée par les clients consensus d'Ethereum — dépublié via l'avis GHSA-gc42-3jg7-rxr2 et corrigé en v0.49.4. Couverture francophone chez Cointribune, Coin Academy et Journal du Token.
Ce qui a été publié
Le billet d'EF Protocol Security décrit une campagne où plusieurs agents IA travaillent en parallèle sur le code systèmes, le code cryptographique et les contrats du protocole Ethereum. Les agents se coordonnent via un dépôt Git partagé, sans orchestrateur central — une structure directement inspirée du travail « fleet-based compiler » d'Anthropic, mentionnée par l'équipe. Un agent produit à lui seul environ 1 000 signalements candidats ; après revue humaine, 86 % des propositions les mieux classées survivent à l'examen. Le titre du billet est prescriptif : le goulot d'étranglement n'est plus l'invention de faux positifs plausibles, mais leur tri.
Le seul signalement de la campagne à mériter à ce jour un identifiant CVE public est CVE-2026-34219, décrit ci-dessous.
Mécanisme — un panic à distance dans le heartbeat gossipsub
Gossipsub est le protocole de diffusion (pub/sub) que tous les clients consensus d'Ethereum utilisent pour propager blocs et attestations. L'implémentation Rust vit dans le crate libp2p-gossipsub. Le bug est dans le traitement du champ backoff d'un message de contrôle PRUNE :
- Un pair envoie un message PRUNE dont le
backoffest réglé au maximum autorisé. - La valeur est convertie côté récepteur en un
Instantproche du plafond. - À chaque heartbeat (période comprise entre 43 et 74 secondes), l'expiration du backoff est calculée par une addition non vérifiée :
backoff_time + slack. - L'addition dépasse la plage représentable, panique dans un thread validateur, et fait tomber le nœud.
L'attaque ne demande ni compte, ni mise, ni compétence de minage. Il suffit d'être connecté comme pair gossipsub légitime — un état atteignable via une session TCP + Noise + mplex/yamux classique. Le pair peut se reconnecter et rejouer le message après chaque crash, transformant l'exploit en déni de service persistant à coût quasi nul.
Correctif
- Package :
libp2p-gossipsub(Rust) - Version corrigée : v0.49.4
- Avis GitHub : GHSA-gc42-3jg7-rxr2
- Correctif : contrôles de bornes sur la durée
backoffd'un PRUNE avant qu'elle n'entre dans l'arithmétique du heartbeat.
Le CVSS remonté par les sources varie : le CVSS v3.1 publié dans l'avis est en zone haute (8.2), plusieurs bases publiques rapportent un score intermédiaire (5.9). Écart classique de scoring — l'important pour un opérateur de validateur est que la condition de déclenchement (« un pair, un message ») autorise à traiter la mise à jour comme non négociable.
Périmètre touché
- Clients consensus Ethereum qui embarquent
rust-libp2p: notamment Lighthouse (Rust), et toute distribution ou side-car qui dépend du crate à une version antérieure à 0.49.4. - Toute application externe à Ethereum qui utilise le crate en production, ce que rappelle l'avis Snyk lié à la CVE — libp2p sert bien au-delà d'Ethereum.
- Non affectés : les clients consensus qui embarquent leur propre implémentation gossipsub non-Rust (par exemple les implémentations Go dans
go-libp2psont sur une base de code distincte), sauf s'ils ont chaîné une dépendance sur le crate Rust patché.
Chaque opérateur de nœud doit vérifier la version de libp2p-gossipsub réellement embarquée par son binaire (résolution transitive incluse), pas seulement la version du client consensus.
Que faire, dans l'ordre
- Mettre à jour les nœuds vers un binaire consensus qui embarque
libp2p-gossipsub≥ v0.49.4. Les images officielles publiées après le 9 juillet 2026 par les équipes clients devraient satisfaire cette contrainte — à confirmer sur les release notes. - Contrôler la chaîne de dépendances. Pour les opérateurs qui compilent leur propre binaire ou embarquent des side-cars (indexeurs, MEV-boost, proxys custom), résoudre le lock file et confirmer la version finale du crate.
- Filtrer temporairement, si la mise à jour ne peut pas être appliquée dans la fenêtre d'exposition, les pairs gossipsub nouveaux et inconnus au niveau réseau (le vecteur exige un peer authentifié en Noise).
- Surveiller les paniques dans les journaux des clients consensus sur les 43–74 secondes qui suivent un pic de nouveaux pairs.
Contexte — l'IA en sécurité protocole, second cas public en six semaines
C'est le second bug consensus-critique majeur d'une chaîne publique attribué en 2026 à une boucle d'audit assistée par l'IA. Fin mai, un auditeur indépendant avait rapporté avoir utilisé un framework similaire pour identifier une faille de soundness dans le circuit Orchard de Zcash, corrigée en NU6.2 en juin.
L'analyse d'EF Protocol Security recadre pourtant l'enthousiasme : les agents ne sont pas des chercheurs autonomes. Ils sont des outils de recherche massifs dont la sortie brute — plusieurs centaines à plusieurs milliers de signalements par exécution — n'est actionnable qu'après un tri humain expert. Le rendement de l'exercice, mesuré par le nombre de vraies vulnérabilités trouvées, n'est pas dans la génération : il est dans la capacité à évacuer rapidement le bruit.
Sources primaires : Ethereum Foundation Blog — « The triage is the product » · GHSA-gc42-3jg7-rxr2. Reprise francophone : Cointribune · Coin Academy.