Fallo de seguridad en Core Lightning: qué deben hacer ahora quienes gestionan un nodo

Si gestionas tu propio nodo Lightning con el software Core Lightning, hoy tienes exactamente una tarea: actualizar a la versión 26.06.7. Blockstream afirma haber publicado esta versión el 28 de agosto de 2026. Corrige varios fallos de seguridad confirmados, y todas las ediciones anteriores se consideran desde entonces sin soporte. Si no puedes actualizar de inmediato, reinicia el nodo con el modificador --offline. Cualquiera de las dos vías lleva pocos minutos, y ambas resultan más eficaces que la reacción que a muchos se les ocurre primero: apagar el equipo.

Si en cambio tienes Bitcoin en un exchange, en una cartera corriente o en una aplicación, sin gestionar tú mismo un nodo, el aviso no te afecta directamente. Se refiere a la máquina que administra tus canales de pago. Quien no gestione ninguna no tiene nada que actualizar. Aun así merece la pena echar un vistazo: el episodio muestra con qué rapidez un error de programación notificado se convierte en un plazo con fecha, y ahora mismo se está repitiendo a intervalos cortos.

Qué ha ocurrido: Core Lightning confirma fallos y publica una actualización de emergencia

Core Lightning, abreviado CLN, es una de las varias implementaciones de software de la red Lightning. La red Lightning es una segunda capa sobre la cadena de bloques de Bitcoin: dos partes bloquean conjuntamente un importe en una transacción y luego liquidan entre ellas tantas veces como quieran, sin inscribir cada pago por separado en la cadena. Esa conexión bloqueada se denomina canal de pago. El software que administra un canal así, lo vigila y lo defiende en caso de disputa recibe el nombre de nodo.

A finales de agosto, el equipo de CLN comunicó públicamente que durante semanas había tramitado un número inusualmente alto de informes de vulnerabilidades generados con ayuda de herramientas de inteligencia artificial. Varios de ellos resultaron auténticos. La indicación del proyecto en su propio canal fue escueta y contraria al primer impulso: no apagues el nodo bajo ningún concepto, reinícialo con --offline, porque ese modificador corta las conexiones con otros nodos y cierra así la vía de ataque.

Los relatos difieren sobre la secuencia exacta, y conviene señalarlo, porque de ello depende la valoración de cuánto tiempo estuvieron abiertos los fallos. El servicio especializado CryptoSlate fecha la llegada de los primeros informes generados con inteligencia artificial el 13 de agosto y un primer anuncio del proyecto el 23 de agosto. Otros informes, entre ellos el de TFTC, sitúan el aviso público el 26 de agosto y hablan de unos diez días de margen. El final de esa cadena está documentado y no se discute: el 28 de agosto la versión corregida estaba disponible como archivo firmado.

Hasta ahora no se han notificado pérdidas

Según el estado de la información en el momento de la divulgación, no hubo pérdidas de fondos confirmadas ni ningún caso conocido en el que alguien explotara realmente uno de los fallos. Se trata de una instantánea y no de un cese de la alerta: el núcleo técnico de los defectos permanece bajo reserva hasta mediados de septiembre, y solo después podrá comprobarse de forma independiente cuál fue realmente el tamaño de la ventana.

¿Me afecta a mí? La respuesta depende de quién gestione tu nodo

El aviso se refiere al software Core Lightning. En el comunicado del proyecto no se menciona ninguna otra implementación de la red Lightning. Para ti, la cuestión se resuelve siguiendo una línea sencilla:

• Gestionas tu propio nodo con Core Lightning, por ejemplo en un pequeño servidor doméstico, en una máquina alquilada o en un paquete cerrado como Umbrel o Start9: eres el destinatario. Actualizar o --offline, hoy.
• Gestionas tu propio nodo con otra implementación: este aviso no se dirige a ti. Mantener una disciplina general de actualización sigue siendo razonable, porque los avisos de este tipo llegan ahora con poca separación.
• Usas una cartera Lightning en el móvil cuyo nodo gestiona otra persona: entonces la obligación de actualizar recae en ese proveedor y no en ti. Reconoces estas ofertas porque nunca actualizas ningún software ni pagas tú mismo la apertura de un canal. Qué cartera sigue cada vía lo ordena nuestra comparación de carteras de software.
• Solo tienes Bitcoin en un exchange o en un dispositivo físico, sin usar Lightning: el episodio no toca tu saldo.

Esta distinción importa más de lo que parece. Los avisos de este tipo se resumen enseguida en noticias sobre toda la red Lightning. El círculo de destinatarios es más estrecho: abarca a quienes gestionan un software concreto en una edición concreta.

Versión 26.06.7: por qué las ediciones anteriores ya no tienen soporte

La versión corregida lleva el número 26.06.7. La nota del proyecto al respecto es breve y tajante: las ediciones anteriores a la 26.06.7 ya no tienen soporte. Eso no significa que un nodo más antiguo se detenga, porque técnicamente sigue funcionando. Significa que para esos estados ya no llegarán correcciones de seguridad y que una vía de ataque conocida quedará abierta en cuanto se publique el código fuente.

En la fecha conviene ser preciso, porque los datos difieren ligeramente: la entrada del blog de Blockstream está fechada el 28 de agosto de 2026, mientras que en la tienda de aplicaciones de Umbrel esa misma versión lleva la del 29 de agosto. La diferencia se explica por el paso a través de las fuentes de paquetes y no cambia el fondo. Lo que importa es el número, no el día.

La siguiente versión regular, con el número 26.09, sigue prevista para finales de septiembre según el proyecto. Quien pase ahora a la 26.06.7 tendrá que repetir la operación dentro de pocas semanas. Eso aconseja dejar bien montada la vía de actualización una vez, en lugar de buscarla cada vez.

Comprobar la firma: así confirmas que el archivo procede del proyecto

La indicación del proyecto, traducida literalmente, dice: comprobar las firmas de los archivos, instalar, reiniciar. Ese orden no es un adorno. Una firma es una rúbrica criptográfica con la que los desarrolladores confirman que un archivo procede de ellos sin alteraciones. Sin esa comprobación, una actualización de seguridad sería el cebo ideal: el usuario espera un archivo nuevo, lo busca de forma activa y lo instala con permisos elevados.

En este caso el motivo es especialmente tangible. Como el código fuente se retiene, durante las dos primeras semanas nadie puede reconstruir qué contiene el archivo. La firma es por tanto, de momento, el único indicio sobre su procedencia. Quien actualiza mediante un paquete cerrado no descarga por su cuenta y deja esa comprobación al proveedor del paquete, lo que desplaza la tarea sin suprimirla.

La segunda comprobación llega más tarde

En cuanto el código fuente esté a la vista, el software podrá reconstruirse a partir de él y compararse con el archivo que habrá estado funcionando dos semanas. Si ambos coinciden, quedará demostrado a posteriori que el archivo firmado no contenía nada distinto de lo que el proyecto publicó. Ese segundo paso está al alcance de cualquiera, y precisamente en él se apoya el compromiso del proyecto.

Qué desactiva realmente el modificador --offline en un nodo Lightning

El modificador --offline es una opción de arranque del software del nodo. El proyecto describe así su efecto: elimina la vía de ataque al quitar a los atacantes la posibilidad de dirigirse siquiera al nodo, mientras el programa sigue funcionando y leyendo la cadena de bloques para detectar intentos de fraude.

En la práctica esto significa que el nodo ya no acepta conexiones desde fuera ni establece ninguna por su cuenta. No puedes enviar ni recibir pagos, y los pagos encaminados de otras personas dejan de pasar por ti. En cambio, todo lo que ocurre en la cadena de bloques tu nodo lo sigue viendo, y puede reaccionar a ello.

El precio queda por tanto claramente dicho: la disponibilidad de tus canales termina mientras el modificador esté activo. Para un nodo privado eso es una incomodidad. Para un nodo por el que pasan con regularidad pagos ajenos, es una pérdida de ingresos. CryptoSlate señala que un número suficiente de actualizaciones tardías y de nodos apagados podría reducir de forma apreciable la capacidad de encaminamiento en partes de la red.

Por qué apagar el equipo es peor que el modo sin conexión

Aquí está el punto en el que los consejos bienintencionados causan daño. La reacción evidente ante un aviso de seguridad es apagar el aparato. En un nodo Lightning esa es la peor de las dos opciones, y el motivo está en cómo se construyen los canales de pago.

Un canal de pago queda respaldado por el último saldo firmado conjuntamente. Cualquiera de las partes puede cerrar el canal de forma unilateral en cualquier momento a través de la cadena de bloques, lo que se conoce como cierre forzoso. Si al hacerlo una contraparte presenta un saldo antiguo que le resulta más favorable, se trata de un intento de fraude. Contra eso protege un plazo de impugnación: dentro de una ventana acordada, la parte perjudicada puede presentar una transacción de penalización y recibe en ese caso todo el contenido del canal.

Ese plazo corre en tiempo de bloques y no en tiempo natural, y corre con independencia de si tu equipo está encendido. Un nodo apagado no lee la cadena de bloques, no advierte el intento de fraude y deja pasar el plazo. Eso es exactamente lo que el proyecto quiere decir al afirmar que un nodo apagado no puede cumplir esa función. El modo sin conexión, en cambio, deja el programa en marcha y la cadena leyéndose, y solo retira las conexiones.

Quien usa una torre de vigilancia dispone de un margen

Una torre de vigilancia es un servicio que observa la cadena de bloques en tu lugar y presenta la transacción de penalización en caso de fraude mientras tu propio nodo duerme. Quien tenga configurado un servicio así queda en mejor posición durante una interrupción. No deberías confiarte, porque muchos nodos privados funcionan sin él y su configuración no es un paso menor.

Umbrel y Start9: cómo llega la actualización de seguridad a los nodos de un clic

Muchos nodos privados funcionan con paquetes cerrados provistos de una interfaz en lugar de con la línea de comandos. Allí no encontrarás --offline como botón del panel; es una opción de arranque de la aplicación. Por eso la vía de la tienda de aplicaciones tiene aquí una historia propia, que se sigue bien en la entrada de Umbrel.

Allí apareció primero, el 27 de agosto, una versión intermedia con el número 26.06.6-patch.1. Su nota explicaba que el nodo seguía funcionando y vigilando la cadena de bloques de Bitcoin, pero que de momento no podía enviar, recibir ni reenviar pagos Lightning. La indicación que la acompañaba era clara: dejar Core Lightning en marcha y no eliminarlo, la siguiente actualización aparecería como de costumbre en cuanto la corrección estuviera lista.

El 29 de agosto llegó la 26.06.7 con la nota de que se trataba de una actualización de seguridad importante y de que el nodo volvería a conectarse automáticamente a la red Lightning después. Para los usuarios de estos paquetes eso significa dos cosas. El modo sin conexión pudo llegar ya de forma automática, sin que nadie accionara un modificador. Y la funcionalidad completa solo regresa con la segunda actualización. Si llevas unos días preguntándote por qué no sale un pago, aquí tienes la explicación.

Código fuente solo el 11 de septiembre: qué hay detrás del embargo

Un embargo es en este contexto un plazo de reserva acordado durante el cual no se publican los detalles técnicos de un fallo. Lo habitual es aplicarlo entre quien notifica y el fabricante antes de la corrección. Aquí el caso es distinto: la corrección ya está publicada y, aun así, el código fuente permanece bajo reserva hasta el 11 de septiembre de 2026, es decir, catorce días después de la entrega.

El razonamiento es práctico. A partir de una corrección publicada puede deducirse el defecto que repara. Quien dispone del código fuente ve qué líneas han cambiado y a menudo sabe antes que el defensor dónde arranca el ataque. El informe de TFTC atribuye ese razonamiento al desarrollador principal de CLN, Christian Decker: los detalles técnicos se retienen precisamente para impedir que los atacantes construyan con ellos un ataque operativo.

En contra puede objetarse que el software de código abierto obtiene su verificabilidad justamente de que cualquiera puede leerlo. Durante dos semanas funciona en los nodos un archivo cuyo contenido nadie ajeno al proyecto puede reconstruir. Ambas partes tienen un argumento, y ambas se refieren al mismo periodo. La discusión solo podrá zanjarse después del 11 de septiembre, cuando resulte posible comparar el código fuente con el archivo entregado.

Informes de vulnerabilidades generados con IA: el patrón detrás de la emergencia

El desencadenante de este episodio es tan llamativo como su desarrollo. Los defectos no proceden de una auditoría planificada. Llegaron como una avalancha de informes generados con herramientas de inteligencia artificial. Una parte era descarte, otra parte era auténtica, y distinguir ambas le costó semanas al proyecto.

Para un software mantenido de forma voluntaria eso supone una carga nueva. Quien recibe informes debe revisarlos uno por uno, porque pasar por alto un hallazgo auténtico sería el error más caro. Al mismo tiempo, el esfuerzo del lado de quienes producen esos informes tiende a cero. La relación entre ataque y defensa se desplaza así de forma apreciable.

Core Lightning no es un caso aislado en esto. TFTC encuadra el episodio en una serie y cita como ejemplo anterior el 3 de agosto, cuando el servicio de intercambio Boltz suspendió sus swaps aludiendo a ataques asistidos por inteligencia artificial. Quien haya seguido las últimas semanas conoce el patrón también en el terreno del hardware: hemos descrito hace poco cómo BitBox02 cerró tres fallos de seguridad con el firmware 9.26.5 y por qué en Coldcard la semilla antigua no debería reutilizarse en todos los casos tras una actualización de firmware. La rapidez con la que instalas una actualización de seguridad ha pasado así de asunto marginal a rutina.

Qué significa el incidente para la custodia de tus bitcoins

De un episodio como este no se sigue que la autocustodia sea un error. De él se sigue una división que compensa al margen de este caso: un nodo Lightning es un aparato conectado de forma permanente a la red, que acepta conexiones de desconocidos y necesita claves mientras funciona. Un sistema así sigue siendo un sistema caliente, por muy cuidadosamente que se mantenga.

De ahí resulta un reparto sencillo de tus posiciones. En el canal de pago va el importe que realmente necesitas para pagar. Todo lo que exceda de eso corresponde a una custodia cuyas claves nunca estén en un equipo con conexión a la red, como la que describe nuestra comparación de carteras físicas. La tarea que la acompaña es el respaldo de las palabras de recuperación, sobre la que hemos reunido qué aportan realmente el acero, la frase de contraseña y el multifirma.

La segunda conclusión afecta a la velocidad. Entre el aviso y la versión corregida transcurrieron unos dos días según los datos disponibles. Quien en ese tiempo no se entera del aviso, porque no sigue ni al proyecto ni a su fuente de paquetes, se queda fuera de la ventana. Una vía de notificación configurada forma parte del equipamiento de una infraestructura gestionada por uno mismo y no de sus comodidades.

Revisar el fallo de Core Lightning: qué conviene retener

1. Comprueba hoy la versión de tu nodo y actualiza a la 26.06.7. Si no es posible de inmediato, reinicia con --offline y realiza la actualización después. Si no tienes claro qué software hay detrás de tu pago Lightning, lo aclara la comparación de carteras de software.
2. Separa con limpieza las posiciones calientes y frías. En el canal queda lo que necesitas para pagar, el resto pasa a una custodia sin conexión permanente a la red. Qué dispositivos lo consiguen figura en la comparación de carteras físicas.
3. Apunta el 11 de septiembre en tu lista. Ese día se publica el código fuente, y solo entonces podrá comprobarse el archivo que ha estado funcionando y valorarse el alcance de los fallos. Las herramientas con las que seguir posiciones y acontecimientos las reúne nuestro panorama de plataformas de análisis.

Las pruebas sólidas figuran en el comunicado del proyecto sobre la versión 26.06.7 (Blockstream, 28 de agosto de 2026) y en la entrada de la tienda de aplicaciones de Umbrel con las notas sobre ambas actualizaciones (Umbrel App Store).

(30 de agosto 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.)