Bitcoin Core publicó en noviembre de 2026 los detalles de tres vulnerabilidades de seguridad, aproximadamente un año después de que las correcciones ya se hubieran distribuido. La más grave de las tres, calificada de gravedad alta, podía impedir que los nodos de minería generaran plantillas de bloques válidas tras una reorganización de la cadena.

Bitcoin Core es la implementación de referencia del protocolo de Bitcoin. Los nodos de la red dependen de este software de código abierto para validar y retransmitir transacciones y bloques, mientras que los mineros y los pools de minería lo utilizan para ensamblar plantillas de bloques a partir de transacciones sin confirmar en la mempool, el área de espera de la red para transacciones pendientes.

Como política, el proyecto revela las vulnerabilidades solo después de un retraso: la corrección se distribuye primero en una versión, y la descripción técnica se publica solo cuando las versiones afectadas ya están desactualizadas. Las correcciones para estas fallas llegaron en las versiones 30.0, 29.2 y 28.3, todas publicadas en octubre de 2025. Los avisos llevan los identificadores CVE-2025-62861, CVE-2025-62859 y CVE-2025-62860, los identificadores estándar bajo los cuales se catalogan las vulnerabilidades de software divulgadas públicamente. CVE-2025-62861 tiene calificación alta; las otras dos tienen calificación media. En consecuencia, el proyecto publicó los avisos solo 14 días después de que finalizara el soporte de la línea 29.x, la última serie de versiones vulnerable. Los textos completos están disponibles en la revelación oficial y en el índice de avisos de seguridad del proyecto.

Cómo una reorganización podía paralizar a los nodos de minería

La falla de gravedad alta, CVE-2025-62861, afectaba a las versiones 28.0 a 28.2 y 29.0 a 29.1. Niklas Goegge la reportó en septiembre de 2025. El defecto se origina en TRUC, siglas de Topologically Restricted Until Confirmation, también conocidas como transacciones v3. Esta política de la mempool impone límites estrictos sobre cómo las transacciones sin confirmar pueden depender entre sí, y su propósito principal es ayudar a los protocolos de capa 2, como la Lightning Network, a aumentar las comisiones después del hecho. La versión 28.0 añadió una regla adicional llamada sibling eviction: una nueva transacción puede intentar agregar un segundo hijo a una transacción padre TRUC y, si paga suficiente en comisiones, reemplaza al hijo existente.

El error apareció durante una reorganización (reorg, abreviado), un evento en el que la red reemplaza los bloques agregados más recientemente por una cadena diferente. Bitcoin Core primero devuelve las transacciones de los bloques desconectados a la mempool con la bandera bypass_limits=true. Sin embargo, la rama de sibling eviction no respetaba esta bandera y se ejecutaba de todos modos. Como resultado, la regla expulsaba una transacción mientras sus descendientes permanecían en la mempool, dejando en la mempool transacciones que gastaban salidas que ya no existían. Cada vez que el nodo intentaba construir nuevas plantillas de bloques, la verificación de validez fallaba.

Los mineros afectados solo podían volver a producir plantillas válidas después de reiniciar el nodo, ya que un reinicio recarga la mempool en un estado consistente. Aun así, el aviso de CVE-2025-62861 no menciona ninguna solución alternativa aparte de la actualización. Greg Sanders entregó la corrección en el PR #33504, que el proyecto fusionó en la rama principal en octubre de 2025 y aplicó también a las líneas 28.x, 29.x y 30.x. La falla afectaba solo a la creación de plantillas: dado que TRUC es una regla de mempool y no una regla de consenso, el error no tocó el consenso. Las reglas de mempool como TRUC son políticas locales que cada nodo aplica a sus propias transacciones pendientes, a diferencia de las reglas de consenso, que cada nodo aplica sobre la cadena compartida.

Dos fallas de gravedad media afectan la retransmisión de bloques y los peers de Tor

CVE-2025-62859 afecta a las versiones anteriores a 29.2 y a 30.0. Eugene Siegel había reportado la vulnerabilidad ya en abril de 2025. Se encuentra en el manejo de bloques compactos, el formato abreviado que los nodos utilizan para pasarse nuevos bloques entre sí. Las versiones afectadas borraban el estado de descarga de dicho bloque antes de verificar la maleabilidad del witness, un término que designa un cambio posterior al hecho en los datos del witness. Si esta verificación fallaba, el nodo solicitaba los datos nuevamente al mismo peer mediante GETDATA, con un tiempo de espera de 10 minutos, aproximadamente el intervalo promedio entre bloques de Bitcoin. Por lo tanto, un peer malicioso que anunciara primero un bloque compacto podía retrasar el procesamiento de bloques de la víctima hasta 10 minutos. Además, el atacante podía repetir el ataque sin límite en el modo -blocksonly o cuando controlaba los tres peers de alto ancho de banda, el pequeño conjunto de peers del que depende un nodo para recibir anuncios prioritarios de bloques. El PR #32646, fusionado en junio de 2025, corrigió el error.

La segunda falla de gravedad media, CVE-2025-62860, afecta a las versiones anteriores a 28.3, 29.2 y 30.0. Martin Zumsande y Antoine Poinsot la reportaron en septiembre de 2025, dos semanas antes de que Goegge reportara la falla de gravedad alta. En Bitcoin Core, las conexiones Tor entrantes aparecen bajo la dirección IP del daemon de Tor, el servicio local que reenvía el tráfico de la red de anonimato. Si esa dirección caía dentro de un rango de IP permitido mediante -whitelist, todos los peers de Tor entrantes recibían permisos de lista blanca. Estos permisos eliminan los límites de DoS y las protecciones contra fugas de privacidad.

Según el aviso, "miles" de nodos alcanzables en la mainnet habían otorgado estos derechos a todas las conexiones Tor entrantes. A menudo, los proveedores que distribuyen Bitcoin Core junto con un daemon de Tor habían establecido la opción. En cambio, la falla nunca afectó a los nodos sin esta configuración opcional, que no es la predeterminada. Desde el PR #33395, Bitcoin Core ya no considera a los peers de Tor entrantes al asignar permisos de lista blanca.

El proyecto califica ambas fallas como de gravedad media. El retraso en el procesamiento de bloques era temporal, y los atacantes podían repetirlo a voluntad solo en configuraciones específicas, mientras que la falla de Tor requería una configuración que se apartaba de la predeterminada.

Por qué pasó un año entre la corrección y la revelación

Bitcoin Core separa deliberadamente la corrección de la revelación. La corrección se distribuye primero en una versión regular, y el proyecto no describe la vulnerabilidad en ese momento; los detalles llegan más tarde, una vez que las versiones afectadas son más antiguas o han alcanzado el fin de soporte. Esto les da a los operadores tiempo para actualizarse.

Para los tres avisos actuales, los reportes llegaron entre abril y septiembre de 2025, y las correcciones entraron al código entre junio y octubre de 2025. Bitcoin Core 30.0, 29.2 y 28.3 se distribuyeron con las correcciones en octubre de 2025. El fin del soporte determinó el momento de la revelación: el soporte de la 29.x, la última línea de versiones vulnerable, finalizó el 27 de octubre de 2026, y los avisos se publicaron el 10 de noviembre de 2026, 14 días después.

El índice de avisos del proyecto utiliza cuatro niveles de gravedad: Critical, High, Medium y Low. Los tres avisos se sitúan en los niveles intermedios. El plazo de CVE-2025-62859 destaca: Siegel reportó la falla en abril de 2025, el proyecto fusionó la corrección en junio de 2025, y los detalles se hicieron públicos apenas más de 18 meses después del reporte.

Qué significan estas fallas para los mineros y operadores de nodos

La falla de gravedad alta afectaba principalmente a los mineros y pools. Solo los nodos que pasaban por una reorg y luego tenían que construir plantillas de bloques activaban el error. En cambio, las dos fallas de gravedad media también afectaban a nodos comunes, aunque cada una requería una situación de red o una configuración específica.

Las versiones 30.0 y 29.2 corrigen los tres errores, y la 28.3 corrige dos de ellos. Sin embargo, desde finales de octubre de 2026, solo las versiones 30.x en adelante reciben soporte. Cualquiera que ejecute la 29.x o una versión anterior utiliza, por lo tanto, software sin soporte, incluso con los backports.

Los avisos dejan varias preguntas abiertas. Por ejemplo, no está claro si un atacante puede crear deliberadamente la topología de reorg que activa el error de gravedad alta. Los avisos tampoco indican si alguien llegó a explotar alguna de las tres fallas, y no existe un conteo exacto de los nodos afectados por la falla de Tor. El historial sí muestra que el proyecto corrigió y distribuyó los tres errores poco más de un año antes de la revelación.