Bitcoin Core revela una vulnerabilidad de Tor que confiaba en miles de nodos

Bitcoin Core ha divulgado una vulnerabilidad que otorgaba permisos de confianza a las conexiones entrantes de Tor en miles de nodos, eliminando algunas protecciones contra el spam y las filtraciones de privacidad.

Resumen

• Miles de nodos accesibles otorgaron permisos a las conexiones entrantes de Tor destinados a pares de confianza.
• La vulnerabilidad de gravedad media afectó ciertas configuraciones de lista blanca y fue corregida en octubre de 2025.
• Un error separado de alta gravedad podría impedir que los nodos de minería afectados crearan plantillas de bloques válidas.

La divulgación de seguridad de Bitcoin Core, publicada el 10 de noviembre, identifica el problema de Tor como CVE-2025-62860. Los desarrolladores publicaron los detalles junto con otras dos vulnerabilidades después de que la última serie de versiones afectadas, 29.x, alcanzara el final de su soporte el 27 de octubre.

Las configuraciones de lista blanca de Bitcoin Core permiten que el tráfico de Tor evite límites

Según el aviso, los pares entrantes de Tor aparecían ante Bitcoin Core bajo la dirección IP del software Tor, que normalmente se ejecutaba en la misma computadora o red local. Cuando esa dirección coincidía con un rango configurado a través de la opción -whitelist, las conexiones externas recibían permisos destinados a pares de confianza.

La inclusión en la lista blanca elimina varios límites de denegación de servicio y salvaguardias contra la filtración de información privada. Los proveedores populares empaquetaron Bitcoin Core con Tor y configuraron rangos de lista blanca coincidentes, dejando a miles de nodos de mainnet accesibles aceptando todas las conexiones entrantes de Tor con esos privilegios, dijeron los desarrolladores.

Los nodos que nunca habilitaron la configuración no predeterminada no se vieron afectados por esta vulnerabilidad. El aviso acredita a Martin Zumsande y Antoine Poinsot con el descubrimiento y la notificación al equipo de seguridad el 12 de septiembre de 2025.

En el cambio de código, Zumsande explicó que las conexiones entrantes de Tor no revelan la dirección de red real del par, lo que hace que la coincidencia basada en la dirección sea ineficaz. Su solución propuesta excluyó las conexiones de cebolla entrantes de los permisos de lista blanca. Los desarrolladores la fusionaron el 17 de septiembre de 2025.

Poinsot notificó a los proveedores de software afectados dos días después, según la cronología de divulgación. Bitcoin Core 30.0 se envió con la corrección el 10 de octubre, seguido por 29.2 el 14 de octubre. El aviso también enumera las versiones menores 28.3 y posteriores como corregidas.

Un error de minería separado podría detener la creación de plantillas de bloques

La vulnerabilidad de minería, rastreada como CVE-2025-62861, recibió una calificación de alta gravedad. Afectó a las versiones 28.0 a 28.2 y 29.0 a 29.1.

El aviso de Bitcoin Core describe un problema durante las reorganizaciones de cadena, cuando las transacciones de bloques desconectados regresan al mempool, la colección de transacciones pendientes del nodo.

Las reglas para las transacciones de versión 3, conocidas como transacciones TRUC, normalmente limitan las relaciones entre transacciones no confirmadas. Sin embargo, durante una reorganización, se supone que las transacciones que regresan de bloques válidos deben eludir esas restricciones.

El error dejó activa una regla de reemplazo de transacciones durante ese proceso. Podría eliminar una transacción restaurada mientras dejaba atrás transacciones que dependían de ella, produciendo un mempool inconsistente.

Con esas entradas faltantes, dice el aviso, la plantilla de bloque propuesta de un nodo de minería fallaría su verificación de validez. La creación de plantillas de bloques no podría reanudarse hasta que un reinicio recargara el mempool en un estado consistente.

Niklas Goegge informó del problema el 26 de septiembre de 2025. En la documentación de la corrección, el desarrollador Greg Sanders explicó que omitir las verificaciones TRUC durante las reorganizaciones había sido el comportamiento previsto, pero el argumento de elusión relevante no se había verificado. Los desarrolladores fusionaron la corrección el 2 de octubre.

Otra vulnerabilidad podría retrasar repetidamente el procesamiento de bloques

El tercer aviso oficial, CVE-2025-62859, describe una vulnerabilidad de gravedad media que involucra bloques compactos, un método que ahorra ancho de banda para retransmitir bloques entre nodos.

Un par malicioso que anunciara primero un bloque compacto podría hacer que una víctima solicitara el bloque completo del mismo par y esperara a través de un tiempo de espera de 10 minutos. El retraso siguió a una verificación fallida de datos de testigos de transacciones alterados.

Según la divulgación, un atacante que controlara los tres pares de alta capacidad de la víctima podría repetir la interrupción indefinidamente. Los nodos que funcionaban con -blocksonly eran otra configuración en la que era posible un estancamiento repetido. Eugene Siegel informó de la vulnerabilidad el 28 de abril de 2025.

Los detalles públicos siguieron al final del soporte

La política de divulgación de Bitcoin Core normalmente retiene los detalles de vulnerabilidades de gravedad media y alta hasta dos semanas después de que la última versión afectada alcance el final de su vida útil.

Como informó anteriormente crypto.news, un cambio de política en octubre creó una ruta de divulgación más rápida para fallas fácilmente redescubiertas, incluidos problemas encontrados a través de un simple aviso de IA.

Las correcciones anteriores abordaron diferentes problemas. La versión candidata 31.1rc1 de junio corrigió una falla de privacidad de PrivateBroadcast que podría exponer direcciones IP. En mayo, los desarrolladores divulgaron una vulnerabilidad del intérprete de scripts que involucraba un bloque especialmente diseñado que podría bloquear de forma remota nodos vulnerables; su corrección se envió en Bitcoin Core 29.0 en abril de 2025.