El atacante inició sesión como administrador en servidores BTCPay desactualizados antes de los vaciamientos de hot wallets, según el fundador
Puntos clave
- •Los vaciamientos de hot wallets del domingo apuntaron a instancias de BTCPay Server que ejecutaban la versión 2.4.1, lanzada el 23 de julio, o anteriores, según la actualización de la investigación del proyecto.
- •BTCPay emitió una alerta instando a todos los operadores a apagar sus instancias y reportó ningún vaciamiento creíble de hot wallets entre usuarios de la versión 2.4.7, lanzada el 29 de octubre.
- •En las intrusiones reportadas, los atacantes iniciaron sesión como administradores, y BTCPay aún no ha determinado cómo se obtuvo ese acceso.
- •La versión 2.4.2, lanzada el 7 de agosto, corrigió una falla explotada activamente que permitía a atacantes no autenticados robar credenciales macaroon de LND y apoderarse de nodos de Lightning, pero BTCPay no ha confirmado si ese error se usó el domingo, señalando que el error de agosto no requería autenticación mientras que los ataques del domingo involucraron inicios de sesión de administrador.
- •Dorier dijo que los operadores que hayan actualizado al menos una vez desde el lanzamiento de la 2.4.2 no tienen motivos para alarmarse, al tiempo que advirtió a los usuarios no mantener demasiado en una hot wallet.

Los barridos de hot wallets reportados el domingo parecen haber apuntado a instancias de BTCPay Server que ejecutaban versiones anteriores a la 2.4.2, según Nicolas Dorier, fundador de BTCPay Server. En esos casos, el atacante inició sesión como administrador, y el equipo dijo que aún trabaja para determinar cómo se obtuvo ese acceso.
La investigación apunta a la 2.4.1 o versiones anteriores
BTCPay emitió una alerta a las 5:25 p.m. ET del domingo, publicada en X, instando a cualquiera que ejecutara una instancia a apagarla con ./btcpay-down.sh hasta que terminara la investigación. Dorier hizo un seguimiento unas dos horas después, señalando que los servidores públicos de BTCPay, que ejecutan la versión 2.4.7, no habían sido atacados. Más tarde dijo que el equipo tenía rastros que indicaban que "se usaron vulnerabilidades anteriores a la 2.4.2".
Una actualización publicada por BTCPay a las 11:07 p.m. ET (aquí y aquí) acotó el objetivo: los investigadores identificaron un vector de ataque dirigido a instancias que ejecutaban la versión 2.4.1, lanzada el 23 de julio, o versiones anteriores.
El proyecto reportó "ningún reporte creíble de vaciamientos de hot wallets" por parte de usuarios de la 2.4.7, que se lanzó el 29 de octubre. Instó a los operadores a mantener el software actualizado y pidió a las víctimas que enviaran detalles y registros a su equipo de seguridad.
Algunos proveedores de hosting pudieron haber apagado instancias automáticamente para evitar que se explotaran versiones antiguas. BTCPay agradeció a LunaNode y otros por su pronta acción. Dorier dijo que los operadores que hayan actualizado al menos una vez desde el lanzamiento de la 2.4.2 no tienen "motivos para alarmarse", al tiempo que advirtió a los usuarios no mantener demasiado en una hot wallet y prometió una publicación de blog con más detalles.
Los vaciamientos del domingo alcanzaron fondos que el aviso de agosto consideraba seguros
Como BTCPay es autohospedado, el proyecto no puede modificar ni apagar el servidor de un comercio. Su modo de hot wallet firma los pagos con una semilla almacenada en ese servidor, lo que significa que quien controle el servidor puede mover las monedas, según la documentación de BTCPay. En la práctica, una versión de seguridad como la 2.4.2 protege un servidor determinado solo cuando su operador la instala.
La versión 2.4.2 data de agosto. BTCPay lanzó la 2.4.2 el 7 de agosto para corregir una vulnerabilidad crítica que ya estaba bajo ataque activo, como reportó Cryptopolitan en su momento. Todas las versiones anteriores, incluidas las versiones candidatas de la 2.4.2, permitían que un atacante no autenticado robara las credenciales macaroon de LND, lo que le permitía apoderarse de un nodo de Lightning y mover sus fondos. El proyecto detalló el parche en su aviso de seguridad. Foundation y Citadel21 reportaron ataques a sus nodos de Lightning, y Craig Raw, desarrollador de Sparrow Wallet, dijo que también fue afectado.
Con el lanzamiento de la 2.4.2, los macaroons de LND se regeneraron automáticamente. Los operadores que exponían LND a través de su propio proxy, servicio Tor o un puerto redirigido aún debían cambiar esas credenciales manualmente. La versión 2.4.2 también corrigió una vulnerabilidad independiente de omisión de la autenticación de dos factores TOTP a través de la autenticación Basic de la API Greenfield, reportada el 4 de agosto. BTCPay dijo que ese error no estaba relacionado con el hackeo de macaroons y que sus propias wallets on-chain, incluidas las hot wallets, no se vieron afectadas por esa falla.
Ni BTCPay ni Dorier han dicho si el atacante del domingo explotó el error de macaroon de agosto u otra vulnerabilidad anterior a la 2.4.2. El error de macaroon de agosto era explotable sin ninguna autenticación; las intrusiones del domingo, en cambio, involucraron inicios de sesión de administrador. En agosto, los patrocinadores ofrecieron una recompensa de recuperación del 10% de los fondos devueltos, hasta 3 BTC, como reportó Cryptopolitan. Por separado, River reportó que el uso promedio de Bitcoin por comercios creció 74% en 2025, con el volumen de Lightning superando los 1.000 millones de dólares mensuales, el tipo de actividad de pagos comerciales que software autohospedado como BTCPay está diseñado para procesar.