v0.14.1
Versión de Eclair que contiene soluciones críticas para el flujo de apertura de canales 2
300 MB
Memoria asignada y descartada por un solo mensaje init de longitud máxima en versiones anteriores de Eclair 1
1 MB per second
Tasa de fuga de memoria causada por la explotación de la condición de carrera en open_channel 2
48 minutes
Tiempo necesario para que una sola conexión haga colapsar un nodo con un heap de 4 GB mediante la saturación de canales no financiados 2

Visión general de las vulnerabilidades de Eclair

Divulgaciones recientes en materia de seguridad han revelado múltiples vulnerabilidades de denegación de servicio (DoS) que afectan a Eclair, una popular implementación de nodos de Lightning Network 12. El investigador de seguridad Matt Morehouse publicó los detalles de estas vulnerabilidades en Delving Bitcoin 12. Los fallos identificados afectan a las versiones de Eclair v0.13.1, v0.14.0 y anteriores 12. Para proteger sus sistemas, se recomienda a los operadores de nodos que actualicen a la versión v0.14.1 de Eclair o posterior 2.

Aunque algunos de los problemas subyacentes se abordaron parcialmente en la versión v0.14.0 de Eclair, lanzada en mayo, la protección completa contra los exploits del flujo de apertura de canales requiere la versión v0.14.1 12.

Detalles de los vectores de inicialización y gossip

El primer conjunto de vulnerabilidades está relacionado con los protocolos de intercambio de claves de inicialización (handshake) y de consultas de gossip 1. Cada ataque requiere únicamente haber completado el handshake BOLT8, no un canal activo 1. Una de las vulnerabilidades radica en la forma en que Eclair analizaba los bits de características (feature bits) dentro de un mensaje de inicialización 1. Debido a que el nodo analizaba estos bits de manera individual, asignaba múltiples objetos para cada bit 1. En consecuencia, un solo mensaje de inicialización de longitud máxima podía asignar y descartar aproximadamente 300 MB de memoria mientras monopolizaba un hilo de procesamiento durante un máximo de 300 ms 1. Durante las pruebas, un atacante que utilizó unas pocas docenas de conexiones para repetir este mensaje logró desconectar con éxito a todos los pares del nodo en un minuto y agotar su memoria en cinco minutos 1. Morehouse descubrió este error utilizando un fuzzer llamado smite 1.

Se encontró otra vulnerabilidad en la gestión de consultas de gossip por parte de Eclair 1. A pesar de que la especificación BOLT7 eliminó la codificación zlib para mensajes de consulta específicos en abril de 2022, Eclair siguió aceptándolos 1. Dado que la descompresión zlib de Eclair carecía de un límite de salida, un mensaje de 64 kB podía descomprimirse hasta los 64 MB y generar unos 17 millones de objetos 1. Una ráfaga masiva de estos mensajes podía dejar fuera de servicio a un nodo Eclair en cuestión de segundos 1. Morehouse localizó este fallo mediante el uso de un modelo de lenguaje de gran tamaño (LLM) para buscar errores de asimetría de recursos en el código fuente 1.

Fallos en el flujo de apertura de canales

Otras dos vulnerabilidades apuntan al flujo de apertura de canales de Eclair 2. La primera, designada como LNF-2026-0003, es una condición de carrera en open_channel 2. En la versión v0.14.0 de Eclair y anteriores, existe un retraso entre la comprobación de ID de canales temporales duplicados y la inserción de un nuevo canal en el mapa del nodo 2. Un atacante puede explotar este retraso mediante el procesamiento en cadena (pipelining) de mensajes idénticos, lo que hace que Eclair genere dos actores de canal para un solo ID 2. El segundo actor sobrescribe al primero, dejando un actor huérfano que consume aproximadamente 25 KB de memoria heap 2. Explotar esta condición de carrera de forma repetida genera una fuga de aproximadamente 1 MB de memoria por segundo, lo que acaba provocando un colapso del sistema 2.

El segundo fallo en el flujo de apertura de canales es una saturación por canales no financiados 2. Los atacantes pueden eludir el limitador de tasa (rate limiter) de Eclair reutilizando el ID final de un canal como el ID temporal de la siguiente solicitud 2. Este truco hace que el limitador de tasa rastree el ID dos veces y elimine ambas entradas a la vez, lo que permite que el número de canales pendientes crezca indefinidamente 2. Debido a que cada canal pendiente almacena características del par que ocupan unos 65 KB, una sola conexión puede agotar un nodo con un heap de 4 GB en aproximadamente 48 minutos 2. Al persistirse estos canales, el nodo colapsará repetidamente al reiniciar hasta que la base de datos se limpie manualmente o se incremente el tamaño del heap 2.

Impacto más amplio en Lightning Network

Aunque las vulnerabilidades detalladas se dirigen específicamente a Eclair, otras implementaciones populares de Lightning Network también están recibiendo mantenimiento y actualizaciones de seguridad 1. Por ejemplo, LND lanzó la versión v0.21.4-beta.rc1, que es una versión candidata (release candidate) para un lanzamiento de mantenimiento 1. Esta versión candidata de LND incluye una corrección para la sincronización de anuncios de canales e introduce una restricción para los nuevos canales heredados (legacy) 1.

El descubrimiento de los errores en Eclair también pone de relieve la evolución del papel de las herramientas de prueba automatizadas 12. Morehouse utilizó tanto el fuzzer especializado para Lightning Network smite como un entorno de pruebas basado en LLM para identificar estos fallos arquitectónicos profundos 12. La herramienta basada en LLM mapeó específicamente los puntos de entrada y los invariantes del código fuente para buscar violaciones tomando como referencia las especificaciones BOLT 2.

Lo que aún no está establecido

  • Si los nodos de Core Lightning están afectados por vulnerabilidades similares, ya que las divulgaciones facilitadas solo detallan Eclair y LND 12.
  • El cronograma exacto de cuándo todos los operadores de nodos Eclair activos completarán sus actualizaciones a la versión v0.14.1 o posterior 2.
  • Si otras implementaciones de Lightning Network presentan condiciones de carrera similares en sus flujos de apertura de canales 2.

Preguntas frecuentes

¿Qué versiones de Eclair son vulnerables a estos ataques de denegación de servicio?

Las versiones v0.13.1 y v0.14.0 de Eclair, así como todas las versiones anteriores, son vulnerables a estos exploits 12.

¿Cómo puede un atacante explotar la condición de carrera en open_channel?

Un atacante puede procesar en cadena mensajes open_channel idénticos para eludir las comprobaciones de duplicados, lo que genera dos actores de canal para un solo ID y filtra aproximadamente 1 MB de memoria por segundo 2.

¿Qué herramientas se utilizaron para descubrir estas vulnerabilidades de Eclair?

Las vulnerabilidades fueron descubiertas por Matt Morehouse utilizando el fuzzer smite y un entorno de pruebas basado en LLM que contrasta los puntos de entrada del código fuente con las especificaciones BOLT 12.

Fuentes

  1. Bitcoin Optech — Bitcoin Optech Newsletter #425 (2026-10-02) https://bitcoinops.org/en/newsletters/2026/10/02
  2. Delving Bitcoin — Disclosure: DoS vulnerabilities fixed in Eclair v0.14.1 (2026-10-01) https://delvingbitcoin.org/t/disclosure-dos-vulnerabilities-fixed-in-eclair-v0-14-1/2928

Esta nota es informativa y educativa. No es asesoramiento financiero ni una recomendación de compra o venta.