Qué pasó
El 7 de agosto de 2026 el proyecto BTCPay Server publicó un
aviso de seguridad
pidiendo a los operadores que actualizaran de inmediato. El fallo, presente en todas las
versiones anteriores a la 2.4.2, "podía permitir a un atacante remoto sin autenticar obtener
los ficheros de credenciales .macaroon de LND", y esas credenciales "podían usarse para tomar
el control de un nodo LND y mover fondos". El aviso no lo plantea como una posibilidad: "Hemos
confirmado que hubo atacantes que explotaron esta vulnerabilidad. Hubo usuarios afectados y se
robaron fondos".
Qué cambia
Una macaroon no es una contraseña. Es una credencial al portador, y la documentación de LND es
inequívoca sobre lo que eso significa: "Compartir una macaroon permite a cualquiera que la
tenga en su poder usarla para acceder al servicio (en nuestro caso, lnd) y hacer todo lo que
esa macaroon permita"
(macaroons.md). LND
escribe tres de ellas en disco al arrancar. La que se llama admin.macaroon "contiene una
macaroon sin caveats", que es la forma que tiene la documentación de decir que puede hacerlo
todo.
No hay un paso de inicio de sesión que pueda fallar, así que leer el fichero es el ataque entero. Una contraseña habría que probarla contra un servicio capaz de limitar los intentos o de rechazarla. Una macaroon presentada al nodo es válida sin más, porque la validez es una propiedad de los bytes y no de quien los tiene.
Ese mismo documento de LND ya había señalado la exposición: los ficheros de macaroons "están
sin cifrar y, en el caso de admin.macaroon, dan acceso completo al daemon. Esto puede verse
como un riesgo de seguridad bastante grande si el daemon lnd se ejecuta en un entorno que no
es plenamente de confianza". Y va más allá, al llamarlos "los únicos ficheros con información
altamente sensible que no están cifrados", a diferencia del fichero de la cartera y la base de
datos de macaroons, que "siempre están cifrados, incluso si no se usa contraseña". LND incluye
un modo de stateless initialization que no escribe ningún fichero de macaroon, precisamente
por esto. Cada comercio que ejecutaba un
nodo Lightning a través de BTCPay tenía ese fichero en el
mismo servidor que una aplicación web accesible desde internet.
La corrección es igual de contundente. Actualizar a la 2.4.2 lleva además LND a la 0.21.1 y regenera las macaroons, lo que invalida cualquier copia que se hubiera llevado un atacante. La versión 2.4.2 también "elimina temporalmente el acceso público a la API de LND en despliegues con Docker", así que una cartera externa como Zeus ya no puede llegar al nodo a través del dominio de BTCPay ni de su dirección onion. Es una función que funcionaba, apagada a propósito mientras el incidente sigue abierto.
El 10 de agosto el proyecto publicó su respuesta, donde confirma que la vulnerabilidad "permitía a un atacante obtener las credenciales admin macaroon de LND de las instancias afectadas y usarlas para acceder a las carteras LND conectadas". La BTCPay Server Foundation anunció que donará 0,21 BTC a Craig Raw, que reportó el fallo, y otros 0,21 BTC al fondo del Bitcoin Red Team, y que varios colaboradores se han comprometido con una recompensa de recuperación del "10% del importe recuperado, hasta un máximo de 3 BTC por la recuperación total de los fondos".
Qué no cambia
No llegó a las carteras on-chain de BTCPay. El aviso es concreto, y corrige su propia advertencia inicial: tras revisarlo mejor, el proyecto confirmó "que solo LND está afectado" y que "las carteras on-chain de BTCPay Server, incluidas las hot wallets, no están afectadas". La excepción conviene leerla dos veces, porque es fácil confundirla con lo contrario: los fondos que estén en la cartera on-chain del propio LND forman parte del nodo afectado y sí pueden seguir en riesgo.
No alcanza a otras implementaciones de Lightning. Un operador con Core Lightning o Eclair detrás de BTCPay nunca estuvo expuesto a este riesgo concreto de credenciales, y el proyecto lo dice en lugar de anunciar a todo el mundo que fue comprometido.
Actualizar no cierra una puerta que abrió uno mismo. Si el nodo es accesible por un reverse proxy propio, un servicio Tor o un puerto redirigido, "actualizar BTCPay Server no cierra las vías de acceso que uno gestiona por separado", y esas credenciales hay que rotarlas a mano. Rotarlas tampoco deshace el robo: las macaroons nuevas dejan inservibles las copias antiguas, y las monedas que ya se movieron no vuelven.
Y el mecanismo sigue sin ser público. El aviso no dio detalles técnicos "porque los operadores todavía necesitan tiempo para actualizar", y a 25 de agosto de 2026 el blog del proyecto no publica nada más, así que cómo se llegó a esa lectura de ficheros no es algo que este texto pueda contar. Se conoce la forma del resultado, no la del fallo.
Contexto
La lección no es que Lightning sea inseguro. Es qué es un fichero de credenciales una vez que
está en una máquina que además responde a peticiones de desconocidos. Una clave de firma se
trata con ceremonia. Un .macaroon parece configuración, y lleva la misma autoridad.
Por eso el propio consejo del proyecto, en un texto sobre su propio fallo, es el consejo de siempre: "mantener los fondos en cold storage siempre que sea posible. Si hace falta una hot wallet para la operativa diaria, mover con regularidad el exceso de fondos a cold storage". Un nodo de comercio tiene que estar caliente para cobrar, lo que traslada la pregunta a cuánto hay dentro y no a si está expuesto. El coste de la custodia no desaparece porque el software sea bueno: se traslada al saldo.
La divulgación vino de la misma dirección que varias historias de este mes. El endurecimiento del transporte de Stratum V2 y un input de splice que LDK ahora rechaza acreditan a equipos de auditoría con nombre propio, y el Bitcoin Red Team aparece también en este incidente. La diferencia es que aquellos llegaron como parches antes de que nadie perdiera nada, y este no.