Miles de nodos de Bitcoin dieron a extraños anónimos un pase alrededor de los límites de seguridad

Bitcoin Core divulgó un fallo de configuración el 10 de noviembre que hizo que miles de nodos alcanzables de la red principal de Bitcoin trataran las conexiones entrantes de Tor como pares de confianza, otorgándoles exenciones de los límites de denegación de servicio y protecciones de privacidad.

El proyecto calificó el CVE-2025-62860 como de severidad media. Afectó a versiones vulnerables cuando una configuración -whitelist no predeterminada cubría la dirección IP del daemon Tor del nodo, el software que maneja sus conexiones Tor. Los nodos que nunca habilitaron esa configuración nunca se vieron afectados.

Las correcciones se enviaron en octubre de 2025. La nueva divulgación explica cómo una configuración destinada a conexiones de confianza se propagó a través del software empaquetado y otorgó esos privilegios a pares remotos de Tor.

Para una conexión entrante de Tor, Bitcoin Core ve la dirección IP del daemon Tor en lugar de la dirección de red real del par remoto. Ese daemon generalmente se ejecuta en la misma máquina o red local.

En configuraciones afectadas, Core verificó esa dirección contra un rango de IP marcado como de confianza. Si el rango incluía el daemon, las conexiones entrantes de Tor heredaban los permisos de la lista blanca. La dirección local identificó al intermediario que llevaba la conexión, pero no pudo establecer qué par remoto merecía confianza.

Cómo los pares de Tor heredaron la confianza local

En configuraciones vulnerables, una lista blanca de IP confiaba en la dirección del daemon Tor local y pasaba exenciones a los pares remotos entrantes.
PEERS REMOTOS DE TORABCTor daemonGeneralmente en la misma máquina o red localIP visible: la dirección del daemonBitcoin Core recibe la conexiónLas direcciones de red reales de los pares remotos permanecen ocultas.Los marcadores de pares son ilustrativos, no un conteo de nodos.
PEERS REMOTOS DE TORABCTor daemonGeneralmente en la misma máquina o red localCore ve la IP del daemonBitcoin CoreLas IPs remotas reales están ocultasLos marcadores de pares son ilustrativos, no un conteo de nodos.

Qué cambia en la verificación de confianza

Qué cambia en la verificación de confianzaAntes de la corrección + lista blanca coincidenteCon la corrección
Una versión vulnerable utilizó el rango de IP coincidente del daemon para otorgar exenciones de pares de confianza.
CONFIGURACIÓN VULNERABLELa IP del daemon coincide con la lista blancaRango de IP de confianza no predeterminadoAplicar confianzaExenciones de pares de confianzaSe levantaron varias salvaguardias de DoS / privacidad
CONFIGURACIÓN VULNERABLELa IP del daemon coincide con la lista blancaRango de IP de confianza no predeterminadoAplicar confianzaExenciones de pares de confianzaSe levantaron varias salvaguardias de DoS / privacidad
Las conexiones de cebolla entrantes evitan la coincidencia de la lista blanca basada en direcciones, previniendo esta concesión errónea.
CORE CORREGIDOConexión de cebolla entranteSe omite la coincidencia de direccionesOmitir confianza IPSin privilegios de esta reglaLa IP del daemon no puede otorgar confianza
CORE CORREGIDOConexión de cebolla entranteSe omite la coincidencia de direccionesOmitir confianza IPSin privilegios de esta reglaLa IP del daemon no puede otorgar confianza

El parche excluye las conexiones de cebolla entrantes de las concesiones de lista blanca basadas en direcciones.

El estado anterior a la corrección requiere una versión vulnerable y una lista blanca no predeterminada que coincida con el daemon Tor. El cambio concierne a los permisos de lista blanca basados en direcciones, no a cada posible permiso de par.
Fuentes y evidencia

Fuentes

1. Divulgación de Bitcoin Core
2. Parche de Bitcoin Core #33395

Hechos de apoyo

• En versiones vulnerables de Bitcoin Core, el fallo afectó a nodos cuyo rango de IP de lista blanca no predeterminada coincidía con la dirección de su daemon Tor. [1]
• Para conexiones entrantes de Tor, Bitcoin Core ve la dirección IP del daemon Tor, generalmente en la misma máquina o red local, en lugar de la dirección de red real del par remoto. [1] [2]
• La configuración de -whitelist exime a los pares de confianza de varios límites de denegación de servicio y mitigaciones de fugas de privacidad; coincidir con la dirección del daemon Tor extendió erróneamente esos privilegios a los pares de Tor entrantes. [1]
• El parche detiene la aplicación de permisos de lista blanca basados en direcciones a conexiones de cebolla entrantes porque sus direcciones de red remotas no se revelan. [2] [1]

Método

Ruta de conexión cualitativa más dos estados reportados. Los marcadores de pares ilustran múltiples conexiones remotas y no codifican ningún conteo o escala.

Alcance

El estado anterior a la corrección requiere una versión vulnerable y una lista blanca no predeterminada que coincida con el daemon Tor. El cambio concierne a los permisos de lista blanca basados en direcciones, no a cada posible permiso de par.
Infografía por CryptoSlate

Esa distinción es importante porque -whitelist levanta varios límites destinados a restringir el comportamiento de denegación de servicio, junto con mitigaciones contra fugas de privacidad. El problema concernía a las exenciones otorgadas a los pares de red; los privilegios descritos en la divulgación no establecen acceso a la billetera ni robo de monedas.

Bitcoin Core dice que los proveedores populares empaquetaron el software del nodo con Tor y un rango de lista blanca coincidente. Algunos software de cliente también requerían lista blanca y generalmente se ejecutaban junto a Tor. Juntas, estas configuraciones llevaron a que miles de nodos alcanzables de la red principal incluyeran cada conexión de Tor entrante en la lista blanca.

Esa es la conclusión histórica de la exposición del aviso, no un conteo de nodos que aún son vulnerables hoy.

Martin Zumsande y Antoine Poinsot reportaron el problema en septiembre de 2025. El parche se fusionó el 17 de septiembre y dejó de aplicar permisos de lista blanca basados en direcciones a conexiones de cebolla entrantes, cuyas direcciones de red remotas están ocultas.

Bitcoin Core 30.0, 29.2 y 28.3 enviaron la corrección en octubre de 2025. La corrección está presente en todas las versiones desde 30.0 en adelante, así como en lanzamientos menores posteriores en las ramas corregidas 28.x y 29.x.

Qué deben verificar ahora los operadores de nodos

Esos umbrales de parches más antiguos son distintos de la guía de actualización de hoy. El cronograma de mantenimiento de Bitcoin Core ahora cubre 30.x, 31.x y 32.x; 28.x y 29.x han llegado al final de su vida útil. El proyecto recomienda la última versión de mantenimiento de la versión principal más nueva que un operador pueda adoptar. Su página de descarga lista 32.1 como la más reciente a partir del 11 de noviembre.

Para los operadores que utilizan software de nodo empaquetado, verifiquen la versión de Bitcoin Core que realmente se está ejecutando y si su rango de lista blanca incluye la dirección del daemon Tor.

Este contenido se ofrece únicamente con fines informativos generales y no constituye asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, tradear o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.