Bitcoin Core accélère les correctifs des failles faciles à découvrir

Bitcoin Core change sa politique pour les failles faciles à découvrir

Antoine Poinsot a annoncé sur la liste de diffusion Bitcoin-Dev une modification de la politique de sécurité de Bitcoin Core, selon la lettre Bitcoin Optech n° 429 du 30 octobre 2026. La mesure vise les vulnérabilités que le projet classe comme faciles à découvrir, « such as those found with a simple prompt to a large language model » (comme celles obtenues par une simple requête à un grand modèle de langage, traduit de l'anglais).

Selon Optech, Bitcoin Core reçoit davantage de signalements de ce type de bogue. Ces failles peuvent être retrouvées par d'autres personnes ou déduites de correctifs publiés sans annonce.

La politique de Bitcoin Core prévoyait jusqu'ici d'attendre la version majeure suivante et d'appliquer un embargo fondé sur la gravité de la faille. Pour les failles faciles à découvrir, le projet reporte désormais le correctif dans chaque version maintenue, sort des versions correctives au plus vite et les accompagne d'un avis de sécurité.

Trois failles corrigées dans Bitcoin Core 32.1, 31.2, 30.4 et 29.5

Bitcoin Core #36665, #36667 et #36669 sont trois vulnérabilités divulguées sous cette nouvelle classification, d'après Optech. Leurs correctifs ont été fusionnés après le marquage de la version 32.0, si bien que celle-ci n'a jamais été publiée ; les versions suivantes les contiennent.

Donnée	Valeur	Date	Source
Versions de Bitcoin Core contenant les trois correctifs	32.1, 31.2, 30.4 et 29.5	30 octobre 2026	Lettre Bitcoin Optech n° 429
Délai avant déconnexion d'un pair (#36667)	plus de 20 minutes au-delà de la limite du tampon d'envoi	30 octobre 2026	Lettre Bitcoin Optech n° 429
Taille de fichier d'annulation provoquant le débordement (#36669)	4 GiB	30 octobre 2026	Lettre Bitcoin Optech n° 429
Seuil pouvant arrêter un nœud sous Windows sans réorganisation (#36669)	2 GiB	30 octobre 2026	Lettre Bitcoin Optech n° 429

Bitcoin Core #36665 corrige un épuisement de mémoire : un pair connecté pouvait faire planter les nœuds sous Windows, macOS ou BSD. Linux, qui s'appuie sur un autre mécanisme de gestion des connexions réseau, n'était pas touché.

Bitcoin Core #36667 ajoute un délai de déconnexion pour les pairs dont le tampon d'envoi dépasse durablement sa limite. Le but est de contenir une hausse de la mémoire utilisée sans plafond.

Bitcoin Core #36669 corrige le débordement des fichiers d'annulation, qui servent à défaire des blocs lors d'une réorganisation de la chaîne. La divulgation citée par Optech juge l'exploitation impraticable, car elle suppose de miner des milliers de blocs construits à cet effet. Les nœuds sur systèmes 32 bits ou sur stockage FAT32 restent concernés.

Optech précise que les versions 29.x et antérieures de Bitcoin Core sont arrivées en fin de cycle de vie et ne recevront plus de mises à jour.

Core Lightning 26.04.1 corrige un déni de service par annonce de canal

Nishant Bansal a divulgué sur le forum Delving Bitcoin un déni de service (DoS), une attaque qui rend un service indisponible, dans Core Lightning (CLN) des versions 25.02 à 26.04. Le logiciel ne vérifiait pas que les deux identifiants de nœud d'une annonce de canal étaient différents, ce qui faisait planter le nœud.

Selon Optech, le message enregistré par CLN provoquait un nouveau plantage à chaque redémarrage du nœud, tant que l'opérateur ne le supprimait pas manuellement. La mise à jour seule ne l'effaçait pas.

Pour Optech, l'attaque ne coûtait que des frais de transaction sur la chaîne : il suffisait de financer une sortie multisignature 2-sur-2 contrôlée par l'attaquant, puis de signer l'annonce. Les anciennes versions de CLN relayaient cette annonce sans planter, jusqu'à des nœuds vulnérables que l'attaquant ne pouvait pas joindre directement.

La faille a été divulguée de manière responsable en avril, puis corrigée dans CLN 26.04.1 par la modification Core Lightning #9082, qui rejette toute annonce dont les identifiants ne sont pas strictement ordonnés. Optech écrit que les opérateurs restés sur une version affectée « should upgrade to the latest release » (devraient passer à la dernière version, traduit de l'anglais).

La spécification BOLT7 du réseau Lightning impose désormais aussi cette vérification au récepteur, avec la modification BOLTs #1333 ; jusque-là, seuls les émetteurs devaient ordonner les identifiants.

Questions fréquentes

Quelle est la nouvelle politique de sécurité de Bitcoin Core pour les failles faciles à découvrir ?

Selon la lettre Bitcoin Optech n° 429 du 30 octobre 2026, Antoine Poinsot a annoncé sur la liste Bitcoin-Dev que Bitcoin Core a modifié sa politique de sécurité pour les vulnérabilités classées comme faciles à découvrir, par exemple celles trouvées avec une simple requête à un grand modèle de langage. Au lieu d'attendre la version majeure suivante et l'embargo fondé sur la gravité, le projet reporte désormais le correctif dans chaque version maintenue, publie des versions correctives dès que possible et les accompagne d'un avis de sécurité. Optech indique que le projet reçoit davantage de signalements de ce type de bogue.

Quelles versions de Bitcoin Core contiennent les correctifs des failles #36665, #36667 et #36669 ?

D'après la lettre Bitcoin Optech n° 429 du 30 octobre 2026, les correctifs des trois vulnérabilités (Bitcoin Core #36665, #36667 et #36669) figurent dans Bitcoin Core 32.1, 31.2, 30.4 et 29.5. Ils ont été fusionnés après le marquage de la version 32.0, qui n'a donc jamais été publiée. Optech précise que les versions 29.x et antérieures ont atteint la fin de leur cycle de vie et ne recevront plus de mises à jour. Les versions 31.2, 30.4 et 29.5 sont décrites comme des versions de maintenance incluant les mêmes trois correctifs de sécurité que la 32.1.

Que corrigent les failles Bitcoin Core #36665, #36667 et #36669 ?

Selon la lettre Bitcoin Optech n° 429 du 30 octobre 2026, #36665 corrige un épuisement de mémoire permettant à un pair connecté de faire planter des nœuds sous Windows, macOS ou BSD ; Linux n'était pas touché. #36667 ajoute un délai de déconnexion d'un pair si le tampon d'envoi dépasse sa limite pendant plus de 20 minutes, afin de contenir une croissance de mémoire sans plafond. #36669 corrige un débordement de fichier d'annulation au-delà de 4 GiB, pouvant corrompre des données nécessaires lors d'une réorganisation. La divulgation citée par Optech juge son exploitation impraticable, car elle exige de miner des milliers de blocs spécifiques.

Quelle faille de déni de service a été corrigée dans Core Lightning 26.04.1 ?

Selon la lettre Bitcoin Optech n° 429 du 30 octobre 2026, Nishant Bansal a divulgué sur Delving Bitcoin un déni de service touchant Core Lightning (CLN) des versions 25.02 à 26.04. Le logiciel ne vérifiait pas que les deux identifiants de nœud d'une annonce de canal étaient différents, ce qui faisait planter le nœud, et de nouveau à chaque redémarrage tant que l'opérateur ne supprimait pas le message à la main. La faille a été divulguée de manière responsable en avril et corrigée dans CLN 26.04.1 par Core Lightning #9082, qui rejette toute annonce dont les identifiants ne sont pas strictement ordonnés. Optech précise que la spécification BOLT7 impose désormais cette vérification au récepteur.