Tres fallos de seguridad en Bitcoin Core: qué puedes hacer ahora

Bitcoin Core publicó el 28 de octubre de 2026 tres avisos de seguridad de una vez. El más grave permite que un único par malicioso tumbe cualquier nodo bajo Windows, macOS o BSD. Los tres puntos están corregidos en las versiones 29.5, 30.4, 31.2 y 32.1. Si manejas tu propio nodo de Bitcoin y no has actualizado desde el lunes, estás funcionando con una versión cuyas debilidades se describen públicamente desde el miércoles.

Un nodo es el ordenador que comprueba por sí mismo toda la blockchain en lugar de creer a un proveedor. Si se cae, no desaparece ningún saldo: las claves están en la cartera, no en el nodo. Lo que se pierde es la comprobación propia, y con dos de los tres fallos el ordenador se va al suelo con él.

Tres avisos en un día: qué ha revelado Bitcoin Core

Las tres publicaciones figuran juntas en la lista de avisos del proyecto. Dos de ellas están clasificadas como «Medium» y una como «Low», y las tres llevan el añadido «easily discoverable», es decir, fácilmente localizable. Esa es la clasificación decisiva: quien lee el código encuentra el punto sin esfuerzo especial.

• Datos TCP urgentes: un par puede tumbar un nodo bajo Windows, macOS o BSD. Linux no está afectado.
• Pares pre-BIP31 en pausa: la necesidad de memoria de un nodo crece despacio, pero sin límite.
• Desbordamiento de los archivos undo: un minero puede dañar los datos de recuperación de otros nodos.

La secuencia de publicaciones está inusualmente apretada. Las correcciones se incorporaron el 26 de octubre y se retroportaron a las ramas 29, 30, 31 y 32. El 27 de octubre aparecieron las versiones 31.2 y 32.1, el 28 de octubre siguieron 29.5 y 30.4, y ese mismo día se puso en línea la descripción de los fallos.

Datos TCP urgentes: por qué se caen los nodos de Windows y macOS

Bitcoin Core limita cuántos datos mantiene por par a la espera de procesarlos. Si la cola se alarga demasiado, el software pausa la lectura de ese puerto. Ese mecanismo se llama contrapresión: el software frena al par en lugar de llenarse él mismo.

Justo ese freno se puede esquivar. En sistemas distintos de Linux, Bitcoin Core vigila los puertos de red con una técnica más antigua que reacciona también a los llamados estados excepcionales de un puerto. Hasta ahora lo hacía incluso cuando la lectura estaba pausada desde hacía tiempo. Un par solo tiene que enviar, por tanto, datos TCP urgentes, una forma de transmisión fuera del orden normal que se usa poco, y el nodo sigue leyendo. La cola crece sin límite hasta que la memoria de trabajo se llena.

El proyecto describe la consecuencia en su aviso sin ambigüedades: un par malicioso puede tumbar por esta vía cualquier nodo conectado bajo Windows, macOS o BSD. Sin margen previo, sin preparación, sin potencia de cálculo. El fallo se comunicó el 23 de octubre y estaba corregido tres días después.

Contrapresión: el freno que aquí falla

Que esto fuera posible se debe a una particularidad de la implementación. Bajo Linux, Bitcoin Core usa otro procedimiento para vigilar los puertos de red. La ruta defectuosa simplemente no existe allí. Por eso los nodos en servidores Linux, en la mayoría de las cajas domésticas ya montadas y en centros de datos quedan al margen en este punto.

select() en lugar de poll(): los nodos Linux no están afectados

En la práctica, esa es la distinción más importante de toda la jornada. Si haces funcionar tu nodo en un ordenador de placa única o en un pequeño servidor Linux, este fallo te deja fuera. Si en cambio manejas Bitcoin Core como programa en tu ordenador de trabajo, es decir, bajo Windows o en un Mac, perteneces al grupo afectado. Lo mismo vale para los nodos en sistemas BSD.

La diferencia no es teórica. Un nodo caído no sigue sincronizando, no responde a las consultas de tu propia cartera y no avisa de ningún pago entrante. Si haces funcionar tu cartera contra tu propio nodo, durante ese tiempo ves un saldo desactualizado.

Pares pre-BIP31: 2 MB de memoria por hora y conexión

El segundo fallo actúa más despacio y por eso resulta más traicionero. Bitcoin Core pone en la cola los anuncios para todos los pares, también para los que ya están pausados. A ellos pertenecen sobre todo los frecuentes avisos de nuevas transacciones.

Normalmente eso es inocuo, porque un par se desconecta si no responde durante veinte minutos a un mensaje de control. Ese mensaje de control está descrito en el BIP 31, una propuesta de mejora de los primeros tiempos de la red que añade un número aleatorio al mensaje ping. Los pares que no admiten el BIP 31 quedan exentos de esa desconexión. Un par solo tiene que hacerse pasar por antiguo y retrasar la lectura a propósito.

El proyecto cifra el aumento con precisión: hasta 2 MB por hora y conexión entrante, hasta 5 MB por hora y conexión saliente. Un nodo con muchas conexiones entrantes acumula por esta vía, a lo largo de días, lastre suficiente para llenar la memoria de trabajo. Bastante menos afectados están los nodos que funcionan con el ajuste -blocksonly, porque allí desaparecen los avisos de transacciones, que constituyen la mayor parte de la cola.

Este punto se comunicó ya el 15 de septiembre de 2026. Entre el aviso y la corrección pasaron, por tanto, seis semanas buenas en las que el fallo era conocido por el proyecto y no por el público.

Archivos undo por encima de 4 GiB: el tercer fallo en el directorio rev

El tercer punto afecta a un archivo del que la mayoría de los operadores de nodos nunca ha oído hablar. Junto a los archivos de bloques, Bitcoin Core crea los llamados archivos undo, reconocibles por el patrón de nombre rev*.dat. En ellos consta qué monedas ha gastado un bloque. El software necesita esos datos cuando una reorganización de la blockchain tiene que deshacer un bloque ya contabilizado.

Una reorganización, reorg para abreviar, es el proceso en el que la red cambia a otra cadena de bloques más larga y retira bloques antes válidos. Los archivos de bloques están limitados a 128 MiB; los archivos undo, en cambio, nunca tuvieron un límite superior. Las posiciones que contienen se guardaban como números de 32 bits, y esos solo llegan hasta 4 GiB.

Un minero puede construir bloques válidos cuyos datos undo son bastante mayores que los propios bloques. Si un archivo undo crece más allá de esos 4 GiB, la indicación de posición salta de vuelta al principio. Los datos undo más nuevos sobrescriben los más antiguos y el archivo se recorta a la longitud del salto. Si una reorganización posterior deshace un bloque afectado, el nodo ya no puede leer sus datos undo y se apaga. Un reinicio no ayuda. La recuperación exige una reconstrucción completa del índice con una versión corregida, cosa de horas o días en un ordenador doméstico corriente.

Los sistemas de 32 bits y FAT32 siguen expuestos incluso tras la actualización

Aquí está el punto que, al contrario que los otros dos, no queda resuelto por completo. El desbordamiento se corrigió guardando ahora las posiciones como números de 64 bits y haciendo que Windows use las órdenes de archivo adecuadas. El formato en el disco queda sin cambios, así que no hace falta mover los datos.

Dos configuraciones siguen siendo vulnerables de todos modos. En los sistemas de 32 bits las órdenes de archivo siguen funcionando solo hasta 2 GiB, de modo que allí el fallo aparece ya con la mitad del volumen de datos y sin ninguna reorganización. Y quien tenga su directorio de bloques en un sistema de archivos FAT32, por ejemplo en un disco externo antiguo o en una memoria USB, choca con el límite de tamaño de archivo de ese formato, 4 GiB. En ambos casos la escritura de los datos undo fracasa y el nodo se apaga de nuevo en cada arranque.

Aprovechar el fallo en la práctica es apenas factible en sistemas de 64 bits. El proyecto describe el esfuerzo en detalle: las transacciones necesarias no son conformes al estándar, un atacante tendría que minar varios miles de bloques de ese tipo, lo que equivale a cerca de un mes de producción de bloques de toda la red, y después unos dieciocho bloques más suyos tendrían que caer exactamente al final de un archivo de bloques del nodo objetivo. Por último tendría que ganar una reorganización a lo largo de dos bloques. Como la distribución de archivos es distinta de un nodo a otro, ninguna preparación alcanza todos los objetivos.

Project Loupe: un escaneo automático encontró los tres fallos

Los tres errores se remontan a la misma fuente. Se encontraron mediante un escaneo automatizado con un modelo de lenguaje que funciona con el nombre de Project Loupe en Spiral y del que es responsable Elias Rohrer. Gregory Sanders comprobó los hallazgos y los comunicó al equipo de seguridad de Bitcoin Core.

Dos de los tres puntos se descubrieron una segunda vez de forma independiente. El desarrollador L0rinc comunicó el fallo de memoria con pares en pausa el 21 de septiembre y el desbordamiento undo el 21 de agosto, y Andrew Dorman el desbordamiento undo el 23 de octubre. Las correcciones provienen en cada caso de Antoine Poinsot.

Del embargo a la divulgación: Bitcoin Core ha cambiado las reglas

Que las descripciones estuvieran públicas apenas un día después de las versiones terminadas no es casualidad. El proyecto cambió hace poco su práctica de publicación y abandonó el largo plazo de reserva, del que informamos el 23 de octubre de 2026: Bitcoin Core tumba el embargo. Los tres avisos del 28 de octubre son la primera tanda de peso con la nueva línea.

Para los operadores eso tiene dos caras. Los fallos se conocen más rápido, y quien no actualiza queda expuesto antes. Al mismo tiempo, ahora consta de forma consultable qué puede salir mal exactamente, en lugar de solo un número de versión con la nota de «actualización de seguridad».

Sin nodo propio: dónde está entonces tu saldo en bitcoines

La mayor parte de los inversores no maneja ningún nodo propio. Quien guarda sus monedas en una cartera de software en el móvil o en el ordenador usa los nodos de otras personas, normalmente los del proveedor de la cartera. Qué cartera elige qué vía y dónde puedes activar tu propia comprobación está en la comparativa de carteras de software.

En ese grupo nadie está afectado directamente por los tres fallos. Queda un riesgo de todos modos: si se cae el nodo del proveedor, no ves un saldo actualizado y no te confirman ningún pago. Tus claves siguen intactas en la cartera, y en eso consiste toda la idea de la autocustodia.

El precio no reaccionó a la publicación. Bitcoin cotizaba la mañana del 29 de octubre de 2026 en torno a 79.790 dólares (CoinGecko), alrededor de un 1,6 % por debajo del día anterior, al mismo paso que el resto del mercado tras la decisión de tipos de la Reserva Federal del día previo.

Bitcoin Core 32.1: quien siga en 32 bits sigue expuesto

1. Comprobar la versión y cambiarla. En la consola, bitcoin-cli getnetworkinfo muestra la versión en uso. Todo lo que esté por debajo de 29.5, 30.4, 31.2 o 32.1 hay que cambiarlo, sobre todo en Windows y macOS. Si quieres aprovechar la ocasión para separar las claves del ordenador del día a día, los dispositivos están en la comparativa de carteras hardware.
2. Mirar el sistema de archivos y la arquitectura. Si el directorio de bloques está en FAT32 o el nodo corre en un sistema de 32 bits, el tercer fallo sigue abierto. Mudarse a un sistema de archivos moderno lo elimina. Quien prefiera apoyarse del todo en un proveedor compara las comisiones en el panorama de los exchanges cripto.
3. Observar el consumo de memoria. Si el consumo de un nodo más antiguo crece de forma sostenida a lo largo de días, encaja con el segundo fallo. Con -blocksonly el aumento resulta bastante menor. Quien prefiera mantener su saldo en una casa supervisada comprueba las autorizaciones entre los exchanges cripto regulados.

Las descripciones completas están en la lista de avisos de Bitcoin Core, y el texto sobre el fallo TCP en el aviso individual correspondiente.

(29 de octubre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)