Des milliers de nœuds Bitcoin ont accordé des exemptions de sécurité à des inconnus anonymes

Bitcoin Core a révélé un défaut de configuration le 10 novembre qui a conduit des milliers de nœuds accessibles du réseau principal Bitcoin à traiter les connexions Tor entrantes comme des pairs de confiance, leur accordant des exemptions des limites de déni de service et des protections de la vie privée.

Le projet a évalué la gravité de la vulnérabilité CVE-2025-62860 comme moyenne. Elle a affecté les versions vulnérables lorsque le paramètre -whitelist non par défaut couvrait l'adresse IP du démon Tor du nœud, le logiciel gérant ses connexions Tor. Les nœuds qui n'ont jamais activé ce paramètre n'ont jamais été affectés.

Les correctifs ont été expédiés en octobre 2025. La nouvelle divulgation explique comment une configuration destinée aux connexions de confiance s'est répandue à travers un logiciel groupé et a accordé ces privilèges à des pairs Tor distants.

Pour une connexion Tor entrante, Bitcoin Core voit l'adresse IP du démon Tor plutôt que l'adresse réseau réelle du pair distant. Ce démon fonctionne généralement sur la même machine ou le même réseau local.

Dans les configurations affectées, Core a vérifié cette adresse par rapport à une plage IP marquée comme de confiance. Si la plage incluait le démon, les connexions Tor entrantes héritaient des permissions de la liste blanche. L'adresse locale identifiait l'intermédiaire portant la connexion, mais ne pouvait pas établir quel pair distant méritait confiance.

Comment les pairs Tor ont hérité de la confiance locale

Dans les configurations vulnérables, une liste blanche IP faisait confiance à l'adresse du démon Tor local et passait des exemptions aux pairs distants entrants. REMOTE TOR PEERSABCTor daemonGénéralement sur la même machine ou réseau localAdresse visible : l'adresse IP du démonBitcoin Core reçoit la connexionLes adresses réseau réelles des pairs distants restent dissimulées.Les marqueurs de pairs sont illustratifs, pas un compte de nœuds. REMOTE TOR PEERSABCTor daemonGénéralement sur la même machine ou réseau localCore voit l'adresse IP du démonBitcoin CoreLes IP réelles distantes sont dissimuléesLes marqueurs de pairs sont illustratifs, pas un compte de nœuds.

Qu'est-ce qui change lors de la vérification de confiance

Qu'est-ce qui change lors de la vérification de confianceAvant la correction + liste blanche correspondanteAvec la correction
Une version vulnérable utilisait la plage IP correspondante du démon pour accorder des exemptions de pairs de confiance.
CONFIGURATION VULNÉRABLEL'adresse IP du démon correspond à la liste blanchePlage IP de confiance non par défautAppliquer la confianceExemptions de pairs de confianceDiverses protections contre les DoS / la vie privée levées
CONFIGURATION VULNÉRABLEL'adresse IP du démon correspond à la liste blanchePlage IP de confiance non par défautAppliquer la confianceExemptions de pairs de confianceDiverses protections contre les DoS / la vie privée levées
Les connexions onion entrantes contournent la correspondance de la liste blanche basée sur l'adresse, empêchant cette attribution erronée.
CORE CORRIGÉEConnexion onion entranteLa correspondance d'adresse est ignoréeIgnorer la confiance IPAucun privilège de cette règleL'adresse IP du démon ne peut pas accorder de confiance
CORE CORRIGÉEConnexion onion entranteLa correspondance d'adresse est ignoréeIgnorer la confiance IPAucun privilège de cette règleL'adresse IP du démon ne peut pas accorder de confiance

Le correctif exclut les connexions onion entrantes des attributions de liste blanche basées sur l'adresse.

L'état avant la correction nécessite une version vulnérable et une liste blanche non par défaut correspondant au démon Tor. Le changement concerne les permissions de liste blanche basées sur l'adresse, pas chaque permission de pair possible.
Sources et preuves

Sources

1. Divulgation de Bitcoin Core
2. Correctif Bitcoin Core #33395

Faits supplémentaires

• Sur les versions vulnérables de Bitcoin Core, le défaut a affecté les nœuds dont la plage IP de liste blanche non par défaut correspondait à l'adresse de leur démon Tor. [1]
• Pour les connexions Tor entrantes, Bitcoin Core voit l'adresse IP du démon Tor, généralement sur la même machine ou le même réseau local, plutôt que l'adresse réseau réelle du pair distant. [1] [2]
• Le paramètre -whitelist exonère les pairs de confiance de diverses limites de déni de service et de mesures d'atténuation des fuites de vie privée ; la correspondance de l'adresse du démon Tor a par erreur étendu ces privilèges aux pairs Tor entrants. [1]
• Le correctif empêche les permissions de liste blanche basées sur l'adresse d'être appliquées aux connexions onion entrantes car leurs adresses réseau distantes ne sont pas révélées. [2] [1]

Méthode

Chemin de connexion qualitatif plus deux états rapportés. Les marqueurs de pairs illustrent plusieurs connexions distantes et n'encode aucun compte ou échelle.

Portée

L'état avant la correction nécessite une version vulnérable et une liste blanche non par défaut correspondant au démon Tor. Le changement concerne les permissions de liste blanche basées sur l'adresse, pas chaque permission de pair possible.
Infographie par CryptoSlate

Cette distinction est importante car -whitelist lève diverses limites destinées à restreindre le comportement de déni de service, ainsi que des mesures contre les fuites de vie privée. Le problème concernait les exemptions accordées aux pairs réseau ; les privilèges décrits dans la divulgation n'établissent pas l'accès au portefeuille ou le vol de pièces.

Bitcoin Core indique que des fournisseurs populaires ont groupé le logiciel de nœud avec Tor et une plage de liste blanche correspondante. Certains logiciels clients nécessitaient également une liste blanche et fonctionnaient souvent aux côtés de Tor. Ensemble, ces configurations ont conduit des milliers de nœuds accessibles du réseau principal à mettre sur liste blanche chaque connexion Tor entrante.

C'est la découverte historique de l'exposition de l'avis, pas un compte de nœuds encore vulnérables aujourd'hui.

Martin Zumsande et Antoine Poinsot ont signalé le problème en septembre 2025. Le correctif a été fusionné le 17 septembre et a cessé d'appliquer les permissions de liste blanche basées sur l'adresse aux connexions onion entrantes, dont les adresses réseau distantes sont dissimulées.

Bitcoin Core 30.0, 29.2 et 28.3 ont expédié le correctif en octobre 2025. Le correctif est présent dans toutes les versions à partir de 30.0, ainsi que dans les versions mineures ultérieures des branches fixes 28.x et 29.x.

Ce que les opérateurs de nœuds devraient vérifier maintenant

Ces seuils de correctifs plus anciens sont distincts des conseils de mise à niveau d'aujourd'hui. Le calendrier de maintenance de Bitcoin Core couvre désormais 30.x, 31.x et 32.x ; 28.x et 29.x ont atteint leur fin de vie. Le projet recommande la dernière version de maintenance de la nouvelle version majeure qu'un opérateur peut adopter. Sa page de téléchargement indique 32.1 comme la dernière version au 11 novembre.

Pour les opérateurs utilisant un logiciel de nœud empaqueté, vérifiez la version de Bitcoin Core réellement en cours d'exécution et si sa plage de liste blanche inclut l'adresse du démon Tor.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.