Un fallo en Core Lightning puede mantener un nodo atrapado en bloqueos repetidos incluso después de actualizarlo, porque el anuncio defectuoso que activa el problema queda guardado en el disco y debe borrarse de forma manual.

El investigador Nishant Bansal divulgó el caso y advirtió que, además del tiempo fuera de servicio, la caída puede impedir vigilar eventos del canal que requieren respuesta antes de un plazo.

El anuncio queda guardado y vuelve a disparar la caída

La vulnerabilidad afecta a Core Lightning desde la versión v25.02 hasta la v26.04, según la divulgación de Bansal, publicada el 24 de octubre. El problema aparece cuando el software recibe un anuncio de canal con una estructura malformada que acepta y guarda.

Los anuncios de canal informan a los nodos sobre las conexiones que forman parte del grafo de enrutamiento de Lightning. En el caso descrito, el mensaje identificaba al mismo nodo, hasta entonces desconocido, como ambos extremos de una conexión, una configuración que el programa vulnerable no rechazaba antes de conservarla.

Después de guardarse en el archivo gossip_store, el proceso que lo carga intenta insertar dos veces el mismo nodo en el grafo. Esa protección contra duplicados detiene gossipd, el componente que gestiona esos anuncios, y Core Lightning trata ese error como fatal para todo el nodo.

El resultado puede repetirse cada vez que el operador reinicia el servicio, porque el arranque vuelve a leer el registro que quedó guardado. Así, el problema no se limita al instante en que llega el anuncio: la entrada persistente puede convertir un primer bloqueo en una secuencia de reinicios fallidos hasta que alguien la retire.

El parche previene nuevos anuncios, pero no limpia el disco

Core Lightning incorporó la corrección mediante el PR #9082 el 24 de abril y la publicó en la versión v26.04.1 el 25 de abril. El cambio verifica el orden de los identificadores de los nodos antes de aceptar el anuncio y exige que el primero sea estrictamente menor que el segundo, con lo que también rechaza identificadores iguales.

La validación nueva impide que futuros anuncios con esa estructura lleguen a aceptarse y escribirse en el archivo local. Sin embargo, la actualización no revisa ni borra automáticamente los datos malformados que ya estaban guardados antes de instalarla, por lo que el inicio todavía puede encontrar el registro que dispara el fallo.

Por esa diferencia entre prevenir nuevas entradas y reparar datos existentes, instalar una versión corregida no basta necesariamente para restaurar un nodo afectado. Bansal indicó que el operador debe eliminar manualmente del gossip_store el registro problemático.

Bitcoin Optech destacó el problema el 30 de octubre, meses después de que el parche preventivo se incorporara al proyecto. La divulgación puso el foco en las consecuencias de un registro que sobrevive a la actualización, mientras que la corrección para impedir nuevas entradas estaba disponible desde abril.

La v26.04.1 fue la primera versión que incorporó la corrección para este defecto. El reporte de Bitcoin Optech también señala que las versiones anteriores a la v25.02 podían aceptar y retransmitir estos anuncios sin bloquearse por sí mismas, de modo que el mensaje podía propagarse por la red sin necesidad de conexión directa con cada nodo vulnerable.

La interrupción también puede poner fondos en riesgo

La consecuencia no se limita a perder disponibilidad del nodo o capacidad para procesar las tareas habituales de Lightning. Bansal advirtió que, mientras está fuera de línea, el operador no puede vigilar la cadena para detectar ciertos eventos relacionados con sus canales, lo que añade un riesgo financiero a la interrupción técnica.

Entre esos eventos está la posible publicación de un estado de canal revocado, ante el cual el nodo debe poder reaccionar. La divulgación también menciona reclamaciones de pagos con un plazo definido, que necesitan ejecutarse antes de su vencimiento; si el servicio permanece caído y el operador no actúa a tiempo, los fondos pueden quedar en riesgo.

La información disponible no cuantifica cuántos nodos han recibido el anuncio ni confirma pérdidas efectivas. Sí establece una cadena concreta de condiciones: el anuncio malformado se guarda, el inicio vuelve a cargarlo, la caída persiste hasta la limpieza manual y la desconexión puede impedir respuestas sensibles al tiempo.

Para los operadores, el punto central es revisar qué versión ejecutan y distinguir entre instalar una corrección preventiva y recuperar un nodo que ya conserva el registro problemático. La actualización puede cerrar la puerta a nuevos anuncios de este tipo, pero el dato almacenado exige una acción adicional para terminar con los bloqueos repetidos.