Bitcoin Core : une proposition pour corriger vite les failles faciles

La pull request n° 1281 crée une catégorie de failles faciles à découvrir

Le contributeur darosior a ouvert le 16 octobre 2026 la pull request n° 1281, intitulée « Update security policy for easy-to-find vulnerabilities », sur le dépôt du site bitcoincore.org. Une pull request est une demande de modification soumise à la relecture des autres développeurs.

Selon la description de la pull request n° 1281, une faille pourra être classée « facile à découvrir » lors du tri des signalements. Le texte vise en pratique les failles repérables par « une simple requête à un LLM » (traduit de l'anglais), mais précise que la catégorie ne se limite pas à ces cas, sans en détailler les critères.

Pour ces failles, la proposition de darosior prévoit trois engagements : rétroporter le correctif, c'est-à-dire l'appliquer aussi aux anciennes versions, dans toutes les versions encore maintenues ; publier une version corrigée « dès que possible » ; accompagner cette version d'un avis de sécurité donnant certains détails sur la faille.

La proposition attribue aux LLM une hausse des signalements

Le contributeur darosior explique le changement par une hausse du nombre de signalements de failles faciles à découvrir ou à redécouvrir. Il l'attribue en grande partie aux LLM, qui abaissent « drastiquement » le niveau requis pour trouver certaines catégories de failles ou repérer des correctifs discrets (traduit de l'anglais). La description ne chiffre ni les signalements ni cette hausse.

La politique de sécurité en vigueur, selon la description de la pull request, privilégie une période d'embargo plus longue, pendant laquelle la faille reste confidentielle, en raison d'une « culture de mise à jour lente » (traduit de l'anglais). En pratique, les correctifs ne peuvent généralement pas être rétroportés et n'arrivent qu'avec la version majeure suivante.

Pour les failles faciles à trouver, la description qualifie cet arbitrage de « mauvais compromis » : l'embargo « n'apporte pas grand-chose » mais retarde la disponibilité d'une version corrigée (traduit de l'anglais).

La politique de sécurité du dépôt bitcoin/bitcoin renvoie au site bitcoincore.org pour la liste des versions de Bitcoin Core qui reçoivent des mises à jour de sécurité.

Cinq contributeurs approuvent le principe, le moment de l'alerte reste discuté

Cinq contributeurs ont donné un « Concept ACK », c'est-à-dire une approbation du principe et non du texte final : sedited, instagibbs, fanquake et vincenzopalazzo le jour de l'ouverture, puis stickies-v le 19 octobre 2026.

Donnée	Valeur	Date	Source
Pull request ouverte sur le dépôt bitcoincore.org	n° 1281	16 octobre 2026	Pull request n° 1281, GitHub
Approbations de principe (« Concept ACK »)	5	16 et 19 octobre 2026	Pull request n° 1281, GitHub
Échanges sur le moment de l'alerte	stickies-v, darosior	20 octobre 2026	Pull request n° 1281, GitHub
Proposition de procédure dérogatoire	ariard	22 octobre 2026	Pull request n° 1281, GitHub
Remaniement du texte de la proposition	darosior	22 octobre 2026	Pull request n° 1281, GitHub

Le contributeur stickies-v a estimé le 20 octobre 2026 qu'il serait peut-être préférable de divulguer la faille au plus tard à l'ouverture de la pull request de correction. Le contributeur darosior a répondu que, sous le niveau de gravité « critique », alerter avant une version corrigée « ferait plus de mal que de bien » (traduit de l'anglais).

Le contributeur darosior a aussi écrit le 20 octobre 2026 que, sous cette politique, les correctifs auraient moins de temps de « maturation » dans les branches de développement avant leur diffusion aux utilisateurs (traduit de l'anglais).

Le contributeur ariard a proposé le 22 octobre 2026 une procédure « dérogatoire » dans laquelle l'avis de sécurité pourrait être publié ou non au moment du correctif. Le contributeur darosior a jugé cette option « une mauvaise idée » (traduit de l'anglais).

Le même jour, darosior a remanié le texte de la pull request pour intégrer la catégorie « facilement découvrable » au paragraphe existant de la page des avis de sécurité, plutôt que de l'ajouter à la fin.

À lire aussi : Electrum 4.8.3 corrige une faille.

Questions fréquentes

Que prévoit la pull request n° 1281 de Bitcoin Core pour les failles faciles à découvrir ?

Selon la description de la pull request n° 1281 ouverte le 16 octobre 2026 par darosior, une faille classée « facile à découvrir » aurait son correctif rétroporté dans toutes les versions maintenues. Une version serait publiée dès que possible, avec un avis de sécurité donnant certains détails.

Pourquoi Bitcoin Core veut-il changer sa politique de sécurité pour les failles faciles à trouver ?

Selon la description de la pull request n° 1281 du 16 octobre 2026, darosior constate une hausse des signalements de failles faciles à (re)découvrir, due en grande partie aux LLM. Il juge l'embargo actuel un mauvais compromis : il apporte peu et retarde la version corrigée.

Que dit la politique de sécurité actuelle de Bitcoin Core sur les embargos et les correctifs ?

Selon la description de la pull request n° 1281 (16 octobre 2026), la politique en vigueur privilégie un embargo plus long, en raison d'une culture de mise à jour lente. Les correctifs ne peuvent généralement pas être rétroportés et n'arrivent qu'avec la version majeure suivante.

Pourquoi darosior refuse-t-il d'alerter les utilisateurs avant la publication d'un correctif pour Bitcoin Core ?

Dans la discussion de la pull request n° 1281, darosior a écrit le 20 octobre 2026 que, sous le niveau de gravité « critique », alerter avant une version corrigée « ferait plus de mal que de bien » (traduit de l'anglais). Pour le niveau critique, le traitement reste ad hoc.