Los nodos de Eclair, una de las implementaciones de Bitcoin Lightning, pueden volver a quedarse sin memoria cada vez que se reinician si no han instalado el parche correspondiente. El problema afecta a las versiones 0.14.0 y anteriores y permite a un par malicioso acumular solicitudes de apertura de canales sin llegar a emitir la transacción de financiación en la cadena.
La vulnerabilidad fue divulgada el 30 de septiembre por el investigador Erick Cestari, que detalló sus implicaciones en una publicación técnica. El fallo ya había sido corregido antes de hacerse público: ACINQ incorporó el cambio el 17 de julio y Eclair 0.14.1 se publicó el 29 de julio.
Solicitudes acumuladas sin pagar comisiones en la cadena
Eclair limita el número de canales pendientes que un mismo par puede abrir. Sin embargo, el tratamiento inconsistente de los identificadores temporales y definitivos de los canales hacía que el contador pudiera infravalorar los canales aún no financiados.
Un atacante podía aprovechar esa diferencia para enviar numerosas solicitudes y lograr que el nodo las guardase, sin necesidad de aportar los bitcoins que normalmente exige la financiación de un canal ni de pagar una comisión de transacción en la red de Bitcoin. El ataque sí requiere tráfico de red y capacidad de cálculo, pero no que el atacante inmovilice fondos en la cadena.
El riesgo principal es para la disponibilidad del nodo. En la prueba de concepto de Cestari, realizada con Eclair 0.14.0 en regtest, el entorno local de pruebas de Bitcoin, la máquina virtual de Java agotó una memoria de 4 GB después de aproximadamente 47 minutos y 43 segundos. En ese momento, la base de datos de canales había acumulado 217.623 registros.
Ese resultado corresponde a una prueba concreta y no establece cuánto tardaría el ataque en todos los entornos. Tampoco demuestra que la vulnerabilidad se haya explotado activamente ni permite determinar cuántos nodos siguen ejecutando una versión afectada.
Reiniciar el nodo no elimina la carga almacenada
La particularidad del fallo es que el primer colapso no borra los registros fraudulentos. Eclair los conserva en disco y vuelve a cargarlos durante el arranque. Como consecuencia, el proceso puede agotar de nuevo la memoria antes de recuperar el servicio.
Cestari señaló como posibles medidas de recuperación aumentar temporalmente el tamaño de la memoria disponible o eliminar de forma manual los registros falsos de la base de datos. Reiniciar repetidamente el nodo, por sí solo, no resuelve el problema porque la carga subyacente permanece almacenada.
La corrección introducida en Eclair 0.14.1 reforzó las comprobaciones de canales duplicados y aborda este fallo de denegación de servicio. La versión también corrige otro problema, identificado por Matt Morehouse, de lnfuzz, como LNF-2026-0003. En ese caso, una condición de carrera durante la apertura de canales podía dejar procesos huérfanos consumiendo memoria o capacidad de procesamiento. Según el aviso, el nodo probado se recuperaba al desconectar el par o reiniciar, sin pérdidas, un comportamiento distinto del provocado por la acumulación persistente en la base de datos.
El parche mínimo no cubre todas las vulnerabilidades recientes
ACINQ recomienda actualmente actualizar a Eclair 0.14.3, publicada el 14 de septiembre, debido a otras vulnerabilidades corregidas en esa versión. Entre ellas figuran problemas de seguridad distintos que podían permitir a nodos maliciosos provocar pérdidas de fondos.
Por tanto, instalar la versión 0.14.1 o posterior resuelve los dos fallos de denegación de servicio descritos, pero no debe interpretarse como la recomendación de seguridad vigente para los operadores. Evitar nuevas solicitudes de canales no financiados y recuperar una base de datos ya sobrecargada son, además, problemas operativos separados.
