Core Lightning v26.06.9 se publicó el 07-10-2026 como una actualización correctiva orientada a operadores de nodos. Según lo comunicado, corrige una regresión de v26.06.8 que podía retrasar el tráfico de los canales en nodos con alta actividad, así como un caso límite de pagos durante el cierre de canales. La versión también refuerza las autorizaciones y la configuración. Se recomendó actualizar a los usuarios de v26.06.8, mientras que los nodos que hayan ejecutado master tendrían restricciones para degradar a versiones 26.06.x debido a cambios en el esquema de la base de datos.

Core Lightning v26.06.9 se dirige a los operadores de la versión 26.06.8

Core Lightning v26.06.9 parece ser una versión correctiva orientada a operadores, no una actualización cosmética. Los cambios comunicados se concentran en tres áreas: una regresión de v26.06.8 que podía limitar a los pares y retrasar el tráfico de los canales en nodos muy cargados, un caso límite de pagos durante el cierre de un canal que podía poner en riesgo fondos reenviados y mejoras menores en torno a runes y la gestión de la configuración.

Esta urgencia encaja con la propia estructura de lanzamientos del proyecto. La documentación de Core Lightning señala que la nota de lanzamiento en GitHub es el texto principal y que esa misma redacción se reutiliza posteriormente para el anuncio en la lista de correo y el blog de lanzamiento. Por ello, incluso sin reproducir aquí la nota exacta del parche, esta versión debe entenderse más como una medida operativa relevante que como una actualización de mantenimiento secundaria. La siguiente cuestión es por qué las dos correcciones principales importan por razones distintas.

Las dos correcciones comunicadas abordan riesgos operativos diferentes

La regresión comunicada en v26.06.8 es un problema de enrutamiento y rendimiento, mientras que la incidencia de pagos durante el cierre se plantea como un caso límite de protección de fondos. Según la descripción de la versión, los mensajes rutinarios de v26.06.8 se contabilizaban contra un presupuesto de CPU destinado a las consultas de gossip. En nodos con alta actividad, esto podía limitar a los pares y ralentizar el tráfico de los canales. La versión 26.06.9 reserva ese presupuesto para las consultas de gossip, eliminando la causa de la ralentización.

La segunda corrección aborda un modo de fallo distinto. La nota de lanzamiento indica que, si un canal se estaba cerrando al llegar la fecha límite de un pago, los fondos reenviados podían quedar expuestos salvo que el nodo forzara el cierre del canal. La versión 26.06.9 modifica este comportamiento y fuerza el cierre en ese escenario.

Conviene no confundir este cambio con el trabajo previo sobre cierre de canales incluido en 26.06. En el anuncio oficial de Blockstream sobre Core Lightning 26.06, la línea general de lanzamientos introdujo por separado una regla para esperar 72 bloques, en lugar de 12, antes de cerrar canales durante determinadas ventanas de disputa. Es un antecedente útil sobre la seguridad del cierre de canales, pero no es el mismo mecanismo que la corrección comunicada en v26.06.9 para los plazos de pago. En términos prácticos, el parche parece abordar tanto el comportamiento del nodo bajo carga como un caso límite más específico durante el cierre, lo que ayuda a explicar la firme recomendación de actualizar.

Los refuerzos y los límites para revertir la versión elevan la presión operativa

Además de las dos correcciones principales, se informó de que v26.06.9 endurece varios comportamientos sensibles desde el punto de vista de la seguridad. La descripción de la versión señala que las runes restringidas ya no pueden crear otras sin restricciones ni volver a listar runes incluidas en listas negras; el comando listconfigs ahora oculta los valores sensibles, y setconfig bloquea la inyección de configuración mediante opciones persistentes. Estos cambios hacen que la versión sea relevante no solo para nodos de enrutamiento, sino también para operadores preocupados por los límites de autorización y una administración más segura.

El mismo informe señala que las pruebas de seguridad se retuvieron temporalmente para dificultar el desarrollo de exploits. También indica que los nodos que hayan ejecutado master no pueden degradar a una versión 26.06.x debido a cambios en el esquema de la base de datos. Estos detalles elevan las implicaciones operativas, pues sugieren que algunos usuarios pueden tener menos margen tanto para examinar el parche de forma independiente de inmediato como para planificar vías de reversión.

La conclusión más útil es acotada: los operadores afectados deben tratar la versión 26.06.9 como una actualización de mantenimiento importante, mientras que los detalles más precisos —como las etiquetas formales de gravedad, la exposición exacta por rol y cualquier procedimiento de reversión compatible— siguen dependiendo de los materiales de lanzamiento específicos del parche publicados por el proyecto.