El fallo que vació nodos Lightning era un robo de credenciales, y el proyecto cerró el acceso remoto a LND 19 minutos antes de que existiera el parche

El aviso de emergencia del viernes decía «actualiza o apaga el servidor» y poco más. El documento que BTCPay Server ha publicado después ya dice qué robaron y cómo: un atacante remoto y sin autenticar podía sacar del servidor los ficheros con extensión .macaroon, que son las credenciales que autorizan a operar un nodo Lightning de LND. Quien tiene esos ficheros manda en el nodo y puede mover el dinero. Es un robo de llaves, no un robo de monedas, y por eso el parche no cerró el incidente.

El proyecto lo confirma sin rodeos en su aviso de seguridad: hubo explotación real, hubo usuarios afectados y hubo fondos robados. Sigue sin haber cifra ni recuento de nodos, dos días después. Y hay una marcha atrás importante respecto a las primeras instrucciones, las que recogimos aquí el viernes por la tarde: los monederos de cadena de BTCPay, incluidos los calientes generados dentro del programa, no están afectados. Lo de mover ese dinero se pidió, en palabras del propio equipo, por exceso de precaución.

Una credencial copiada sobrevive a la actualización

Un macaroon es un testigo de autorización con permisos dentro: se presenta al nodo y el nodo obedece. No caduca por sí solo y no se invalida porque el servidor que lo guardaba se actualice. De ahí sale la secuencia que describieron las víctimas el viernes, y que el aviso ahora encaja: Zach Herbert, de Foundation, la empresa del monedero Passport, contó que le cerraron todos los canales y barrieron los saldos «durante la noche», con el monedero caliente de BTCPay intacto. Ese detalle, que entonces parecía una casualidad afortunada, resulta ser la firma del ataque: el atacante nunca tuvo el monedero, tuvo el nodo.

El aviso acota el perímetro con precisión poco habitual. Solo está expuesto quien use LND. Quien corra Core Lightning u otra implementación, o no use Lightning, no tiene el problema de credenciales, aunque se le recomienda actualizar igual. Los monederos de cadena de BTCPay quedan fuera, y hay una excepción que conviene leer despacio: el dinero que esté en el monedero de cadena de LND sigue en riesgo, porque ese monedero es parte del nodo comprometido. Y las versiones candidatas de la propia 2.4.2 también traían el fallo, así que quien probaba la release candidate estaba tan expuesto como quien no había actualizado nada.

Hemos confirmado que los atacantes explotaron esta vulnerabilidad. Hubo usuarios afectados y se robaron fondos. Todavía no publicamos los detalles técnicos porque los operadores necesitan tiempo para actualizar.

El proxy se cerró antes de que existiera el parche

La parte que nadie ha contado está en el otro repositorio del proyecto, el de los despliegues con Docker, que es como está montada la mayoría de las instalaciones. Descargué su registro de comits y la cronología no coincide con la versión pública. El primer movimiento no fue el parche: a las 15:11:50 UTC del viernes entró un comit titulado «Do not expose LND anymore» que borra once líneas de la plantilla de configuración del proxy inverso. Lo que desaparece son dos bloques: el que enrutaba las llamadas gRPC de lnrpc, routerrpc, verrpc y walletrpc hacia el puerto 10009 del contenedor de LND, y el que servía la API REST del nodo bajo la ruta /lnd-rest/btc/.

La versión 2.4.2 se publicó a las 15:31:16 y el aviso en la cuenta del proyecto salió a las 15:51. O sea que el acceso remoto al nodo se cerró 19 minutos y 26 segundos antes de que hubiera parche disponible y 39 minutos y 10 segundos antes de que alguien fuera del equipo supiera que había un ataque en marcha. Tiene lógica defensiva: si el problema es que se están fugando credenciales de LND, lo primero que se hace es quitar de internet la puerta donde esas credenciales sirven. Pero significa que la primera medida de contención fue silenciosa y quirúrgica, y que el equipo sabía dónde estaba el fuego antes de decirlo.

Core Lightning entró en la lista y salió 35 minutos después

El mismo registro guarda el rastro del momento en que el equipo aún no sabía hasta dónde llegaba el agujero. A las 17:02:59 entró un comit llamado «Do not expose CLN REST anymore» que borra seis líneas más, las de la ruta /clightning-rest/btc/, es decir el acceso remoto a los nodos de Core Lightning. A las 17:38:20, treinta y cinco minutos y veintiún segundos más tarde, ese comit se revierte y la ruta vuelve.

Esa ida y vuelta es la traducción operativa de la frase del aviso que dice que, «tras una revisión posterior», se confirmó que solo LND estaba afectado. La conclusión se publica como certeza; el repositorio enseña que durante media hora fue una sospecha con la que se cortó el acceso a los usuarios de otra implementación. Nada de eso es reprochable en una respuesta a incidente, pero explica por qué las instrucciones del viernes y las del sábado no dicen lo mismo, y por qué medios como TFTC siguen recomendando mover los fondos de los monederos calientes que el aviso ya ha declarado a salvo.

La rotación de todas las credenciales es una variable de entorno

El viernes escribimos que actualizar no bastaba y que había que regenerar los macaroons a mano. Una hora y veintidós minutos después de que publicáramos eso, el proyecto lo automatizó, y el cambio cabe en una línea. A las 19:40:37 UTC se subió la imagen de LND de la 0.21.0-beta a la 0.21.1-beta; a las 22:11:03 entró el comit «Triggering macaroon regeneration», que añade una única variable de entorno al fragmento de Docker del contenedor: LND_MACAROON_ROTATION_ID: "lnd-security-2026-08-v1". Un fichero, una línea añadida, cero borradas. Eso es lo que hace que cada nodo que actualice destruya sus credenciales viejas y emita otras.

Hay un matiz que el aviso no aclara y que conviene decir: LND 0.21.1-beta no es una versión de seguridad. Se publicó el 30 de junio, 38 días antes de todo esto, y sus notas dicen expresamente que no trae migraciones. El salto de versión no arregla nada del lado de LND; es el vehículo que fuerza la reconstrucción de la imagen y, con ella, la rotación. Sumadas las horas, entre el aviso público de las 15:51 y el comit que rota las credenciales pasaron 6 horas y 20 minutos, y hasta la última modificación del documento de seguridad, 22:59:46, pasaron 7 horas y 9 minutos. En esa ventana había operadores ya actualizados a 2.4.2 y todavía con los macaroons robados en manos de otro.

El precio de cerrar la puerta lo paga el comerciante

El cierre del proxy no es un detalle interno. Como confirma Cointelegraph, la 2.4.2 retira el acceso público a la API de LND en los despliegues con Docker, así que un monedero externo como ZEUS deja de poder conectarse al nodo propio a través del dominio de BTCPay o de su dirección onion de Tor. Los cobros siguen funcionando; lo que se rompe es administrar el nodo desde el móvil, que para mucha gente era la razón de montarlo así. El proyecto dice que restaurará la opción cuando sea seguro y ofrece ayuda para buscar otra configuración a quien depende de ella.

Y queda el aviso que se aplica solo: quien exponga su LND por su cuenta, con un proxy propio, un servicio Tor o un puerto abierto, tiene que rotar credenciales él mismo. Actualizar BTCPay no cierra caminos que BTCPay no administra. Es la misma lección de la semana en el software de Bitcoin, con el sprint de auditoría con IA que declaró 85 fallos críticos y con Boltz apagando sus swaps: la superficie de ataque no es el programa, es el conjunto de puertas que cada operador ha ido abriendo por comodidad.

La otra cara

Contra la lectura de que esto es un desastre de gestión hay tres cosas concretas. La primera es que el perímetro se ha reducido, no ampliado: al final del fin de semana la lista de afectados es más corta que el viernes, y una rectificación a la baja es una buena noticia para quien movió fondos por si acaso. La segunda es que la respuesta se puede auditar minuto a minuto desde fuera, comits incluidos, algo que con software cerrado no existe ni como posibilidad. La tercera es la asignación de mérito: el aviso agradece a Craig Raw, autor del monedero Sparrow, la comunicación responsable del fallo, y al equipo que analizó el ataque. Según CoinDesk, los agradecimientos incluyeron también a Rob Hamilton, Calle y Evan Kaloudis.

El contrapeso serio es el silencio sobre las cifras. No hay importe robado, no hay número de nodos, no hay recuento de servidores sin parchear. Sin eso, ningún comerciante puede calibrar si lo suyo fue mala suerte o estadística. El equipo promete un análisis técnico completo y pide disculpas a los afectados, y de momento retiene los detalles a propósito para que los operadores tengan tiempo de actualizar, lo que es defendible y a la vez deja a cualquiera sin manera de comprobar si su nodo estuvo expuesto. El mercado, como es habitual con estas roturas, no se ha enterado: bitcoin cotiza a 64.756 dólares con una bajada del 0,32% en 24 horas y ether a 1.912,91 con un 0,18% de descenso.

Datos y fuentes: aviso de seguridad de BTCPay Server, repositorios btcpayserver-docker y lnd en GitHub, CoinDesk, Cointelegraph, TFTC, CoinGecko.