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 gravedad media. Afectó a las versiones vulnerables cuando una configuración -whitelist no predeterminada cubría la dirección IP del daemon de 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 de 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 de 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 identificaba el intermediario que llevaba la conexión, pero no podía 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 local de Tor y pasaba exenciones a los pares remotos entrantes.
PEERS REMOTOS DE TOR
DAEMON DE TOR
Generalmente en la misma
máquina o red local
IP visible: la dirección IP del daemon
Bitcoin Core recibe la conexión
Las direcciones de red reales de los pares remotos permanecen ocultas.
Los 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 confianza
Antes de la corrección + lista blanca coincidente
Con la corrección
Una versión vulnerable utilizó el rango de IP coincidente del daemon para otorgar exenciones de pares de confianza.
CONFIGURACIÓN VULNERABLE
La IP del daemon coincide con la lista blanca
Rango de IP de confianza no predeterminado
Aplicar confianza
Exenciones de pares de confianza
Se levantaron varias salvaguardas de DoS / privacidad
CONFIGURACIÓN VULNERABLE
La IP del daemon coincide con la lista blanca
Rango de IP de confianza no predeterminado
Aplicar confianza
Exenciones de pares de confianza
Se levantaron varias salvaguardas 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 CORREGIDO
Conexión de cebolla entrante
Se omite la coincidencia de direcciones
Omitir confianza IP
Sin privilegios de esta regla
La IP del daemon no puede otorgar confianza
CORE CORREGIDO
Conexión de cebolla entrante
Se omite la coincidencia de direcciones
Omitir confianza IP
Sin privilegios de esta regla
La 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 de Tor. El cambio se refiere a los permisos de lista blanca basados en direcciones, no a todos los permisos de pares posibles.
Fuentes y evidencia

Fuentes

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

Hechos de apoyo

• En las versiones vulnerables de Bitcoin Core, el fallo afectó a los nodos cuyo rango de IP de lista blanca no predeterminada coincidía con la dirección de su daemon de Tor. [1]
• Para las conexiones entrantes de Tor, Bitcoin Core ve la dirección IP del daemon de 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 filtraciones de privacidad; coincidir con la dirección del daemon de 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 las 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 de Tor. El cambio se refiere a los permisos de lista blanca basados en direcciones, no a todos los permisos de pares posibles.
Infografía de 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 filtraciones de privacidad. El problema se refería a las exenciones otorgadas a los pares de red; los privilegios descritos en la divulgación no establecen acceso a billeteras 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 listas blancas y generalmente se ejecutaban junto a Tor. Juntas, estas configuraciones llevaron a que miles de nodos alcanzables de la red principal incluyeran en la lista blanca cada conexión de Tor entrante.

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 informaron sobre 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 las 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 las versiones 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 calendario 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 reciente que un operador pueda adoptar. Su página de descarga enumera 32.1 como la más reciente a partir del 11 de noviembre.

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

Este contenido se ofrece únicamente con fines informativos generales y no constituye un 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, operar 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.