Core Lightning, una de las principales implementaciones de software utilizadas para operar nodos de pago Lightning de Bitcoin, ha lanzado la versión 26.06.10 con un nuevo conjunto de correcciones de seguridad, y sus mantenedores piden a todos los usuarios actualizar lo antes posible. La actualización acompaña el parche de software con una segunda tarea para los operadores: revisar las credenciales que permiten comandos remotos en sus nodos, un paso que los mantenedores describen como independiente de la instalación de la nueva versión. Combina el endurecimiento del plugin que gestiona comandos remotos con cambios en la forma en que los nodos evalúan la apertura de canales y las condiciones de pago.

Este es el tercer lanzamiento puntual consecutivo publicado sin período de embargo. Las versiones 26.06.8 y 26.06.9 siguieron el mismo enfoque, con correcciones hechas públicas de inmediato. Al igual que en esos lanzamientos, los mantenedores han vuelto a retener las pruebas vinculadas a las correcciones de seguridad. Según las notas de la versión, esto dificulta convertir las correcciones en exploits funcionales y da a los usuarios más tiempo para actualizar. El modelo de divulgación también define lo que está en juego para los operadores: una vez que un lanzamiento es público, también lo son las debilidades que aborda, lo que significa que un nodo rezagado ejecuta software con fallas documentadas.

Revisión de credenciales añadida a la lista de tareas de actualización

Los runes y commando están en el centro del trabajo de seguridad de esta actualización. Commando permite que un par conectado directamente solicite a un nodo ejecutar un comando, y el par generalmente necesita un rune —una credencial de autorización— para hacerlo.

La actualización cierra una forma de eludir los límites de los runes sobre los nombres de parámetros mediante nombres duplicados o con variantes de puntuación. También corrige un fallo de commando causado por reutilizar un ID de comando tras un comando fallido. Los runes de tamaño excesivo ahora son rechazados de forma directa; anteriormente, el software podía dedicar tiempo cuadrático a decodificarlos.

Los mantenedores recomiendan vincular cada rune utilizado a través de commando al ID de nodo de la aplicación que lo usa. Con esta restricción de id, el rune no puede utilizarse desde ningún otro lugar. También se indica a los operadores que pongan en lista negra cualquier rune que no puedan justificar usando el comando blacklistrune, y que luego emitan nuevos runes con restricciones más estrictas. En conjunto, los pasos equivalen a una auditoría de cada credencial que puede activar comandos remotos en un nodo, revocando los runes sin explicación antes de emitir los reemplazos.

Correcciones de canales y pagos

La nueva versión verifica las firmas de transacciones de un par durante la apertura de canales con financiamiento dual y el splicing, la operación que ajusta los fondos de un canal sin cerrarlo. Esto sigue la especificación BOLT 2 del protocolo Lightning, que cubre el establecimiento de canales y la operación normal entre pares, según el changelog.

Otra corrección trata sobre un contrato de pago condicional conocido como HTLC. Un HTLC recién eliminado podía confundirse con uno activo que compartiera su payment hash, monto y expiración, lo que hacía que el nodo fallara el pago activo mientras su par aún podía reclamarlo.

El manejo de aperturas de canales también es más estricto. Los nodos ahora rechazan las aperturas de canales cuando un par propone un límite de dust —el umbral bajo el cual los outputs se consideran dust— superior a 5,000 satoshis; el changelog indica que el comportamiento anterior permitía a un par convertir el saldo del nodo en comisiones durante un cierre forzado. Para aperturas con financiamiento dual, también se rechaza el límite de dust de un par superior a la reserva del canal, y una apertura v2 de confirmación cero —un canal que se activa antes de que su transacción de financiamiento sea confirmada— se rechaza a menos que el operador haya configurado el nodo para aceptarla de ese par. El financiamiento dual sigue siendo experimental, y los mantenedores desaconsejan canales de confirmación cero con pares que no sean de confianza.

Otros cambios ofrecen una respuesta predeterminada segura cuando falla un hook de plugin, en lugar de un fallo o bloqueo. Los aumentos de comisión de splicing ahora utilizan al menos 25/24 de la tasa de comisión previa, lo que requieren pares como Eclair. Los nodos que han ejecutado builds de desarrollo no pueden hacer downgrade a la serie 26.06.x porque su esquema de base de datos es más nuevo. El lanzamiento incluye binarios reproducibles para Ubuntu 22.04, 24.04 y 26.04, además de imágenes de Docker.

Divulgación y fechas de lanzamiento

Las fallas corregidas en este lanzamiento fueron reportadas por casi 20 fuentes identificadas, incluyendo The Bitcoin Red Team, Matt Morehouse y Niklas Gögge. Otras pidieron no ser nombradas.

GitHub indica una fecha de lanzamiento del 4 de noviembre para la versión, mientras que su changelog etiquetado muestra el 5 de noviembre. La actualización sigue a un fallo separado de trigger almacenado divulgado el 2 de noviembre. Al momento de la redacción, bitcoin cotizaba cerca de $76,002, con una caída del 5.29% en 24 horas.