¿Core Lightning actualizado con Docker? Así compruebas si el parche está de verdad

Cuando tu nodo de Core Lightning muestra v26.06.7 al arrancar, eso todavía no demuestra que las correcciones de seguridad de esa versión estén funcionando de verdad. Quien haya descargado su actualización por Docker entre el 28 de agosto de 2026 a las 16:04 UTC y el 1 de septiembre puede estar ejecutando una imagen que se identifica correctamente y aun así no contiene las correcciones. La prueba sólida es el digest de la imagen, y no lo que muestra la versión. Este texto te guía por la comprobación necesaria y por lo que hay que hacer después.

La situación ha cambiado en dos puntos desde nuestro artículo del 30 de agosto: la ventana defectuosa de Docker está ya documentada en la nota de versión, y el embargo sobre el código fuente venció el 11 de septiembre. Ambas cosas modifican lo que tienes que hacer como operador.

Qué es Core Lightning y por qué te afecta esta actualización

Core Lightning (antes c-lightning) es una de las tres implementaciones extendidas del protocolo Lightning, escrita en C y mantenida en el repositorio ElementsProject/lightning. Una implementación es sencillamente un programa independiente que aplica las mismas reglas de red que los programas de la competencia, pero tiene código propio y, por tanto, también fallos propios.

La red Lightning en sí es una segunda capa sobre la cadena de bloques de Bitcoin: dos partes bloquean fondos conjuntamente en un canal de pago y a continuación liquidan entre ellas tantos pagos como quieran sin escribir cada uno de ellos en la cadena. Quien opera un nodo así custodia él mismo las claves de ese dinero bloqueado. Justo eso es lo que vuelve seria la cuestión: un fallo en el software del nodo afecta de forma inmediata a Bitcoin que es tuyo y del que no cuida nadie más.

La autocustodia significa responsabilidad propia, y esa responsabilidad no termina al guardar la clave. Incluye también la pregunta de si el software que usa esa clave se corresponde con el estado que crees tener instalado. Quien prefiera mantener sus fondos sin un servicio de servidor permanente encontrará los aparatos para ello en nuestra comparativa de carteras de hardware. Para un nodo Lightning, en cambio, no hay manera de evitar mantener actualizado el software en funcionamiento.

Qué salió mal con la imagen de Docker de la versión 26.06.7

La versión 26.06.7 apareció el 28 de agosto de 2026 como versión de mantenimiento. El comunicado del proyecto es escueto: se trataría de una versión intermedia que corrige vulnerabilidades confirmadas, comunicadas al equipo en las tres semanas anteriores. Una versión intermedia es una entrega que contiene únicamente correcciones y ninguna función nueva.

Para los usuarios de Docker, algo se torció por el camino. La nota de versión se amplió después con un apartado que llama al fallo por su nombre: entre el 28 de agosto a las 16:04 UTC y el 1 de septiembre, cuatro etiquetas sirvieron imágenes que al arrancar informaban de v26.06.7 pero no contenían las correcciones de esa versión. Estaban afectadas v26.06.7, latest, v26.06.7-vls y latest-vls.

La causa la nombra el propio proyecto: un proceso automático de compilación había publicado las imágenes a partir de una etiqueta de relleno. Entretanto han sido sustituidas, y los manifiestos erróneos ya no están referenciados por ninguna etiqueta. Un manifiesto es el archivo descriptivo que determina de qué piezas se compone una imagen de contenedor. Quien todavía tenga la versión equivocada en local no notará nada de esa corrección: en tu máquina se queda lo que descargaste entonces.

Hay un punto que exculpa por completo a una parte de los operadores. Quien estuviera fijado a v26.06.6 o a una versión anterior no estuvo afectado en ningún momento, según indica el proyecto. El problema alcanza únicamente a quienes descargaron 26.06.7 o latest dentro de la ventana citada.

Por qué el número de versión al arrancar no prueba el nivel de parche

La comprobación más evidente es también la inútil. Una llamada que te muestra la versión en ejecución se limita a leer una cadena de caracteres escrita en el programa durante la compilación. Si esa cadena procede de una etiqueta de relleno, un programa sin parchear informa fielmente del número que se le dio y no te dice nada sobre el código real.

Ese es el punto incómodo de nuestro propio artículo del 30 de agosto: allí te hicimos comprobar la versión. Para los operadores de Docker de la ventana afectada, esa vía de comprobación no valía nada, sin que entonces pudiera saberse. Por eso está aquí esta continuación, y por eso la comprobación es a partir de ahora otra.

El digest es el valor de control que identifica de forma unívoca una imagen de contenedor. Es un hash criptográfico sobre el manifiesto, es decir, sobre el contenido real de la imagen. Una etiqueta como latest es un puntero móvil que hoy puede señalar a una imagen y mañana a otra. El digest no puede hacerlo: si cambia un solo byte del contenido, cambia el valor. Es, por tanto, el único dato que te dice qué estás ejecutando realmente.

¿Estás afectado? La ventana temporal, las etiquetas y las tres plataformas

Tres preguntas aclaran el caso. Primera: ¿obtuviste siquiera el software como contenedor? Quien instaló los archivos comprimidos de la página de publicación nunca estuvo afectado, porque esos archivos fueron los correctos desde el principio. Segunda: ¿tu descarga cayó en la ventana entre el 28 de agosto a las 16:04 UTC y el 1 de septiembre? La nota de versión no indica una hora exacta para el final de esa ventana, así que queda un resto de imprecisión, y en la duda es mejor comprobar una vez de más. Tercera: ¿utilizaste una de las cuatro etiquetas citadas?

Quien tenga dudas en las tres preguntas siempre acierta con la comprobación del digest. Esa comprobación te cuesta una sola orden y responde a la pregunta de forma definitiva, da igual cuándo y cómo obtuvieras la imagen.

Para las imágenes de esta versión hay tres plataformas: linux/amd64, linux/arm64 y linux/arm/v7. La tercera tiene una particularidad que atañe a quienes usan pequeños ordenadores de placa única: para linux/arm/v7 no existe archivo comprimido de publicación. Los programas de esa plataforma se compilan aparte y no están cubiertos por ningún manifiesto firmado. Quien trabaje sobre esa arquitectura parte, por tanto, de una cadena de prueba más débil que en las otras dos. Además, según indica el proyecto, las imágenes no llevan atestaciones de procedencia ni SBOM, es decir, ningún justificante de origen legible por máquina.

Así compruebas el digest de la imagen de tu nodo Lightning

La orden que menciona la nota de versión lee el digest de la imagen disponible en local. Tiene este aspecto:

docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7

La salida es el valor que tienes que comparar. El proyecto indica dos valores de referencia para las imágenes corregidas. Para las etiquetas v26.06.7 y latest es sha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4. Para la variante de firmante bajo v26.06.7-vls y latest-vls es sha256:6a5e05c13a65613f8c0fe3830c60248a6724e7206c1c23dd26ac2e98a3e72c1f.

Dos indicaciones sobre la ejecución. La orden consulta exclusivamente tu almacén local, no descarga nada y no modifica nada. Y se refiere a la etiqueta que le indiques: quien trabaje con latest pone latest; quien opere la variante de firmante, la etiqueta -vls correspondiente. Si el valor mostrado coincide carácter por carácter con el de referencia, has terminado y estás ejecutando la versión corregida.

Lo importante es el cotejo a lo largo de toda la cadena. Un vistazo rápido a los cuatro primeros y los cuatro últimos caracteres no basta, porque justo esa es la parte que una persona da por buena con un «ya vale» cuando duda. Copia ambos valores uno al lado del otro y compáralos con la máquina, por ejemplo escribiendo el valor de referencia en un archivo y contrastando la salida contra él.

El digest no coincide: así descargas la imagen corregida

Si el valor difiere, la solución no tiene nada de espectacular. Descargas la imagen de nuevo, y además para cada etiqueta que uses realmente:

docker pull elementsproject/lightningd:v26.06.7
docker pull elementsproject/lightningd:latest

Después compruebas otra vez el digest con la misma orden de arriba. Solo cuando el valor nuevo coincide con el de referencia reinicias el contenedor, para que el proceso en marcha utilice de verdad la imagen fresca. Un pull por sí solo no cambia un contenedor en ejecución; tu nodo sigue funcionando con el estado antiguo hasta el reinicio.

Quien opere contenedores mediante un archivo Compose o un orquestador debe cuidar que la configuración no recaiga en un estado local almacenado en caché. Lo más limpio es fijar después el propio digest comprobado en lugar de la etiqueta móvil. Así la misma confusión ya no puede repetirse, porque la referencia queda atada al contenido y no a un nombre.

Un cambio menor puede llamar la atención en el reinicio: en las imágenes actuales, Core Lightning se instala en /usr/bin y /usr/libexec/c-lightning, mientras que las imágenes anteriores usaban /usr/local. Se incluyen enlaces simbólicos desde las ubicaciones antiguas, de modo que las rutas fijas siguen funcionando. Quien tenga scripts propios con rutas absolutas debería repasarlos de todas formas una vez.

Operadores de VLS: por qué el firmante tiene que encajar con la versión del nodo

VLS significa Validating Lightning Signer y designa un servicio de firma separado que custodia las claves del nodo y comprueba cada firma contra sus propias reglas antes de emitirla. La idea de fondo: aunque el nodo quede comprometido, un atacante no puede convencer al firmante de autorizar pagos arbitrarios.

Para estos operadores hay un canto duro en el salto a 26.06.7. La variante v26.06.7-vls contiene, según el proyecto, el mismo firmante que v26.06.6-vls, a saber, VLS v0.14.0, que esta entrega deja intacto. El firmante exige, eso sí, que la variable VLS_CLN_VERSION encaje con el nodo con el que habla. Si ahí sigue puesto v26.06.6 mientras el nodo corre con v26.06.7, remote_hsmd_socket se niega a arrancar.

Es incómodo, pero benigno en el resultado: el servicio directamente no arranca, en lugar de seguir funcionando en un estado a medias. Ajusta la variable durante la actualización y el firmante seguirá accesible. Quien interprete mal el mensaje y devuelva el nodo a la versión antigua para que el firmante funcione está deshaciendo justo la corrección de la que aquí se trata.

El embargo ha vencido: qué significa para los nodos sin parchear

El proyecto había retenido deliberadamente el código fuente de esta versión. La justificación está en la nota de versión: un parche muestra qué código modifica, y el retraso debía reducir la probabilidad de que los atacantes reconstruyeran las correcciones y las aprovecharan antes de que la red se actualizara.

Ese plazo ha terminado. La nota de versión lo dice ya literalmente: «The embargo has ended. The source for this release was published on 2026-09-11T11:42Z.» La etiqueta v26.06.7 apunta desde entonces al commit a partir del cual se compilaron los programas, y el archivo fuente acompaña a la publicación.

Para ti como operador, eso invierte la situación de riesgo. Hasta el 11 de septiembre, un nodo sin parchear estaba protegido también por el hecho de que los atacantes no conocían los detalles. Esa protección ha desaparecido sin sustituto, porque desde entonces los cambios se pueden consultar públicamente. Quien no haya actualizado hasta hoy está ejecutando un software cuyas vulnerabilidades están documentadas y a la vista de cualquiera. El proyecto deja constancia además de que las versiones anteriores a 26.06.7 ya no reciben soporte.

Un detalle llamativo al margen, y que se lee en los propios metadatos de la publicación: el archivo de firma de las sumas de comprobación de amd64 no se subió hasta el 12 de septiembre de 2026 a las 06:02 UTC. Quien quisiera comprobar antes la firma no la encontraba para esa arquitectura. El archivo de sumas de comprobación, en cambio, estaba disponible desde el 28 de agosto.

Por qué el apaño --offline no sustituye a la actualización

En el comunicado del proyecto del 28 de agosto figuraba un paso intermedio para todos los que no pudieran actualizar de inmediato. Un reinicio con el modificador --offline aísla el nodo de los mensajes entrantes y les quita así a los atacantes la vía para dirigirse siquiera a él. El servicio sigue funcionando y procesa la cadena de bloques, de modo que todavía puede detectar un intento de fraude del socio de canal. El proyecto escribe al respecto que el modificador debe retirarse tras la actualización y reiniciarse el nodo.

Ese apaño estaba pensado para el tiempo sin detalles públicos. Desde el 11 de septiembre ya no sustituye a la actualización y solo cubre las horas que necesites hasta ponerte al día. Un nodo aislado no reenvía pagos, no gana comisiones y resulta inalcanzable para sus contrapartes. Como estado permanente, es una parada cara.

La misma rutina de comprobación merece la pena para otras piezas de tu propia instalación. Quien ponga una interfaz de administración delante del nodo debería conocer también su accesibilidad desde la red; para Alby Hub describimos ese camino el 11 de septiembre. El punto de partida de esta serie de vulnerabilidades está en nuestro artículo del 30 de agosto, Core Lightning: qué deben hacer ahora los operadores de nodos.

¿Instalado sin Docker? Así verificas sumas de comprobación y firmas

Quien obtiene los archivos comprimidos desde la página de publicación tiene la mejor vía de prueba, pero también tiene que recorrerla. Cada archivo de programa está cubierto por un manifiesto firmado. Primero compruebas las sumas de comprobación:

sha256sum -c SHA256SUMS-v26.06.7 --ignore-missing

Después, la firma sobre ese archivo de sumas de comprobación:

gpg --verify SHA256SUMS-v26.06.7.asc SHA256SUMS-v26.06.7

El archivo SHA256SUMS-v26.06.7 cubre los paquetes de amd64; para arm64 hay un archivo propio con su propia firma. Firmaron cuatro mantenedores del proyecto, cuyas huellas digitales enumera la nota de versión una por una. Un detalle te ahorra una falsa alarma: una firma puede informar de una huella distinta de la listada, porque quienes firman usan subclaves. En cuanto la clave principal está importada, gpg --verify lo resuelve por sí mismo, y la divergencia no es un fracaso de la comprobación.

Hay una segunda prueba más rápida, y es la parte verdaderamente elegante de esta publicación. El archivo de sumas de comprobación contenía desde el principio una línea para el archivo fuente clightning-v26.06.7.zip, aunque ese archivo todavía no era público el 28 de agosto. Como el archivo se firmó entonces, constituye un compromiso adquirido por adelantado sobre exactamente los bytes que ahora están publicados. Con ello se puede demostrar en minutos y sin compilador que el código fuente visible hoy es el mismo que se firmó en agosto, y que durante el embargo no se modificó nada.

Compilación reproducible: dónde termina la cadena de prueba de esta versión

Una compilación reproducible es un proceso que genera, a partir del mismo código fuente, exactamente el mismo archivo de programa byte a byte. Permite a terceros demostrar de forma independiente que un archivo publicado procede realmente del código fuente publicado. En esta versión eso vale solo de forma limitada, y el proyecto nombra él mismo las limitaciones.

En primer lugar, los paquetes no se compilaron con el nivel de optimización estándar. La configuración usa por defecto -Og, mientras que los programas publicados se generaron con -O3. Quien descargue la etiqueta y compile de forma normal obtiene archivos que no encajan con las sumas de comprobación; hay que indicar expresamente COPTFLAGS=-O3. En segundo lugar, los paquetes de arm64 no son recompilables a partir de este estado, porque la herramienta necesaria para ello no está en el árbol de fuentes de esta versión. Esos archivos siguen siendo comprobables por la firma, pero no reproducibles de forma independiente. En tercer lugar, el proyecto advierte de que la recompilación en Fedora puede divergir, porque allí la imagen de compilación se actualiza de nuevo en cada ejecución y dos personas en días distintos pueden encontrarse con versiones de herramientas diferentes.

Todo esto hay que leerlo como la descripción honesta de una cadena de prueba con huecos, y no como una crítica a quienes participan. Para ti como operador significa en la práctica: fíate de la firma y de la suma de comprobación, y trata la recompilación completa como una tarea de especialistas y no como un paso de tu rutina de mantenimiento.

Qué muestra este incidente sobre las cadenas de suministro del software cripto

La lección de fondo está en la entrega y no en la vulnerabilidad en sí. El fallo surgió en un proceso automático de compilación que publicó una imagen a partir de un relleno. Nadie tuvo que ser atacado para ello, y aun así estuvo disponible durante días un archivo que hacía lo incorrecto mientras afirmaba lo correcto.

El propio proyecto menciona en la nota de versión un motivo por el que estas versiones de mantenimiento serán previsiblemente más frecuentes: se emplean modelos de inteligencia artificial cada vez más capaces para rastrear posibles vulnerabilidades en código abierto, lo que aumenta notablemente el número y el ritmo de los avisos. Quien opere infraestructura tendrá que actualizar más a menudo, con lo que la pregunta de cómo se verifica una actualización pasa a ser más importante que la de si se ha realizado.

De ahí se derivan tres costumbres que cuestan poco tiempo. Ata los contenedores a digests en lugar de a etiquetas móviles. Después de cada actualización, comprueba el contenido y no la etiqueta. Y anota qué versión con qué valor de control desplegaste y cuándo, para que en el próximo aviso sepas en minutos si te afecta. Quien no quiera dedicar ese esfuerzo a un servicio de servidor permanente debería plantearse con honestidad si una solución de custodia más ligera encaja mejor con su día a día.

Comprobar la actualización de Core Lightning: lo que te llevas de aquí

1. Comprueba hoy el digest y no el número de versión. Una orden, una comparación con el valor de referencia de la nota de versión, y la pregunta queda respondida. Si al hacerlo te das cuenta de que operar un nodo propio se te hace demasiado trabajoso, con nuestra comparativa de carteras de hardware obtienes una visión de las alternativas a la autocustodia pura mediante servidor.
2. Vuelve a descargar y reinicia si el valor difiere. Descargar de nuevo, comprobar otra vez el digest, cambiar el contenedor y solo después retirar el modificador --offline. Para todo lo que ejecutes luego como software en el nodo merece la pena mirar la comparativa de carteras de software, porque allí cuenta esa misma pregunta por las vías de actualización y los justificantes de origen.
3. Orienta tu mantenimiento hacia los valores de control. Fijar el digest, controlar sumas de comprobación y firmas tras cada descarga, documentar el estado. Y si quieres refinanciar canales, encontrarás las vías en nuestro panorama sobre cómo comprar Bitcoin.

(15 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)

Fuentes primarias: la nota de versión de Core Lightning v26.06.7 en el repositorio del proyecto, así como el comunicado de Blockstream sobre la publicación.