Robos de hot wallets en BTCPay Server, corregidos en 2.4.2

TL;DR

• Atacantes robaron bitcoin y litecoin de las hot wallets de servidores con BTCPay Server 2.4.1 o anterior, mediante la vulnerabilidad corregida en 2.4.2 el 7 de agosto de 2026. El proveedor reveló los robos el 2 de noviembre de 2026.
• Toda versión anterior a 2.4.2, incluidas las release candidates de 2.4.2, está afectada. Los ataques de agosto tomaron el control de nodos LND de Lightning Network; los robos de noviembre vaciaron las hot wallets on-chain de los servidores.
• El proveedor califica la falla de crítica e informa de robos de fondos en agosto y el 1 de noviembre de 2026. No hay CVE asignado y la falla no figura en el catálogo KEV de CISA al 3 de noviembre de 2026.
• Si usa 2.4.1 o anterior, traslade el servicio a un servidor nuevo con una cartera nueva después de barrer sus fondos. Actualizar sin más no elimina un acceso que un atacante ya haya obtenido. Vea «¿Cómo corregirlo?».

¿Está afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• Su despliegue usa BTCPay Server 2.4.1, publicada el 23 de julio de 2026, o cualquier versión anterior. El aviso del proveedor indica que la falla está presente en toda versión anterior a 2.4.2, incluidas las release candidates de 2.4.2.
• La instancia era accesible desde Internet mientras usaba una versión afectada. El proveedor dice no haber establecido cuándo empezaron los atacantes a explotar la falla.
• No ha reconstruido el servidor desde entonces. La guía de recuperación del proveedor aplica incluso si actualizó desde una versión afectada tras su aviso del 1 de noviembre y no notó robo.

Las instancias alojadas también están en el alcance: el 1 de noviembre el proveedor pidió a los proveedores de hosting, incluida LunaNode, que apagaran las instancias de BTCPay Server como precaución. Contacte a su proveedor para trasladarse a una máquina virtual nueva.

Los fondos cuyas claves de gasto se mantienen fuera del servidor, incluidas las carteras de hardware, no resultaron afectados por estos robos. Aceptar pagos hacia tales carteras sigue siendo la práctica recomendada por el proveedor.

Las versiones afectadas se pierden todas las correcciones de seguridad posteriores: las versiones 2.4.3 a 2.4.7 entregaron cambios de seguridad y endurecimiento hasta el 29 de octubre de 2026. Solo la versión 2.4.7 corrige 85 hallazgos de seguridad reportados mediante el OSS Scanner de Anthropic.

Pese a sus 7,888 estrellas en GitHub y 4,131,130 descargas de la imagen Docker oficial, no existe ningún CVE ni aviso de seguridad de GitHub para esta falla, así que los escáneres de versiones no pueden señalar el rango afectado.

Compruebe qué usa:

# Vendor's check: log in and read the version shown at the bottom of the page.

# Docker deployments: list the running container and its image tag
docker ps --format 'table {{.Names}}\t{{.Image}}' | grep -i btcpay
# If the tag reads "latest" or gives no version, the page footer is authoritative.

¿Cómo corregirlo?

1. Si usa 2.4.1 o anterior, siga los pasos de recuperación del proveedor en lugar de una actualización en el mismo sitio:
2. Cree una cartera nueva y barra en ella los fondos restantes de la hot wallet. Use un dispositivo de confianza y una semilla nueva; reutilizar la semilla antigua en un servidor nuevo deja esos fondos en riesgo.
3. Apague el servidor antiguo y conserve los registros y comprobantes de transacción relevantes para la investigación antes de reemplazarlo.
4. Aprovisione una máquina virtual nueva, instale la última versión soportada desde fuentes de confianza y conecte la cartera nueva. No restaure todo el servidor antiguo en la máquina nueva.
5. Desde un dispositivo de confianza, revoque y reemplace cada credencial a la que el servidor antiguo pudiera llegar. No introduzca credenciales nuevas en la máquina antigua. El proveedor cita:
   • credenciales de hosting y SSH
   • credenciales de aplicación y de API
   • credenciales Lightning
6. Si su servidor ya usaba 2.4.2 o posterior el 1 de noviembre, el proveedor no ha visto impacto de estos ataques en esos servidores. Actualice igualmente a la versión actual, porque 2.4.7 corrige 85 hallazgos de seguridad adicionales.
7. En una instalación estándar, use la ruta de actualización del proveedor (Server Settings, luego Maintenance, luego Update) y confirme que el pie de página muestra la nueva versión.
8. Los integradores deben actualizar también NBXplorer a 2.6.10, como recomiendan las notas de la versión 2.4.2.

No existe una solución de contorno de configuración para la falla en sí. En agosto, el consejo provisional del proveedor para usuarios de LND que no podían actualizar era apagar el servidor. Un despliegue LND afectado nunca debe quedar accesible desde Internet.

¿Cuál es la causa raíz?

BTCPay Server cerró dos exposiciones el mismo día: métodos auxiliares públicos de controladores eran enrutables como endpoints HTTP, y el despliegue Docker de referencia exponía las API de LND a través del dominio público. El proveedor declara que aún no publica los detalles técnicos, para dar tiempo a los operadores a actualizar.

La corrección del lado del servidor es el commit 6689cad419, «Disabled unwanted routes», enviado el 7 de agosto de 2026 por el mantenedor Nicolas Dorier sin pull request ni entrada en el registro de cambios. Añade el atributo [NonAction] a cinco métodos auxiliares públicos de controladores, incluido este:

// BTCPayServer/Controllers/UILNURLController.cs, before 2.4.2
public async Task<IActionResult> GetLNURLRequest(
    string cryptoCode,
    Data.StoreData store,
    ...)

// after 2.4.2
[NonAction]
public async Task<IActionResult> GetLNURLRequest(
    string cryptoCode,
    Data.StoreData store,
    ...)

ASP.NET Core mapea cada método público de una clase controladora a un endpoint HTTP enrutable, salvo que el método lleve [NonAction]. Los cinco métodos auxiliares están en los controladores LNURL, LNURL-authentication, stores, email-rule y subscription. Cada uno es un bloque interno que nunca debió recibir una petición.

El mismo día, el commit «Do not expose LND anymore» del repositorio docker eliminó las dos ubicaciones nginx que conectaban el dominio público directamente con el nodo Lightning:

# Production/nginx.tmpl in btcpayserver-docker, removed on 2026-08-07
location ~* ^/(lnrpc|routerrpc|verrpc|walletrpc)\. {
    grpc_read_timeout 6000s;
    grpc_send_timeout 6000s;
    grpc_pass grpcs://lnd_bitcoin:10009;
}
location /lnd-rest/btc/ {
    rewrite ^/lnd-rest/btc/(.*) /$1 break;
    proxy_pass http://lnd_bitcoin:8080/;
}

Un tercer commit el mismo día nombra la clase de la falla. Al revertir una eliminación relacionada, el mantenedor Andrew Camilleri escribió que CLN, otra implementación de Lightning Network, «is not affected by the LNURL issue». BTCPay llega a CLN por un socket Unix con runes, así que «there is no macaroon for that code path to read», en sus palabras. Su mensaje afirma que la ruta de código LNURL lee el macaroon de LND.

El aviso de agosto describe el resultado: un atacante remoto sin autenticar podía obtener los archivos de credenciales .macaroon de LND.

¿Cómo se explota?

Las dos publicaciones del proveedor describen la ruta de ataque; no existe una prueba de concepto pública y el proveedor no ha publicado las peticiones que enviaron los atacantes:

1. El atacante alcanza un servidor afectado por Internet. El aviso de agosto afirma que obtener los archivos de credenciales .macaroon no requería autenticación.
2. En los ataques de agosto, el atacante obtuvo los archivos .macaroon, que otorgan acceso autenticado a un nodo LND. El proveedor revisó ataques que solo apuntaban a archivos con la extensión .macaroon, y afirma que esas credenciales permitían tomar el control del nodo y mover fondos.
3. En los ataques de noviembre, el atacante usó «a different method to exploit the vulnerability fixed in 2.4.2», en palabras del proveedor. Los robos tomaron bitcoin y litecoin de las hot wallets on-chain de los servidores, y el proveedor no ha descrito ese método.
4. No hizo falta acceso adicional para gastar los fondos, porque una hot wallet guarda en el propio servidor las claves necesarias para gastarlos. Las carteras cuyas claves de gasto están fuera del servidor no resultaron afectadas.

¿Cómo fluye el ataque?

Una petición sin autenticar alcanza rutas que el proveedor nunca pensó exponer, y el atacante toma las credenciales macaroon de LND o, en noviembre, los fondos de las hot wallets on-chain.

¿Qué puede hacer un atacante?

Los ataques de agosto tomaron el control de un nodo LND y movieron sus fondos, incluida la cartera on-chain que pertenece al propio nodo. Los ataques de noviembre robaron bitcoin y litecoin de las hot wallets on-chain de los servidores, que el proveedor había considerado no afectadas al revisar los ataques de agosto.

Una vez dentro, al atacante se le considera dueño de la máquina. El proveedor dice a quien tenga fondos robados o señales de acceso no autorizado que considere comprometidos el servidor entero y todos sus secretos. Se aplican los mismos pasos de recuperación.

Dos condiciones limitan el impacto. El servidor debe usar 2.4.1 o anterior. Solo los fondos que el propio servidor podía gastar estaban en riesgo, así que las carteras de hardware y otras claves guardadas en otro lugar quedaron fuera de alcance.

¿Por qué funciona la corrección?

La versión 2.4.2 cierra ambas exposiciones. Los atributos [NonAction] sacan del enrutamiento los cinco métodos auxiliares, así que ya no pueden recibir peticiones. El cambio de nginx saca las interfaces gRPC y REST de LND del dominio público.

El costo documentado es que las carteras externas como Zeus pierden acceso a LND a través del dominio de BTCPay. El proveedor planea restaurar esa ruta cuando sea seguro.

Dos cambios del mismo día invalidan lo ya robado. El repositorio docker sube LND a 0.21.1, y el ajuste LND_MACAROON_ROTATION_ID añadido el 7 de agosto regenera los macaroons. Los archivos macaroon tomados antes de la actualización dejan de funcionar.

La corrección es completa para las dos exposiciones que cierran los commits, pero no puede eliminar un acceso que el atacante ya hubiera obtenido. Por eso el proveedor pide a los operadores de versiones afectadas trasladarse a un servidor nuevo en lugar de actualizar en el mismo sitio.

La versión 2.4.2 también corrige una evasión de la autenticación de dos factores TOTP disponible mediante la autenticación Basic de Greenfield. Desactiva la autenticación Basic por defecto cinco minutos después de crear la cuenta.

¿Cómo sé si fui comprometido?

Compruebe primero la versión: inicie sesión y lea el pie de página. Luego revise la blockchain y su nodo Lightning:

• El proveedor publicó dos direcciones de destino identificadas en los reportes del incidente. Busque transferencias salientes a la dirección bitcoin bc1p0f7wmcnesrapznymf9ljdn04pudgmh96sqtrm9vmgqxdh666fh8qvn63r7 o a la dirección litecoin ltc1qp49tmfdueyaqrmgrx0uyx4uegyygt8yt02whee.
• Trate una coincidencia como una pista entre otras. El proveedor advierte que parte de la actividad en estas direcciones parece anterior a los robos descritos en sus reportes, por lo que sus saldos e historiales no son un total de pérdidas confirmado.
• Si usa o usó LND, aplique las cuatro comprobaciones del aviso de agosto del proveedor:
• pagos que usted no hizo
• cierres de canales inesperados o pares desconocidos
• saldos on-chain y de canales comparados con sus propios registros
• cualquier actividad que no reconozca
• Un saldo de cartera sin cambios no descarta un ataque anterior. Si el servidor usaba 2.4.1 o anterior y era accesible, considere comprometidas la máquina y todos sus secretos. Conserve los registros y siga los pasos de «¿Cómo corregirlo?».

Cronología

• 2026-07-23: se publica BTCPay Server 2.4.1, la última versión que lleva la falla.
• 2026-08-06 a 2026-08-07: los mantenedores envían la corrección compuesta en los repositorios servidor y docker: «Disabled unwanted routes», «Do not expose LND anymore» y la rotación de macaroons.
• 2026-08-07: se publica BTCPay Server 2.4.2. El aviso afirma que atacantes ya habían explotado la falla y que se robaron fondos.
• 2026-08-24: 2.4.3 se publica como versión de seguridad para servidores compartidos por muchos usuarios.
• 2026-09-07: 2.4.4 entrega cambios de endurecimiento del pago y de las tiendas.
• 2026-10-06: 2.4.5 bloquea por defecto los destinos en red privada para las peticiones salientes.
• 2026-10-26: 2.4.6 endurece permisos de API, entrada no confiable, enlaces generados y acciones del navegador.
• 2026-10-29: 2.4.7 corrige 85 hallazgos de seguridad reportados mediante el OSS Scanner de Anthropic.
• 2026-11-01: un vaciado de cartera descrito en los reportes del incidente ocurre a las 13:46 UTC. El primer reporte de robo llega por correo a las 20:56 UTC, y el proveedor avisa a la comunidad a las 22:25 UTC.
• 2026-11-02: el proveedor nombra a 2.4.1 y anteriores como versiones afectadas y publica la guía de recuperación.

FAQ

No uso LND. ¿Sigo en riesgo?

Los ataques de agosto que revisó el proveedor solo apuntaban a archivos macaroon de LND, y los usuarios de otras implementaciones de Lightning Network no estaban expuestos a ese riesgo de credenciales. Los robos de noviembre tomaron bitcoin y litecoin de hot wallets on-chain en servidores con 2.4.1 o anterior. La guía de recuperación ahora aplica a todo despliegue afectado, no solo a usuarios de LND.

Actualicé a 2.4.2 o posterior tras el aviso del 1 de noviembre. ¿Estoy a salvo?

El proveedor no ha visto impacto en servidores que ya usaban 2.4.2 o posterior cuando se emitió el aviso. Si actualizó desde 2.4.1 o anterior después de ese aviso, el proveedor igualmente pide trasladarse a un servidor nuevo con una cartera nueva. Actualizar no elimina un acceso que un atacante ya haya obtenido.

¿Hay un CVE que pueda escanear?

No. Al 3 de noviembre de 2026 no se ha asignado ningún CVE y el repositorio de GitHub no contiene ningún aviso de seguridad, así que los escáneres de dependencias no pueden señalar el rango afectado. La versión mostrada al pie de página es la única comprobación de versión, y los pasos de «¿Cómo corregirlo?» son la remediación.

¿Están seguros mis fondos en cartera de hardware?

Sí. Los fondos en carteras cuyas claves de gasto se mantienen fuera del servidor, incluidas las carteras de hardware, no resultaron afectados por estos robos. El proveedor sigue recomendando reconstruir un servidor antiguo aunque guarde las claves de su cartera en otro lugar, porque el atacante puede conservar otro acceso a la máquina.

¿Qué cambió en las versiones posteriores a 2.4.2?

Son versiones de seguridad y endurecimiento. La versión 2.4.5 bloquea por defecto los destinos en red privada para conexiones Lightning, peticiones LNURL, URL de notificación de facturas y webhooks. La versión 2.4.7 corrige 85 hallazgos de seguridad reportados mediante el OSS Scanner de Anthropic: uno crítico, 13 altos, 52 medios y 19 bajos.

Encuentre servidores de pago expuestos con Ostorlab

El descubrimiento de la superficie de ataque de Ostorlab inventaría sus hosts expuestos a Internet y los servicios que ofrecen. Úselo para listar qué servidores ejecutan un procesador de pagos autohospedado y compruebe primero esas versiones.

Referencias

• Blog de BTCPay Server, «Security Incident Affecting BTCPay Server 2.4.1 and Earlier», 2 de noviembre de 2026, los reportes de robo, los pasos de recuperación, la cronología y las direcciones de destino: https://blog.btcpayserver.org/btcpay-server-security-incident-2-4-1-and-earlier/ (verificado el 3 de noviembre de 2026)
• Blog de BTCPay Server, «Security Advisory: Update BTCPay Server to 2.4.2 Immediately», 7 de agosto de 2026, el robo no autenticado de .macaroon, el alcance de LND, los créditos y el consejo provisional: https://blog.btcpayserver.org/security-advisory-btcpay-server-2-4-2/ (verificado el 3 de noviembre de 2026)
• Commit btcpayserver 6689cad41979c73f769fd42e38268fed1fa800fa, «Disabled unwanted routes», Nicolas Dorier, 7 de agosto de 2026, las cinco adiciones de [NonAction]: https://github.com/btcpayserver/btcpayserver/commit/6689cad41979c73f769fd42e38268fed1fa800fa (verificado el 3 de noviembre de 2026)
• Commit btcpayserver-docker 21ea2e122ae5bc453ad1c0a4d6d6b6dd094dcca2, «Do not expose LND anymore», Nicolas Dorier, 7 de agosto de 2026, las ubicaciones nginx eliminadas: https://github.com/btcpayserver/btcpayserver-docker/commit/21ea2e122ae5bc453ad1c0a4d6d6b6dd094dcca2 (verificado el 3 de noviembre de 2026)
• Commit btcpayserver-docker c48919f9ae51c714078076e7912dd153ba0bb01f, «Revert 'Do not expose CLN REST anymore'», Andrew Camilleri, 7 de agosto de 2026, la descripción de la clase «LNURL issue» y la ruta de código del macaroon: https://github.com/btcpayserver/btcpayserver-docker/commit/c48919f9ae51c714078076e7912dd153ba0bb01f (verificado el 3 de noviembre de 2026)
• Commit btcpayserver-docker 4caadeb0c3a31f88ca1a4ee46fd63d8b9db093c0, «Triggering macaroon regeneration», rockstardev, 7 de agosto de 2026, el ajuste LND_MACAROON_ROTATION_ID: https://github.com/btcpayserver/btcpayserver-docker/commit/4caadeb0c3a31f88ca1a4ee46fd63d8b9db093c0 (verificado el 3 de noviembre de 2026)
• Notas de la versión v2.4.2 de BTCPay Server, 7 de agosto de 2026, la declaración de explotación, los créditos, la corrección de la evasión TOTP y la recomendación de NBXplorer 2.6.10: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.2 (verificado el 3 de noviembre de 2026)
• Notas de la versión v2.4.7 de BTCPay Server, 29 de octubre de 2026, los 85 hallazgos de seguridad por severidad del OSS Scanner de Anthropic: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.7 (verificado el 3 de noviembre de 2026)
• Publicación de BTCPay Server v2.4.1, 23 de julio de 2026: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.1 (verificado el 3 de noviembre de 2026)
• Notas de la versión v2.4.5 de BTCPay Server, 6 de octubre de 2026, el bloqueo por defecto de destinos en red privada: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.5 (verificado el 3 de noviembre de 2026)
• Repositorio btcpayserver/btcpayserver, 7,888 estrellas, y su imagen de Docker Hub, 4,131,130 descargas, las cifras de alcance: https://github.com/btcpayserver/btcpayserver y https://hub.docker.com/r/btcpayserver/btcpayserver (verificado el 3 de noviembre de 2026)
• The Hacker News, «Hackers Exploit BTCPay Server Flaw to Steal Bitcoin and Litecoin From Hot Wallets», 3 de noviembre de 2026, la nota de acceso de Zeus y los apagados de proveedores de hosting: https://thehackernews.com/2026/11/hackers-exploit-btcpay-server-flaw-to.html (verificado el 3 de noviembre de 2026)
• Fuente JSON del catálogo KEV de CISA, verificada para entradas de BTCPay Server el 3 de noviembre de 2026 (ninguna): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (verificado el 3 de noviembre de 2026)