Qué pasó
El 27 de agosto de 2026 un desarrollador llamado Erick Cestari publicó cómo tumbó un nodo Lightning a base de ser pesado. Se conectó al nodo, le hizo la misma pregunta sencilla una y otra vez, y después se tapó los oídos. El nodo siguió apuntando respuestas que nadie recogía hasta que se quedó sin memoria y el sistema lo mató.
Lo encontró por casualidad, mientras construía su propia versión del software que usan los nodos Lightning para hablar entre ellos. Lo reportó en privado el 25 de agosto de 2025 y esperó un año antes de decir nada en público.
Qué cambia
Lightning es una red de ordenadores que se pasan pagos en bitcoin unos a otros, para que los pagos pequeños no necesiten cada uno su propio hueco en un bloque. Esos ordenadores se llaman nodos, y comprueban constantemente que los vecinos a los que están conectados siguen vivos.
La forma de comprobarlo es un ping. Un nodo manda un ping, el otro devuelve un pong, y el primero sabe que la línea sigue abierta. Hay un detalle raro en las reglas: el nodo que manda el ping decide de qué tamaño tiene que ser la respuesta. Puede pedir un pong de hasta 65.531 bytes, más o menos el texto de un capítulo corto de un libro.
El ataque de Cestari usa eso. Conectarse a un nodo, pedirle el pong más grande posible, y volver a pedirlo, miles de veces, sin leer nunca una sola respuesta. El nodo es educado. Escribe cada pong y los va apilando a la espera de enviarlos. La pila no tenía límite. En un servidor pequeño con 2 GB de memoria bastó un atacante para llenarla; cien vecinos fingidos lo hicieron más rápido.
Lo interesante es por qué el nodo no tenía límite aquí y sí lo tiene en todo lo demás.
Core Lightning reparte su trabajo entre varios programas. El que se ocupa de la conexión
se llama connectd, y cuando le pasa un mensaje a otro de los programas espera primero a
que ese programa esté listo. Los ingenieros lo llaman backpressure: dejas de aceptar
trabajo nuevo hasta terminar el anterior. Un supermercado hace lo mismo cuando corta el
paso a una escalera mecánica que va llena.
Los pings nunca iban a otro programa. connectd los respondía él mismo, así que nunca
pasaban por esa puerta, así que nada le decía nunca que frenara. Un atajo alrededor de una
puerta: ese era todo el fallo.
El atacante no necesita casi nada para hacerlo. Ni un canal de pago abierto, ni bitcoin, ni siquiera una identidad real: solo el saludo mínimo para que lo traten como vecino.
Qué no cambia
A nadie le quitaron monedas, y este fallo no podía quitarlas. Tumbar un nodo no es lo mismo que gastar desde él. Las claves siguen donde estaban, y el nodo vuelve a levantarse cuando alguien lo reinicia.
El arreglo también es viejo. Salió en Core Lightning v25.09 el 2 de septiembre de 2025, ocho días después del reporte, y cualquiera que haya actualizado en el último año ha estado a salvo todo el tiempo. Las notas de la versión no lo mencionaban, y eso es lo normal: nombrar un arreglo de seguridad en un changelog les dice a los atacantes exactamente dónde mirar mientras la mayoría de la gente sigue con la versión antigua.
Aun así no es nada, y sería un error archivar quedarse sin conexión como algo inofensivo. Un nodo Lightning caído no puede vigilar la cadena, y vigilar la cadena es parte de cómo se protege. Si el vecino con el que compartes un canal intenta cerrarlo publicando una versión antigua y más favorable del saldo común, hay una ventana para pillarlo y quedarse con el canal entero como penalización. No se puede pillar nada mientras el nodo se reinicia. Dejar a alguien sin conexión primero es un paso real de un ataque real, aunque la caída por sí sola no robe nada.
Contexto
Aquí el hueco es de un año: arreglado en ocho días, explicado doce meses después. Es deliberado, y es el mismo argumento que dio Blockstream en agosto cuando publicó una versión de seguridad de Core Lightning con el código fuente retenido durante dos semanas. Un arreglo es un mapa. Publicar el mapa antes de que la gente se haya movido les dice a los lectores equivocados dónde estaba el tesoro.
Cestari encontró esto escribiendo su propia implementación del mismo protocolo, que es la manera habitual en que aparecen estas cosas. Alguien lee las reglas con suficiente atención como para construir a partir de ellas y se fija en una frase que nadie había apretado. Eso es un argumento a favor de que exista más de una implementación, y es mejor que cualquiera de las versiones tribales.