Bitcoin Core dio a conocer tres vulnerabilidades que ya tenían correcciones disponibles: una podía dejar a ciertos mineros sin plantillas de bloque válidas tras una reorganización de la cadena, mientras que otras afectaban el procesamiento de bloques y los permisos de conexiones Tor.
***

• El fallo de alta severidad, CVE-2025-62861, podía dejar inconsistente el mempool y obligar a los mineros afectados a reiniciar sus nodos.
• CVE-2025-62859 permitía retrasar hasta 10 minutos el procesamiento de bloques en ciertos escenarios y podía repetirse bajo condiciones específicas.
• CVE-2025-62860 otorgaba permisos de lista blanca a algunas conexiones Tor entrantes; Bitcoin Core señaló que miles de nodos alcanzables estaban configurados de ese modo.

Bitcoin Core revela tres fallos ya corregidos, incluido uno que afectó a mineros

Las vulnerabilidades afectaban la creación de plantillas de bloque, el procesamiento de bloques compactos y los permisos concedidos a ciertas conexiones Tor. Bitcoin Core publicó correcciones para las tres en octubre de 2025 y divulgó los detalles el 10 de noviembre de 2026.

Un error que podía frenar la creación de bloques

Bitcoin Core divulgó tres vulnerabilidades de seguridad en su software, utilizado por muchos nodos de la red Bitcoin, y precisó que las tres ya contaban con correcciones. La de mayor severidad, identificada como CVE-2025-62861, podía impedir que algunos nodos de minería generaran plantillas de bloques válidas después de una reorganización de la cadena. El problema no implicaba que todos los mineros estuvieran expuestos: afectaba a versiones concretas y dependía de una secuencia específica de operaciones en el mempool.

El fallo se relacionaba con las reglas TRUC de expulsión de transacciones hermanas, que Bitcoin Core aplica para gestionar ciertas transacciones en el mempool. Después de una reorganización, algunas transacciones podían regresar a esa memoria temporal, pero las reglas continuaban aplicándose de una forma que dejaba un estado inconsistente: el sistema podía expulsar una transacción sin retirar también a sus descendientes. Esa diferencia entre los elementos vinculados podía bloquear la creación de una plantilla válida para minar.

Una reorganización ocurre cuando la cadena activa cambia y el nodo debe ajustar qué bloques considera parte de la secuencia válida; en ese proceso, algunas transacciones pueden volver a esperar confirmación. El aviso describe cómo el tratamiento de esas transacciones que regresaban al mempool podía desencadenar el error, no una falla general de consenso que afectara por igual a todos los nodos. Para los mineros alcanzados por el problema, el remedio operativo indicado era reiniciar el nodo antes de poder crear plantillas válidas nuevamente.

Niklas Goegge reportó CVE-2025-62861 el 26 de septiembre de 2025, de acuerdo con la divulgación. La vulnerabilidad afectaba a Bitcoin Core 28.0, 28.1 y 28.2, además de las versiones 29.0 y 29.1; el aviso la clasifica como de alta severidad. El alcance descrito es concreto: el fallo podía interrumpir la preparación de bloques en los nodos afectados, pero la información publicada no afirma que se explotara para alterar bloques confirmados ni cuantifica pérdidas económicas.

Retrasos en el procesamiento de bloques

La segunda vulnerabilidad, CVE-2025-62859, recibió una clasificación de severidad media y fue reportada por Eugene Siegel en abril de 2025. Según el aviso, un par malicioso podía aprovechar la maleabilidad de testigos asociada a bloques compactos para retrasar el procesamiento de bloques hasta 10 minutos. El problema se situaba en el intercambio y la reconstrucción de datos entre pares, y no en una modificación de las reglas que determinan qué transacciones son válidas.

Los bloques compactos permiten que los nodos intercambien una representación reducida de un bloque y completen los datos que faltan mediante información que ya tienen o que solicitan a otros pares. La vulnerabilidad descrita aprovechaba la maleabilidad de testigos en ese contexto para demorar la tarea de procesamiento. La cifra de hasta 10 minutos corresponde al retraso señalado por el aviso; la fuente no presenta ese intervalo como un tiempo fijo para toda ejecución ni como una interrupción inevitable de la red.

El riesgo podía repetirse indefinidamente contra nodos que operaran con la opción -blocksonly, según la divulgación. También podía repetirse en un escenario donde el atacante controlara los tres pares de alto ancho de banda del nodo objetivo. Esas condiciones delimitan la exposición descrita: el aviso no sostiene que cualquier participante pudiera provocar el retraso en cualquier nodo, y tampoco ofrece cifras sobre cuántos equipos usaban esa configuración.

La diferencia frente al fallo de minería es relevante para entender el alcance de los avisos. CVE-2025-62861 podía impedir que mineros afectados generaran plantillas válidas hasta que reiniciaran sus nodos, mientras que CVE-2025-62859 podía demorar el procesamiento de bloques bajo escenarios determinados. Ambos problemas muestran riesgos distintos en el funcionamiento de un nodo, pero la información publicada no los presenta como incidentes de pérdida de fondos ni como una vulnerabilidad que comprometiera por sí sola las claves de los usuarios.

Permisos inesperados para conexiones Tor

La tercera vulnerabilidad, CVE-2025-62860, también fue clasificada con severidad media y afectaba a una configuración opcional de lista blanca. Si el rango de direcciones IP configurado para esa lista incluía la dirección del proxy Tor, los pares entrantes que llegaban a través de Tor podían recibir permisos de lista blanca. El defecto, por tanto, dependía de cómo estuviera configurado el nodo y no alcanzaba a quienes no usaban esa opción.

Bitcoin Core indicó que miles de nodos de la red principal alcanzables habían incluido en la lista blanca conexiones Tor entrantes. En esos casos, el permiso eliminaba ciertos límites de denegación de servicio y protecciones de privacidad que normalmente se aplican a esas conexiones. La divulgación no afirma que todos esos nodos fueran atacados ni cuantifica un daño observado; identifica una configuración que podía conceder a esos pares un nivel de confianza distinto del previsto.

Una lista blanca permite tratar de forma diferenciada las conexiones que coinciden con los criterios establecidos por quien administra el nodo. El punto delicado señalado en este caso era que la dirección del proxy Tor podía caer dentro de un rango configurado para otorgar esos permisos, de modo que el nodo no distinguiera como se esperaba la procedencia de la conexión entrante. La alerta se refiere a ese cruce entre la configuración de IP y el uso de Tor, no a una falla general del protocolo de anonimato.

La vulnerabilidad permite apreciar por qué los avisos de seguridad distinguen entre errores del software y condiciones de configuración. Los nodos que no habilitaron la opción de lista blanca no estaban afectados por este problema, según Bitcoin Core, mientras que quienes sí la usaban debían considerar si el rango incluía el proxy Tor. El dato de los miles de nodos alcanzables muestra que la combinación existía en la red principal, aunque no permite deducir que todos mantuvieran la misma configuración o estuvieran expuestos de idéntica manera.

Correcciones publicadas antes de la divulgación

Bitcoin Core 30.0 incorporó correcciones para las tres vulnerabilidades y se lanzó el 10 de octubre de 2025. La versión 29.2, también corregida, llegó el 14 de octubre de ese año. La divulgación pública se produjo después de esas publicaciones, por lo que el reporte describe fallos ya corregidos en las versiones señaladas, aunque los detalles permiten a operadores y desarrolladores entender qué configuraciones y comportamientos estaban involucrados.

El aviso también señaló que la última versión vulnerable de Bitcoin Core llegó al final de su ciclo de vida el 27 de octubre de 2026. Ese hito importa porque delimita el estado de soporte de las versiones afectadas, pero no equivale a afirmar que cada nodo vulnerable dejó de funcionar en esa fecha ni que se actualizó automáticamente. La fuente no informa cuántos nodos seguían ejecutando versiones expuestas cuando hizo pública la divulgación.

Los tres reportes se originaron en momentos diferentes: el problema de retraso se notificó en abril de 2025, y los otros dos fueron reportados en septiembre de ese año. En conjunto, cubren fallos en el tratamiento de transacciones que vuelven al mempool, la reconstrucción de bloques compactos y la asignación de permisos a conexiones Tor. Esa variedad impide reducir la alerta a una sola falla general, y hace necesario distinguir qué versiones y condiciones corresponden a cada CVE.

Los avisos de CVE-2025-62859 y CVE-2025-62860 de Bitcoin Core tienen fecha del 10 de noviembre de 2026. El antecedente de otra vulnerabilidad de memoria de alta severidad, reportada por un medio en mayo y también corregida antes de su divulgación, queda fuera de estos tres casos y no debe confundirse con ellos. Para lectores y operadores, el dato central de esta publicación es que los fallos tenían parches previos y alcances distintos, desde la generación de plantillas hasta las conexiones de nodos.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín