BTCPay Server pide apagar los servidores: vacían billeteras calientes y aún no se sabe cómo

BTCPay Server, el software libre con el que comercios, medios y organizaciones de todo el mundo cobran en bitcoin sin intermediarios, pidió el domingo 1 de noviembre a quienes lo administran que apaguen sus servidores de inmediato. Recibió reportes de billeteras calientes vaciadas en varias instalaciones y, hasta el cierre de esta nota, ni el equipo ni nadie sabe con certeza cómo entraron los atacantes. Revisamos el repositorio oficial del proyecto versión por versión: los datos muestran por qué el problema puede ser menos un fallo nuevo que una cadena de parches que no se aplicaron.

Qué se sabe hasta ahora

• La alerta. Hacia las 17:25 (hora de Bogotá) del domingo, BTCPay Server avisó que había recibido reportes de billeteras calientes vaciadas en varias instancias y pidió ejecutar ./btcpay-down.sh hasta que termine la investigación, según The Defiant y TokenPost.
• Las versiones. Nicolas Dorier, fundador del proyecto, dijo que los robos reportados parecen involucrar versiones anteriores a la 2.4.2 y que los servidores públicos del proyecto, con la 2.4.7, no fueron atacados (TokenPost).
• El método. Según Dorier, el atacante inició sesión como administrador en las instancias afectadas. El equipo todavía no sabe cómo consiguió ese acceso.
• Lo que falta. No hay cifra de pérdidas, ni número de servidores afectados, ni un parche nuevo. Hasta las 21:45 (hora de Bogotá), la última versión publicada seguía siendo la 2.4.7, del 29 de octubre.

Lo que muestran los datos del repositorio

BTCPay Server publica cada versión y su lista de cambios en GitHub. Las revisamos desde la 2.4.0, de junio, para ver qué pasó en el camino. Las fechas son las de cada versión en el repositorio (UTC).

Fuente: lista de cambios (Changelog) del repositorio btcpayserver/btcpayserver en GitHub. Resumen y tabla: Criptoinforme.

Tres datos saltan a la vista:

• Al menos 86 días sin actualizar. Si los servidores robados corren versiones anteriores a la 2.4.2, como dice Dorier, sus administradores no aplicaron un parche que se publicó el 7 de agosto con la advertencia de que la falla “se está explotando activamente” y había que actualizar “tan rápido como puedan”. Del 7 de agosto al 1 de noviembre van 86 días (cálculo de Criptoinforme).
• Seis versiones seguidas con parches de seguridad. Todas las versiones publicadas desde el 7 de agosto, de la 2.4.2 a la 2.4.7, incluyen correcciones de seguridad. Entre la 2.4.6 y la 2.4.7 pasaron solo tres días.
• Los detalles graves no son públicos. En la 2.4.7, el proyecto omitió “intencionalmente” los detalles de los hallazgos críticos y altos. Los atribuye al programa OSS Scanner de Anthropic, que le entregó los reportes con pruebas y correcciones propuestas. Es una práctica normal para dar tiempo a actualizar, pero también significa que nadie fuera del equipo puede saber si alguno de esos fallos sirve para entrar como administrador.

Una hipótesis que nadie ha confirmado

La 2.4.2 no solo cerró la falla de Lightning de agosto. Su lista de cambios incluye otra corrección: “Fix TOTP two-factor authentication bypass via Greenfield Basic authentication”, es decir, una forma de saltarse el código de doble factor usando la autenticación básica de la API Greenfield. Esa misma versión desactivó por defecto la autenticación básica cinco minutos después de crear una cuenta.

Un atacante que entra “como administrador” en servidores que no tienen esa corrección encaja con ese fallo, sobre todo si las contraseñas se filtraron o se reutilizaron en otros sitios. Es una lectura de Criptoinforme, no una conclusión de BTCPay Server: el equipo dijo que todavía no sabe cómo se obtuvo el acceso, y pueden existir otras vías.

Por qué se vacían las billeteras calientes y no las frías

BTCPay ofrece dos formas de recibir bitcoin:

• Billetera caliente. La frase semilla (las claves que permiten gastar) se guarda en el propio servidor. Es cómoda para hacer reembolsos y pagos automáticos, pero quien controla el servidor como administrador puede mover esos fondos.
• Billetera fría o de solo lectura. El servidor solo conoce la clave pública extendida (xpub): puede generar direcciones y ver pagos, pero no gastar. Las claves quedan en una billetera física o en otro dispositivo.

Por eso el robo apunta a las billeteras calientes. Pero ojo: un administrador malicioso también puede cambiar la configuración de una tienda, por ejemplo la xpub o las direcciones de destino, para que los próximos cobros lleguen a una billetera ajena. Si tu servidor estuvo expuesto, que no te hayan vaciado nada no significa que todo esté bien.

Qué hacer si cobras con BTCPay Server

1. Apaga el servidor ahora con ./btcpay-down.sh, como pide el proyecto. Si te lo administra un tercero (un proveedor de alojamiento o tu agencia), escríbele hoy mismo.
2. Saca los fondos de la billetera caliente desde otro lugar. Con la frase semilla, recupera la billetera en otra aplicación confiable y mueve el saldo a una billetera nueva, con una semilla nueva. Si el servidor fue comprometido, da por expuesta la semilla anterior.
3. No lo vuelvas a encender sin actualizar. Espera la indicación del equipo y pasa a la versión más reciente (hoy, la 2.4.7 o la que publiquen).
4. Revisa todo lo que un administrador puede tocar: usuarios con rol de administrador que no reconozcas, claves API, webhooks, procesadores de pagos automáticos, pagos pendientes, la xpub de cada tienda, la configuración de correo y los complementos instalados.
5. Cambia contraseñas y activa el doble factor en todas las cuentas. Si usas Lightning con LND, asegúrate de que el macarrón (la credencial de administrador del nodo) se regeneró con la 2.4.2 o posterior.
6. Si te robaron, repórtalo a security@btcpayserver.org con las direcciones y transacciones, a las autoridades locales y a los exchanges donde se vea llegar el dinero.

No es la primera vez este año

En agosto, una falla crítica permitió a atacantes sin credenciales obtener los archivos “macaroon” de nodos Lightning conectados a BTCPay y vaciarlos. Entre los afectados estuvieron el fabricante de billeteras Foundation y la publicación Citadel21, según CoinDesk. En ese caso las billeteras on-chain generadas en BTCPay no estaban expuestas. El proyecto ofreció entonces una recompensa del 10% de lo recuperado, con un tope de 3 BTC, y anunció que la seguridad tendría prioridad sobre las funciones nuevas “en el futuro previsible”.

El patrón de 2026 es claro: los investigadores, cada vez más ayudados por herramientas de inteligencia artificial, encuentran fallos más rápido que nunca, y los proyectos los corrigen en días. El eslabón débil es el último: el comercio que instaló su servidor una vez y no volvió a actualizarlo. Con un software que cada quien aloja por su cuenta, nadie más lo hace por ti.

Nota en desarrollo. La actualizaremos cuando BTCPay Server publique la causa del ataque o una nueva versión.

Fuentes: alerta de BTCPay Server del 1 de noviembre (vía The Defiant, TokenPost y PANews); declaraciones de Nicolas Dorier (TokenPost); lista de cambios del repositorio btcpayserver/btcpayserver en GitHub; blog de BTCPay Server (10 de agosto); CoinDesk (8 de agosto). Tabla, conteos y cálculo de días: Criptoinforme.