Bitcoin Core revela vulnerabilidad crítica que afectó a nodos durante años

Un fallo de alta severidad en Bitcoin Core permitió potencialmente el cierre remoto de nodos mediante bloques especialmente diseñados. Aunque el parche fue lanzado hace más de un año, una parte importante de la red todavía podría ejecutar versiones vulnerables del software.

***

• Bitcoin Core divulgó el fallo CVE-2024-52911 tras corregirlo silenciosamente en 2025.
• El error afectó versiones desde Bitcoin Core 0.14.0 hasta la rama 28.x.
• Cerca del 43% de los nodos aún podrían ejecutar software vulnerable, según estimaciones citadas por The Block.

Bitcoin Core publicó oficialmente esta semana los detalles de una vulnerabilidad clasificada como de alta severidad que afectó durante años al principal software utilizado para operar nodos de Bitcoin. El fallo, identificado como CVE-2024-52911, podía permitir que un atacante provocara el cierre remoto de nodos mediante bloques inválidos especialmente diseñados.

La divulgación pública ocurrió el 5 de mayo de 2026, aunque la corrección fue incluida silenciosamente meses antes en Bitcoin Core v29.0, lanzado en abril de 2025. De acuerdo con la información oficial del proyecto y reportes citados por The Block, el error impactaba todas las versiones desde Bitcoin Core 0.14.0 hasta la línea 28.x.

El problema fue catalogado como un “use-after-free”, un tipo de vulnerabilidad de manejo de memoria que ocurre cuando un programa intenta acceder a memoria previamente liberada. En ciertos contextos, este tipo de errores puede derivar en cierres inesperados de software o incluso en ejecución remota de código.

Bitcoin Core, que es el software de referencia y la columna vertebral técnica de la red Bitcoin, explicó que el fallo estaba relacionado con el sistema de validación paralela de scripts de transacciones dentro de nuevos bloques. Bajo determinadas condiciones, un hilo de validación en segundo plano podía seguir intentando acceder a datos que ya habían sido destruidos en memoria.

Según el informe técnico publicado por el equipo de desarrollo, un atacante capaz de minar un bloque inválido con suficiente prueba de trabajo podía explotar esta condición para provocar el cierre de nodos vulnerables. Aunque el proyecto indicó que la ejecución remota de código era teóricamente posible debido a la naturaleza del error, aclaró que las restricciones sobre los datos de entrada hacían poco probable ese escenario.

Cómo funcionaba el fallo

Bitcoin Core detalló que, durante la validación de bloques, el software precalcula ciertos datos necesarios para verificar las entradas de las transacciones y los almacena temporalmente mediante estructuras conocidas como PrecomputedTransactionData.

Estos datos eran utilizados posteriormente por procesos paralelos de validación llamados CScriptCheck. El problema surgía porque esos procesos almacenaban punteros hacia la información precalculada, en lugar de almacenar directamente los datos.

En condiciones normales, esto no representaba un inconveniente. Sin embargo, cuando el sistema encontraba un error temprano durante la validación de un bloque inválido, algunos hilos secundarios podían seguir intentando acceder a información ya eliminada de memoria.

El origen técnico del fallo estaba relacionado con el orden de destrucción de objetos locales en C++. Según explicó Bitcoin Core, la clase encargada de controlar la vida útil de los procesos de validación (CCheckQueueControl) era inicializada antes que los datos precalculados. Debido a las reglas de destrucción inversa del lenguaje, la memoria asociada a esos datos era liberada antes de finalizar completamente las verificaciones paralelas.

El resultado era una ventana potencial donde un hilo de validación podía acceder a memoria ya liberada, provocando comportamientos indefinidos y posibles cierres del nodo.

Vale señalar que Bitcoin Core es el programa (cliente) que permite a los usuarios interactuar con la red, validar transacciones y asegurar que se cumplan las reglas del protocolo.

Un ataque costoso y poco práctico

A pesar de la gravedad técnica del problema, el propio diseño económico de Bitcoin habría actuado como barrera natural frente a ataques reales.

Para explotar la vulnerabilidad, un atacante necesitaba minar bloques inválidos utilizando prueba de trabajo legítima. Esto implicaba consumir poder computacional y energía para producir bloques que inevitablemente serían rechazados por la red y no generarían recompensas de minería.

The Block destacó que esta condición probablemente evitó que la vulnerabilidad fuera explotada activamente en la práctica, ya que cualquier atacante tendría pérdidas garantizadas al intentar ejecutar el ataque.

Bitcoin Core también aclaró que las reglas de consenso de Bitcoin nunca estuvieron comprometidas. El fallo afectaba exclusivamente el manejo interno de memoria de los nodos y no alteraba el comportamiento de la blockchain ni las validaciones de consenso entre participantes de la red.

El descubrimiento fue atribuido a Cory Fields, investigador afiliado a MIT Digital Currency Initiative, quien reportó privadamente la vulnerabilidad el 2 de noviembre de 2024 junto con una prueba de concepto y una propuesta de mitigación.

Cuatro días después, el desarrollador Pieter Wuille implementó discretamente una corrección dentro del pull request #31112. Según explicó The Block, el cambio fue deliberadamente presentado bajo un título aparentemente inocuo —“Improve parallel script validation error debug logging”— para evitar llamar la atención de potenciales atacantes antes de que la mayoría de operadores actualizara sus nodos.

La solución fue integrada oficialmente en diciembre de 2024 y posteriormente incluida en Bitcoin Core 29.0 en abril de 2025.

Millones de nodos podrían seguir expuestos

La divulgación pública ocurrió recién después de que la línea 28.x alcanzara el final de su ciclo de soporte el 19 de abril de 2026. Con ello, los desarrolladores consideraron que existía suficiente margen para revelar los detalles técnicos completos.

Sin embargo, la publicación vino acompañada de una advertencia relevante para la red.

De acuerdo con una estimación ampliamente citada basada en el panel de Clark Moody, cerca del 43% de los nodos Bitcoin todavía podrían ejecutar versiones anteriores a v29 y seguir expuestos al problema.

Esto implica que una porción significativa de operadores de nodos aún no habría actualizado sus clientes pese a la existencia del parche desde hace más de un año.

El desarrollador de Bitcoin Core Niklas Gögge afirmó en la red social X que se trata del “primer problema de seguridad relacionado con memory safety” registrado en los avisos públicos del proyecto en aproximadamente dos años.

La divulgación ocurre además en un contexto de creciente discusión sobre la seguridad futura de la infraestructura Bitcoin. En semanas recientes, investigadores propusieron nuevas iniciativas enfocadas en mitigar potenciales riesgos asociados a computación cuántica y protección de direcciones antiguas vinculadas a los primeros años de la red.

Aunque el fallo CVE-2024-52911 ya fue corregido en versiones recientes del software, el episodio vuelve a poner atención sobre la importancia de mantener actualizados los nodos que sostienen la infraestructura descentralizada de Bitcoin.