Core Lightning ha corregido un fallo en la gestión del cierre de canales que podía permitir a un nodo transmitir un estado antiguo y revocado sin activar la penalización prevista para los intentos de engaño. El problema quedó solucionado en la versión v26.06.7, aunque el proyecto recomienda actualizar directamente a la v26.06.8, que incorpora correcciones de seguridad adicionales.
La vulnerabilidad afectaba a una situación concreta de los canales de Lightning Network. En condiciones normales, los participantes sustituyen los compromisos anteriores a medida que cambia el saldo del canal. Si uno de ellos publica un compromiso revocado, la otra parte debe poder reclamar una penalización.
Antes del parche, Core Lightning podía interpretar como cierre cooperativo una transacción de financiación cuyos resultados coincidieran con scripts de cierre ya registrados. Esa comprobación podía ocultar que, en realidad, se estaba difundiendo un compromiso antiguo.
Un escenario condicionado por la configuración del canal
El riesgo no se aplicaba indistintamente a todos los canales. Para que el escenario fuera posible, el participante no debía haber establecido un script de cierre inicial al abrir el canal. Más adelante, podía incluir en un mensaje de cierre el script de salida correspondiente al compromiso revocado.
Con esa coincidencia, la transacción podía parecer legítima para el software. El nodo podía entonces abandonar el cierre cooperativo y emitir el compromiso antiguo, evitando la ruta que habría permitido reclamar la penalización. El análisis publicado por Bitcoin Optech el 25 de septiembre recoge este mecanismo a partir de las notas de los mantenedores y de una prueba de regresión incorporada al proyecto.
La documentación describe una vía potencial para eludir la penalización, no un robo confirmado de fondos. Además, se trata de un problema específico de la implementación de Core Lightning y de su gestión de canales, no de un cambio o una vulnerabilidad en las reglas de la cadena principal de Bitcoin.
Qué deben revisar los operadores
Los operadores que utilicen una versión anterior a la v26.06.7 deben actualizar sus nodos. Core Lightning aconseja emplear la v26.06.8, publicada posteriormente y con otras correcciones de seguridad. El hecho de ejecutar una versión afectada no implica, por sí solo, que todos los canales puedan explotarse: el escenario del cierre revocado requiere la configuración específica descrita.
El proyecto también ha pedido revisar las imágenes de Docker utilizadas durante el despliegue inicial de la v26.06.7. Según las notas de esa versión, algunas imágenes distribuidas bajo esa etiqueta y otras relacionadas entre el 28 de agosto y el 1 de septiembre mostraban la nueva versión al iniciar el nodo, pero no contenían las correcciones correspondientes.
Los operadores deben comprobar el resumen criptográfico de la imagen instalada. Si no coincide con los valores corregidos que publica el proyecto, la recomendación es volver a descargarla.
Una corrección desplegada por fases
La secuencia de versiones muestra que el arreglo se distribuyó en varias etapas. Core Lightning publicó la v26.06.7 el 28 de agosto y liberó inicialmente de forma restringida el código fuente relacionado el 11 de septiembre. El cambio pasó después a la rama principal de desarrollo mediante la solicitud de cambios 9509, integrada el 15 de septiembre.
La v26.06.8 llegó el 22 de septiembre con otras correcciones de seguridad y con el código fuente disponible de inmediato, aunque algunas pruebas permanecieron temporalmente reservadas. El informe de Bitcoin Optech del 25 de septiembre detalló el fallo de los cierres con estados revocados, ya corregido en las versiones publicadas.
La reparación modifica el orden de las comprobaciones: Core Lightning analiza primero los campos de tiempo de bloqueo y de secuencia de la transacción para identificar un compromiso, antes de utilizar sus salidas como posible indicio de un cierre mutuo.
