Qué pasó
El 10 de noviembre de 2026, Bitcoin Core publicó tres avisos de seguridad sobre fallos corregidos en versiones lanzadas durante octubre de 2025. Uno podía retrasar repetidamente el procesamiento de bloques. Otro podía dar a desconocidos conectados por Tor permisos reservados para peers de confianza. El tercero podía impedir que un nodo minero creara una plantilla de bloque válida hasta reiniciarse.
El proyecto esperó para divulgar los detalles hasta que la última rama vulnerable quedó fuera de soporte el 27 de octubre de 2026. Bitcoin Core dice que las correcciones están en las versiones 28.3, 29.2 y 30.0. No reporta explotación conocida.
El fallo de mayor severidad, CVE-2025-62861, afectaba a Bitcoin Core 28.0 hasta 28.2 y 29.0 hasta 29.1. Durante una reorganización de la cadena, una regla para expulsar transacciones podía dejar el mempool en un estado incoherente. Un minero que pidiera entonces una plantilla de bloque podía recibir una que el mismo nodo rechazaba. Reiniciar borraba el estado, pero un atacante capaz de repetir el patrón podía seguir interrumpiendo la minería.
Qué cambia
El fallo de permisos de Tor importa a operadores que usaban la opción no predeterminada -whitelist. Bitcoin Core comprobaba la dirección del proxy en vez de la dirección del peer del servicio oculto. Si el proxy estaba dentro de un rango de confianza, cada peer Tor entrante podía heredar permisos destinados a un peer conocido.
Bitcoin Core dice que paquetes populares para nodos colocaban el proxy Tor dentro de un rango privado incluido en la lista de confianza, por lo que miles de nodos accesibles estaban afectados. Esos permisos extra podían permitir que un desconocido eludiera protecciones normales, incluidos algunos límites de desconexión y retransmisión. Los nodos que nunca activaron -whitelist, y las conexiones que no llegaban mediante la configuración de proxy afectada, no estaban expuestos a este fallo.
El tercer fallo, CVE-2025-62859, usaba maleabilidad del testigo contra la reconstrucción de bloques compactos. Un peer malicioso podía hacer que un nodo pasara hasta diez minutos intentando obtener la transacción correcta antes de procesar el bloque. El atacante podía repetir el retraso cuando controlaba tres peers de gran ancho de banda, o contra un nodo que usara -blocksonly con menos conexiones.
Quienes ejecuten una versión afectada deben pasar a una versión mantenida de Bitcoin Core descargada desde el sitio oficial. La versión 29.2 contiene las correcciones, pero la rama 29.x ya no tiene soporte. Una rama mantenida también es necesaria para recibir correcciones de seguridad posteriores.
Qué no cambia
Los avisos describen fallos de disponibilidad y permisos de peers. No describen una forma de robar claves privadas, crear bitcoin, cambiar el límite de emisión ni hacer válida una transacción inválida.
El fallo de minería no cambió el consenso. El nodo afectado rechazaba su propia plantilla defectuosa antes de minarla. El daño inmediato era una interrupción en la producción de bloques de ese operador, no la aceptación de un bloque inválido por la red.
El fallo de Tor tampoco convertía cada conexión Tor en una conexión de confianza. Requería que un operador o paquete combinara Tor entrante con una regla -whitelist coincidente. La estimación de Bitcoin Core de miles de nodos afectados procede de mediciones públicas de accesibilidad y de configuraciones comunes, no de un recuento de compromisos confirmados.
Estas divulgaciones son nuevas, pero las correcciones no. Un nodo que ya ejecute una versión mantenida tiene los parches. Los tres fallos también son distintos de los fallos de memoria y archivos undo divulgados el 28 de octubre.
Contexto
Tres medios independientes comprobaron los avisos. CoinDesk se centró en el alcance del error de permisos de Tor. The Block comparó las versiones afectadas y el fallo de minería de severidad alta. Decrypt explicó cómo el fallo de la plantilla de bloque podía detener a un operador sin romper el consenso. Unchained también distinguió estos fallos de las divulgaciones del 28 de octubre.
Los reportes coinciden en los mecanismos, las versiones corregidas y la ausencia de explotación conocida. Ninguno demuestra que un atacante usara alguno de los tres fallos en la práctica. La publicación retrasada sigue la práctica de Bitcoin Core de dar tiempo a los operadores para actualizar antes de hacer públicos los detalles técnicos.