El problema técnico, descubierto e informado de manera responsable por el investigador de seguridad Niklas Goegge el 26 de septiembre de 2025, radica en una inconsistencia dentro de la mempool, la memoria temporal donde los nodos alojan las transacciones antes de ser confirmadas.
El origen del problema estaba en un mecanismo llamado «expulsión de hermanos», introducido en la versión 28.0 de Bitcoin Core. Las reglas dictan que ciertas transacciones (conocidas como TRUC) solo pueden tener una única operación que dependa de ellas —un «hijo»— mientras esperan ser confirmadas. Si ingresaba una segunda transacción intentando gastar fondos del mismo origen, el sistema la trataba como un posible reemplazo. Así, si esta nueva operación ofrecía mayores comisiones a los mineros, eliminaba y sustituía a la primera.
La falla crítica se desencadenaba durante una reorganización de la cadena. En estos eventos, las transacciones de los bloques desconectados deben volver a añadirse a la mempool. Para que esta restauración sea fiel y no se apliquen restricciones de topología a transacciones que ya eran válidas, el sistema utiliza un parámetro que evade los límites de las políticas. Sin embargo, el código de Bitcoin Core omitió aplicar esta excepción a la rama de expulsión de hermanos, por lo que las restricciones de TRUC seguían ejecutándose mientras las operaciones se reintroducían.
Como resultado, una reorganización podía intentar restaurar un conjunto de transacciones que en la mempool infringía el límite de descendencia de TRUC. Al seguir activa la expulsión, el sistema eliminaba una transacción recién restaurada pero dejaba atrás a sus descendientes. Esto generaba un estado inconsistente en el cual la memoria retenía transacciones que gastaban fondos que ya no existían.
El efecto directo de esta anomalía recaía sobre los mineros. Al intentar crear una plantilla para un nuevo bloque, el proceso de ensamblaje fallaba en la comprobación de validez. Tal como destacó el desarrollador Michael Ford al citar el informe oficial, un nodo que atravesaba esta reorganización bajo dicho estado inconsistente perdía por completo su capacidad para producir bloques.
La única manera de reactivar el funcionamiento normal de un nodo atrapado en este error era reiniciándolo, lo que obligaba al sistema a recargar la mempool desde cero en un estado consistente.
Este defecto fue solucionado por el desarrollador Greg Sanders, quien introdujo la reparación en el código a finales de septiembre de 2025. Tras su fusión en el código principal, la solución se incorporó a las versiones seguras de Bitcoin Core, garantizando que la evaluación de las transacciones TRUC se desactive adecuadamente durante las reorganizaciones y evitando que los mineros actualizados sufran interrupciones operativas.
La revelación se da en un contexto de extrema sensibilidad sobre la seguridad informática, lo que incluye los desarrollos en torno al ecosistema de Bitcoin, tal como ha estado informando CriptoNoticias. Esto es debido a una ola de ciberataques impulsados por herramientas de inteligencia artificial con elevada capacidad para detectar vulnerabilidades en diversos protocolos.
Vulnerabilidad en conexión con Tor
Además de la falla crítica en la mempool, el 10 de noviembre de 2026 también se divulgaron los detalles de una segunda vulnerabilidad que expuso a miles de nodos de la red principal de Bitcoin. Identificada bajo el código CVE-2025-62860 y clasificada con una severidad media, esta anomalía provocaba que las conexiones entrantes provenientes de la red Tor recibieran permisos de lista blanca de forma indebida.
El problema técnico residía en la interacción entre los pares de Tor y el parámetro de configuración «-whitelist» de Bitcoin Core. Dicha opción se utiliza para otorgar privilegios a pares de confianza, lo cual desactiva los límites que previenen ataques de denegación de servicio (DoS) y suspende las mitigaciones diseñadas para evitar filtraciones de privacidad.
Dado que la dirección IP de los pares entrantes de Tor se identifica con la del daemon de Tor —el cual suele operar en la misma máquina o red local—, el software de Bitcoin le otorgaba estatus de confianza a estas conexiones si la dirección coincidía con el rango configurado.
El reporte destaca que los nodos que mantenían la configuración predeterminada (sin activar la lista blanca) nunca estuvieron en riesgo. Sin embargo, diversos proveedores populares de software distribuían Bitcoin Core integrado con Tor, preconfigurando la lista blanca para incluir la IP del demonio. A su vez, esta regla era un requisito operativo para otras aplicaciones cliente asociadas a Bitcoin Core. Como consecuencia, miles de nodos accesibles de la red principal otorgaron acceso irrestricto y sin las defensas correspondientes a cualquier conexión entrante a través de Tor.
Los investigadores Martin Zumsande y Antoine Poinsot descubrieron y reportaron responsablemente el error el 12 de septiembre de 2025. Cinco días después, se integró una solución en el código que impide de manera definitiva que los enlaces entrantes recibidos a través de una dirección onion obtengan permisos de lista blanca.
Los parches definitivos fueron distribuidos en octubre de 2025 mediante las versiones 30.0, 29.2 y 28.3 de Bitcoin Core. Al igual que con el error de la mempool, los pormenores de la falla se mantuvieron bajo estricta confidencialidad hasta que la última versión vulnerable, perteneciente a la serie 29.x, alcanzó el fin de su vida útil a finales de octubre de 2026.
Actualización 11 de noviembre de 2026: se añade información sobre la segunda vulnerabilidad reportada.
