Vulnerabilidad de Tor en Bitcoin Core: miles de nodos trataban a desconocidos como de confianza

Bitcoin Core divulgó el 10 de noviembre de 2026 otras tres vulnerabilidades de seguridad. La de mayores consecuencias afecta a los nodos que ejecutan Bitcoin Core junto con el servicio de anonimato Tor: quien había activado la opción -whitelist para un rango de IP trataba también, hasta las versiones 28.3, 29.2 y 30.0, cualquier conexión entrante por Tor como un par de confianza. Según los desarrolladores, el fallo afectó a miles de nodos accesibles en la red principal. Los tres errores están corregidos desde hace más de un año, y quien mantiene su nodo actualizado está protegido. Quien todavía use una versión anterior a la 30.0 debería actualizar ahora, porque la serie 29.x, la última afectada, dejó de recibir mantenimiento el 27 de octubre.

Bitcoin Core es el software de referencia de la red Bitcoin. Un nodo es un ordenador que ejecuta este software, verifica por sí mismo cada bloque y retransmite las transacciones a otros nodos. Quien opera su propio nodo no depende de servidores ajenos para conocer su saldo. Cuánto esfuerzo y electricidad supone lo hemos calculado en nuestra guía cómo ejecutar un nodo de Bitcoin.

Bitcoin Core: tres divulgaciones el 10 de noviembre

Los tres avisos llevan los identificadores CVE-2025-62859, CVE-2025-62860 y CVE-2025-62861. Un número CVE (Common Vulnerabilities and Exposures) es un identificador único a escala mundial para una vulnerabilidad conocida. Bitcoin Core califica dos de los tres fallos como de gravedad media y uno como grave. El calendario sigue la política de divulgación del proyecto: una vulnerabilidad solo se describe públicamente cuando la última serie de versiones afectada deja de recibir mantenimiento.

Ese umbral se alcanzó el 27 de octubre de 2026. Ese día terminó el mantenimiento de Bitcoin Core 29.x, tras la publicación de la versión 32.1 el mismo 27 de octubre. El 28 de octubre llegaron las versiones de mantenimiento 31.2, 30.4 y 29.5, y ese mismo día el proyecto ya divulgó otros tres fallos, sobre los que informamos en nuestro artículo tres vulnerabilidades en Bitcoin Core. Los nuevos avisos son la segunda ronda en dos semanas, aunque afectan a otras partes del software.

Los tres casos tienen en común que fueron desarrolladores externos quienes encontraron los fallos y los comunicaron de forma confidencial a la lista de seguridad del proyecto. Las correcciones se incorporaron discretamente a las versiones 28.3, 29.2 y 30.0, publicadas entre el 10 y el 20 de octubre de 2025. Solo ahora, algo más de un año después, se describen públicamente.

Lista blanca de Tor en Bitcoin Core: por qué las conexiones Tor eran de confianza

El fallo con el identificador CVE-2025-62860 reside en un ajuste que muchos usuarios domésticos nunca configuraron por sí mismos. Con -whitelist, un operador marca determinados pares como de confianza. Para ellos, según el aviso de seguridad del proyecto, Bitcoin Core suprime varios límites contra ataques de saturación y relaja medidas de protección pensadas para evitar que salga al exterior información sobre el nodo. Está concebido para dispositivos propios de la red doméstica, como un segundo ordenador o un software de wallet que se comunica directamente con el nodo.

El problema nace de la forma en que Tor entrega las conexiones. Un ordenador ajeno que llega a un nodo a través de Tor no aparece ante Bitcoin Core con su propia dirección. Solo se ve la dirección del servicio Tor, que suele funcionar en el mismo equipo o en la misma red doméstica. Si esa dirección estaba dentro del rango de IP que el operador había autorizado con -whitelist, cualquier conexión entrante por Tor acababa en la lista de pares de confianza. Un participante cualquiera de internet obtenía así los mismos derechos que el propio dispositivo del salón.

El fallo está corregido en Bitcoin Core 30.0 y en todas las versiones posteriores, así como a partir de las versiones de mantenimiento 28.3 y 29.2. Desde entonces, las conexiones Tor entrantes que llegan por una dirección configurada expresamente para Tor (onion bind) nunca reciben derechos de lista blanca. Los nodos que nunca activaron la opción -whitelist no se vieron afectados en ningún momento, según los desarrolladores.

Descubrieron la vulnerabilidad los desarrolladores de Bitcoin Core Martin Zumsande y Antoine Poinsot, que la comunicaron al equipo de seguridad el 12 de septiembre de 2025. La corrección se integró el 17 de septiembre de 2025 y se trasladó a las series de versiones anteriores. Ese mismo día, según el aviso, Poinsot informó también a Luke Dashjr, que mantiene el software de nodo alternativo Bitcoin Knots, y el 19 de septiembre a varios proveedores de software afectados.

Nodos Bitcoin todo en uno: de dónde salían los miles de nodos afectados

El amplio alcance de la vulnerabilidad se debió a una costumbre del sector. Según el aviso de seguridad, proveedores muy extendidos distribuían Bitcoin Core junto con un servicio Tor y fijaban de fábrica la opción -whitelist en un rango de IP en el que también se encontraba el servicio Tor. A ello se sumaba que el software adicional que funciona sobre Bitcoin Core exigía el ajuste de lista blanca para operar, y esos programas suelen ejecutarse junto a un servicio Tor. Los desarrolladores describen así el resultado: miles de nodos accesibles en la red principal incluían en la lista blanca cualquier conexión Tor entrante.

Para muchos usuarios domésticos el escenario resulta familiar. Los paquetes de nodo listos para pequeños ordenadores reúnen Bitcoin Core, Tor, un servidor para las consultas de la wallet y a menudo también software de Lightning bajo una interfaz gráfica. El usuario rara vez llega a ver el archivo de configuración. El aviso no indica si un paquete concreto estaba afectado; los fabricantes fueron informados hace algo más de un año. Quien utilice uno de estos paquetes suele encontrar la versión de Bitcoin Core instalada en el resumen de aplicaciones o en las notas de versión del paquete.

Conviene distinguir entre el paquete y la versión de Bitcoin Core que contiene. Un paquete puede estar recién actualizado y aun así incluir una versión antigua de Bitcoin Core si esa aplicación concreta no se ha puesto al día. Para las tres vulnerabilidades, lo único determinante es el número de versión de Bitcoin Core.

CVE-2025-62859 en Bitcoin Core: Compact Blocks y la espera de diez minutos

La segunda vulnerabilidad de gravedad media afecta a la manera en que los nodos intercambian nuevos bloques de forma eficiente. Compact Blocks es un procedimiento en el que un nodo no transmite el bloque completo, sino solo identificadores cortos de las transacciones que contiene. El receptor reconstruye el bloque con transacciones que ya guarda en su memoria intermedia. Así se ahorra ancho de banda y se acelera la propagación de los nuevos bloques por la red.

Bitcoin Core, en versiones anteriores a la 29.2 y la 30.0, limpiaba su estado de descarga tras reconstruir un bloque de este tipo antes de comprobar una manipulación concreta de los datos de firma (witness malleation). Si esa comprobación fallaba, el nodo volvía a solicitar el bloque, y lo hacía al mismo par, con un tiempo de espera de diez minutos. Un atacante que anunciara primero un bloque nuevo a un nodo podía así frenar el procesamiento de bloques de ese nodo.

Según el aviso, el ataque podía repetirse indefinidamente en dos supuestos: si el atacante controlaba los tres pares que el nodo utiliza para la transmisión rápida de bloques, o si el nodo funcionaba en modo -blocksonly, es decir, retransmitiendo solo bloques y no transacciones sueltas. Descubrió el fallo el desarrollador Eugene Siegel, que lo comunicó el 28 de abril de 2025. La corrección de Gregory Sanders se incorporó el 30 de junio de 2025.

Para un nodo doméstico, una paralización así significa sobre todo que se queda rezagado respecto a los nuevos bloques. La wallet conectada a él muestra entonces los pagos entrantes con retraso. Quien recibe bitcoin y confirma la entrada a través de su propio nodo ve, en el peor de los casos, un estado desfasado.

CVE-2025-62861: las transacciones TRUC bloquean a los mineros tras una reorganización

La única vulnerabilidad calificada como grave afecta sobre todo a los mineros. TRUC significa Topologically Restricted Until Confirmation y designa las transacciones de la versión 3 según BIP 431. Hasta su confirmación se les aplican reglas más estrictas: como máximo un antecesor sin confirmar y como máximo un sucesor sin confirmar. Estas reglas rigen solo para la memoria intermedia de un nodo (mempool), no para las reglas de consenso. Un bloque válido puede, por tanto, estar construido de otra manera.

Desde la versión 28.0, Bitcoin Core aplica a estas transacciones una regla de sustitución, la llamada sibling eviction. Si una transacción TRUC recibe un segundo hijo sin confirmar, el nuevo hijo desplaza al antiguo cuando paga comisión suficiente. En una reorganización, es decir, cuando un nodo pasa a una secuencia de bloques rival más larga, Bitcoin Core devuelve a la mempool las transacciones de los bloques descartados. En ese proceso, la regla de desplazamiento seguía aplicándose por error.

La consecuencia, según el aviso: en la mempool quedaban transacciones que gastaban salidas que ya no existían allí. Un minero cuyo nodo sufría una reorganización de este tipo no podía crear una plantilla de bloque válida hasta reiniciar el nodo. Están afectadas las versiones 28.0 a 28.2 y 29.0 a 29.1; el fallo está corregido en Bitcoin Core 30.0, del 10 de octubre de 2025. Lo comunicó Niklas Gögge el 26 de septiembre de 2025.

Gravedad alta y media: la clasificación de las vulnerabilidades de Bitcoin Core

Bitcoin Core asigna cada vulnerabilidad comunicada a una de cuatro categorías, que el proyecto describe en su página de avisos de seguridad. Se consideran críticos los fallos que amenazan la seguridad de toda la red, como el robo de monedas a nivel de protocolo, la creación de monedas fuera del calendario de emisión fijado o una división permanente de la red. Ninguna de las tres nuevas vulnerabilidades entra en esta categoría.

Son graves (High) los fallos con un efecto considerable sobre los nodos afectados o sobre la red, que normalmente pueden explotarse a distancia y con la configuración por defecto. Son de gravedad media (Medium) los fallos que reducen de forma apreciable el rendimiento o el funcionamiento, pero cuyo alcance o explotabilidad es limitado. En el caso de la vulnerabilidad de Tor, eso significa que el fallo solo actuaba con la lista blanca activada, pero entonces en muchísimos nodos a la vez.

La clasificación ayuda a valorar la urgencia de una actualización. Un nodo doméstico que no produce bloques apenas se ve afectado por la vulnerabilidad grave de TRUC, porque esta incide en la creación de plantillas de bloque. Para los usuarios domésticos, las dos vulnerabilidades de gravedad media son las más relevantes, ya que afectan a la privacidad y a la disponibilidad del propio nodo.

Bitcoin Core 29.x sin mantenimiento: sin parches de seguridad desde el 27 de octubre

Según su propia política de ciclo de vida, el proyecto mantiene siempre las tres versiones principales más recientes. Desde la versión 32.0 son la 32.x, la 31.x y la 30.x. Las versiones principales que salen de esa ventana dejan, por regla general, de recibir correcciones de seguridad. Las versiones actuales son la 32.1, del 27 de octubre, y la 31.2 y la 30.4, del 28 de octubre de 2026.

Quien aún utiliza una versión 29 dispone, para las tres nuevas vulnerabilidades, de una versión corregida con la 29.5, pero ya no recibirá más correcciones en el futuro. Por eso, el camino más limpio es pasar a una versión principal con mantenimiento. Antes de un salto de versión importante conviene leer las notas de la versión, porque la configuración por defecto puede cambiar.

La versión instalada la muestra el comando bitcoin-cli --version o la salida de bitcoin-cli getnetworkinfo en el campo subversion, donde aparece, por ejemplo, /Satoshi:30.4.0/. En la interfaz gráfica Bitcoin-Qt encontrarás el dato en Ayuda e Información. En los paquetes todo en uno suele figurar en el resumen de las aplicaciones instaladas.

Lista blanca de Bitcoin Core en bitcoin.conf: las líneas que llaman la atención

Con independencia de la versión, vale la pena revisar el archivo de configuración bitcoin.conf. Las líneas que empiezan por whitelist= otorgan derechos especiales a los pares. Si aparece un rango de IP completo, por ejemplo una red del router doméstico o una red interna de contenedores, deberías saber qué dispositivos están dentro y si incluye un servicio Tor. Quien no haya creado el archivo por sí mismo, en los paquetes todo en uno a menudo solo llega a él mediante un acceso avanzado al ordenador.

A partir de Bitcoin Core 30.0, 29.2 y 28.3, el software ya no trata como de confianza las conexiones Tor entrantes que llegan por la dirección configurada expresamente para ello. Con una versión actual, el núcleo de la vulnerabilidad queda cerrado aunque la línea de la lista blanca no cambie. Aun así, una lista blanca acotada sigue siendo una buena práctica, porque cada excepción suprime límites de protección.

Saldo en bitcoin y wallet: por qué las vulnerabilidades no cuestan monedas

La buena noticia para los inversores es que, según la clasificación del proyecto, ninguna de las tres vulnerabilidades permitía robar monedas ni crear otras nuevas. En la mayoría de los usuarios domésticos, las claves privadas se guardan de todos modos en una wallet separada y no en el propio nodo. Quien custodia sus fondos en una hardware wallet y usa el nodo solo como instancia de verificación propia separa con limpieza las claves y el software de red. Qué dispositivos encajan para ello lo muestra nuestra comparativa de hardware wallets.

Los riesgos estaban en la disponibilidad y la privacidad. Un par con derechos de lista blanca está sujeto a menos límites contra la saturación y recibe información que el nodo normalmente oculta a los desconocidos. Para quienes usan Tor precisamente por el anonimato, ese es el punto más delicado. Un nodo que se queda rezagado respecto a los nuevos bloques muestra además con retraso los pagos recibidos.

Quien no opera su propio nodo no se ve afectado directamente por las tres vulnerabilidades. Las wallets de software para el móvil suelen consultar servidores ajenos gestionados por el proveedor, y los exchanges custodian las monedas de sus clientes en su propia infraestructura. Nuestra comparativa de wallets de software ofrece una visión general de las wallets que funcionan sin nodo propio.

Fallos de Bitcoin Core: los tres cerrados desde la versión 30

Las tres divulgaciones del 10 de noviembre describen fallos corregidos desde octubre de 2025. Está en riesgo quien opera un nodo con una versión anterior y lleva un año aplazando la actualización. Bastan tres pasos:

1. Comprobar la versión y actualizar: si tu nodo está por debajo de la 30.0, pasa a una versión principal con mantenimiento como la 30.4, la 31.2 o la 32.1. Quien solo guarda sus monedas en un exchange no necesita nodo propio; encontrarás proveedores serios en nuestra comparativa de los mejores exchanges de criptomonedas.
2. Acortar la lista blanca: revisa en bitcoin.conf cada línea con whitelist= y limítala a los dispositivos que conoces de verdad. Para las consultas de la wallet sin nodo propio te ayuda nuestra comparativa de wallets de software.
3. Separar las claves del nodo: guarda los fondos de mayor importe en una hardware wallet y usa el nodo solo para verificar. Los dispositivos adecuados aparecen en la comparativa de hardware wallets.

(11 de noviembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)