Un minero podría hacer crecer un archivo undo de Bitcoin Core por encima de 4 GiB, desbordar sus posiciones de 32 bits y corromper datos, de modo que los nodos se apagan si luego llega la reorganización adecuada; Windows y los sistemas de 32 bits fallan a los 2 GiB, sin necesidad de reorganización. CVE-2026-117346 tiene gravedad baja y exigiría alrededor de un mes de todos los bloques de la red. Las versiones 32.1, 31.2, 30.4 y 29.5 lo corrigen en sistemas de 64 bits; los nodos de 32 bits y el almacenamiento de bloques en FAT32 siguen afectados.
La vigilancia de excepciones de socket funciona ya igual con poll() que con select() en Bitcoin Core 29.5 (#36665), y los pares con el envío en pausa quedan sujetos a un tiempo límite (#36667). Las posiciones de flatfile pasan a enteros de 64 bits (#36669), los nodos dan por hecho v2transport en las direcciones obtenidas de semillas y desaparece una semilla DNS.
Fingiendo que no admite los pings de BIP 31, un par malicioso podía esquivar la desconexión a los 20 minutos y leer despacio, con lo que la cola de envío del nodo engordaba hasta 2 MB por hora por cada par entrante y 5 MB por cada saliente. CVE-2026-117349, de gravedad media, queda resuelto con #36667 en Bitcoin Core 32.1, 31.2, 30.4 y 29.5; los nodos con -blocksonly estaban mucho menos expuestos.
Un par conectado podía tumbar nodos en Windows, macOS y BSD enviando datos urgentes de TCP, que se colaban por las lecturas en pausa del backend select() y acumulaban memoria sin límite (CVE-2026-117350). En Linux los nodos usan poll() y no se ven afectados. Bitcoin Core 32.1, 31.2, 30.4 y 29.5 corrigen este fallo de gravedad media, detectado por un análisis con un LLM dentro de Project Loupe.
Bitcoin Core 30.4 deja de interpretar los bits 5 a 28 de BIP 9 como señales de soft fork, en línea con BIP 323, de modo que los bloques que los activan ya no disparan avisos de despliegues desconocidos (#34779). En la parte de red, los pares con el envío en pausa quedan sujetos a un tiempo límite (#36667), y las posiciones de flatfile pasan a enteros de 64 bits (#36669).
La difusión privada ya tiene un tope en Bitcoin Core 31.2: la cola de transacciones que la red aún no ha devuelto se detiene en 10.000 entradas y, una vez llena, rechaza nuevos envíos, así que toca vaciarla con abortprivatebroadcast (#35406). Los bits de versión 5 a 28 dejan de contar como señales de soft fork, conforme a BIP 323.
La difusión privada de Bitcoin Core 32.1 ya no corre el riesgo de exponer la IP del remitente, algo que podía ocurrir cuando una conexión v2 fallida se reintentaba por v1 de forma directa, sin pasar por Tor. El valor predeterminado de -maxconnections sube de 125 a 200, y el envío de transacciones se limita con una cola global en vez de por par.
El exceso de lecturas y escrituras en disco durante el funcionamiento normal se debía a un fallo que Bitcoin Core 29.4 ya corrige: la base de datos chainstate reescribía una y otra vez buena parte de sí misma. La solución desactiva la seek compaction de LevelDB y compacta el chainstate de forma periódica (#35465).
Se acabó el trasiego de disco del chainstate en Bitcoin Core 30.3, que repara también un cierre inesperado de feebumper cuando no está disponible la comisión combinada de aumento (#34870) y un error de selección de monedas que calculaba un importe como booleano (#34888). En PSBT, las claves públicas MuSig2 ya se validan al deserializar pubnonces y firmas parciales (#34219).
Bitcoin Core 31.1 cierra una filtración de IP en -privatebroadcast: algunas conexiones salían por la clearnet en lugar de por la red de privacidad activada. La actualización acaba además con las reescrituras de chainstate que disparaban la actividad de disco y rechaza las listas vacías de claves públicas en la agregación de claves MuSig2 (#35316).
Un handshake v2 fallido puede dejar al descubierto la IP del remitente en Bitcoin Core 31.0: con -privatebroadcast activado, el reintento por v1 se salta el proxy de Tor y conecta directamente con el par. Lo más probable es que lo provoque un par malicioso que cierre el handshake a propósito. Hasta que salga la 31.1, se puede desactivar la función, fijar -v2transport=0 o enviar por Tor el tráfico saliente IPv4/IPv6.
Las versiones de Bitcoin Core posteriores a 0.14.0 y anteriores a 29.0 podían leer memoria ya liberada al validar un bloque inválido manipulado, lo que hacía caer el nodo. CVE-2024-52911 tiene gravedad alta, aunque el atacante debe gastar prueba de trabajo válida en la punta de la cadena, y se considera improbable la ejecución remota de código. Lo notificó Cory Fields; la corrección llega con 29.0.
El cluster mempool sustituye al diseño anterior en Bitcoin Core 31.0: los límites de ancestros y descendientes dan paso a clústeres de 64 transacciones y 101 kB como máximo, y desaparece el CPFP carveout. El -dbcache predeterminado sube a 1024 MiB en equipos con al menos 4096 MiB de RAM, y una nueva opción, -privatebroadcast, envía las difusiones de sendrawtransaction solo por Tor o I2P.
Dos fallos con monederos sin nombre quedan corregidos en Bitcoin Core 28.4: el de la migración de monederos heredados (#34156) y el de createfromdump, que al fallar borraba el directorio de monederos (#34215). También se retira una semilla DNS de chainparams (#33723).
Los pares que envían transacciones inválidas por consenso dejan de recibir castigo en Bitcoin Core 29.3 (#33050). La validación incorpora una caché de midstate de sighash por entrada para scripts legacy, P2SH y segwit v0 (#32473) y detecta el witness stripping sin volver a ejecutar las comprobaciones de Script (#33105), mientras que addPackageTxs, en el minero, se libra de un desbordamiento de entero sin signo (#33475).
Con Bitcoin Core 30.2 desaparece un fallo de migración en monederos heredados sin nombre (#34156), y createfromdump ya no borra el directorio de monederos cuando falla con uno de ellos (#34215). Pulsar Ctrl-C tampoco deja colgado el programa durante las llamadas de espera IPC (#33511).
En circunstancias poco frecuentes, una migración fallida de wallet.dat en Bitcoin Core 30.0 o 30.1 puede borrar todos los archivos del directorio de monederos y poner en riesgo los fondos. Los desarrolladores han retirado esos binarios y piden no migrar desde la GUI ni por RPC hasta la 30.2. El fallo requiere un wallet.dat predeterminado, sin nombre, que no consiga migrar o cargarse; al resto de usuarios no le afecta.
Los monederos de Bitcoin Core 30.1 dejan de tener en cuenta las monedas TRUC sin confirmar que tienen ancestros (#33528). En IPC, las opciones ya no exigen el argumento -m (#33229), el registro de mensajes consume menos (#33517) y las llamadas waitNext en curso se pueden cancelar (#33676).
Con transacciones no estándar manipuladas se podía ocupar un nodo de Bitcoin Core durante unos segundos cada una sin que desconectara al remitente, lo que permitía a un atacante retrasar la propagación de bloques. CVE-2025-46598, de gravedad baja, lo notificó Antoine Poinsot y se mitigó en v30.0 reduciendo el tiempo de validación en el peor caso.
Un bloque de más de 1 GB podía desbordar una comprobación de tamaño en nodos de Bitcoin Core de 32 bits y tumbarlos al escribir en disco, pero solo si llegaba como bloque compacto y contra una víctima con -maxmempool por encima de 3 GB y 1 GB de transacciones dentro. Pieter Wuille encontró CVE-2025-46597, de gravedad baja; limitar -maxmempool en sistemas de 32 bits lo cerró en 29.1 y 30.0.
