Bitcoin Core publicó el 28 de octubre tres avisos de seguridad sobre bugs detectados por un escaneo automatizado con un modelo de lenguaje, todos corregidos en las versiones 29.5, 30.4, 31.2 y 32.1. Dos permiten que un peer malicioso llene la memoria de un nodo hasta que se apaga, y uno sirve para tumbar sin esfuerzo cualquier nodo que no funcione en Linux.
Bug 1: datos urgentes TCP en Windows, macOS y BSD
En las plataformas distintas de Linux, Bitcoin Core supervisa los sockets con un backend basado en select(). Ese backend vigilaba condiciones excepcionales incluso cuando las lecturas de un peer estaban en pausa, según el aviso de Bitcoin Core.
Un peer podía enviar datos urgentes TCP (fuera de banda) para saltarse el mecanismo de contrapresión y encolar una cantidad ilimitada de datos. En la práctica, un peer malicioso puede tumbar sin esfuerzo cualquier nodo Windows, macOS o BSD al que esté conectado.
- Gravedad: media, clasificado como fácil de descubrir
- Los nodos Linux no se ven afectados, ya que usan poll()
- Identificado el 23 de octubre; Antoine Poinsot abrió el PR #36665 el 26 de octubre
Bug 2: crecimiento lento de la memoria con peers anteriores a BIP31
Bitcoin Core encola anuncios, sobre todo INV de transacciones, para todos los peers, incluidos los pausados. Los peers que no responden a un ping con nonce en 20 minutos son desconectados, pero esa regla no se aplica a los peers que no admiten BIP 31, según indica el segundo aviso.
Un atacante puede fingir que no admite BIP 31 y retrasar de forma estratégica la lectura de mensajes, de modo que la cola crezca sin límite.
- Crecimiento de la memoria: hasta 2 MB por hora por peer entrante y 5 MB por hora por peer saliente
- Los nodos que se ejecutan con -blocksonly se ven mucho menos afectados
- Gravedad media; lo encontró Loupe el 15 de septiembre y L0rinc lo redescubrió de forma independiente el 21 de septiembre
Bug 3: desbordamiento del archivo undo
Un minero puede producir bloques válidos cuyos datos de undo son mucho mayores que los propios bloques, lo bastante como para que un solo archivo rev*.dat supere los 4 GiB. Las posiciones se guardaban como enteros de 32 bits, así que los datos de undo nuevos sobrescriben los antiguos, y si una reorganización afecta después a un bloque dañado, el nodo no puede leerlo y se apaga, explica el tercer aviso. Reiniciar no sirve de nada, y la recuperación exige un -reindex con una versión corregida.
En Windows y en sistemas de 32 bits el límite es de 2 GiB y no hace falta ninguna reorganización: el nodo no logra escribir los datos de undo y se apaga en cada reinicio.
- Gravedad: baja; explotarlo en sistemas de 64 bits es poco práctico
- Un atacante tendría que minar varios miles de bloques, aproximadamente un mes de producción de toda la red
- Los sistemas de 32 bits y los nodos que almacenan bloques en FAT32 siguen afectados tras la corrección
- Lo comunicó Loupe el 8 de julio y después, de forma independiente, L0rinc (21 de agosto) y Andrew Dorman (23 de octubre)
Quién los encontró y por qué ya son públicos
Los tres se descubrieron mediante un escaneo automatizado con LLM dentro del Project Loupe, dirigido por Elias Rohrer en Spiral. Gregory Sanders validó los hallazgos y los trasladó al equipo de seguridad de Bitcoin Core.
La política de Bitcoin Core define las vulnerabilidades fáciles de descubrir como las que se encuentran con un esfuerzo mínimo, por ejemplo con un simple prompt a un LLM. En esos casos, el equipo publica una versión de mantenimiento con la corrección para cada versión principal que mantiene, además de un aviso, sin el periodo de embargo habitual.
Con el calendario normal, los bugs de gravedad media y alta se revelan dos semanas después de que la última versión afectada llegue al final de su vida útil, aproximadamente un año después de la primera versión principal que incluye la corrección.
Versiones corregidas | Fecha de lanzamiento |
|---|---|
31.2 y 32.1 | 27 de octubre de 2026 |
29.5 y 30.4 | 28 de octubre de 2026 |