Servidor de una tienda con un aviso de seguridad, ilustración del robo en carteras calientes de BTCPay Server
Ilustración propia generada con IA.

BTCPay Server pide apagar los servidores tras el vaciado de carteras calientes en versiones antiguas; el atacante reúne 18,46 BTC

Equipo NodeWitness 10 min de lectura

BTCPay Server, el procesador de pagos de código abierto con el que muchos comercios cobran en bitcoin sin intermediarios, pidió en la noche del domingo 1 de noviembre a todos sus usuarios que apagaran sus servidores tras recibir informes de carteras calientes vaciadas por atacantes [1]. Unas horas después, el equipo acotó el ataque a las instalaciones con la versión 2.4.1 o anteriores [2], mientras la dirección del atacante, que hizo pública el propio fundador del proyecto, Nicolas Dorier, acumulaba 18,46 BTC, cerca de 1,44 millones de $ [14][15].

Un aviso que no dejaba lugar a dudas. «Estamos recibiendo informes de carteras calientes en servidores de BTCPay barridas por atacantes no autorizados. Si tienes una instancia en marcha, apágala (./btcpay-down.sh) hasta que completemos la investigación», publicó el proyecto en X, en un mensaje que superó las 600.000 visualizaciones [1]. Y es que, al tratarse de un programa que cada comercio instala en su propia máquina, no existe un interruptor central con el que cortar el problema de golpe [7].

La precisión llegó ya de madrugada. La investigación había identificado un vector de ataque contra las instancias con la versión 2.4.1, publicada el 23 de julio de 2026, o anteriores, y el equipo aseguró no tener «informes creíbles» de carteras vaciadas en la 2.4.7, la última disponible [2]. Algunos proveedores de alojamiento, de hecho, se adelantaron a sus clientes. BTCPay agradeció a LunaNode y a otros proveedores que apagaran por su cuenta las instancias para que las versiones antiguas no pudieran explotarse [3].

«El atacante logró iniciar sesión como administrador»

Fue Dorier quien puso las primeras piezas sobre la mesa. «Nuestros servidores públicos no fueron atacados (con la 2.4.7), parece que los informes son de versiones anteriores a la 2.4.2. El atacante logró iniciar sesión como administrador en esas instancias y todavía estamos intentando averiguar cómo», escribió el fundador [4]. Más tarde añadió que tenían rastros del uso de vulnerabilidades anteriores a la 2.4.2 y que el proyecto contará el detalle en una entrada de su blog [5][6].

Un acceso de administrador que, en este tipo de instalaciones, basta para llevarse el dinero. La cartera caliente guarda la semilla en el propio servidor, conectado a internet, para que BTCPay pueda firmar pagos de forma automática, una opción que su documentación marca con un aviso de peligro [7]. Quien controla la máquina, en definitiva, controla las monedas.

El episodio llega tres meses después de otro susto. En agosto, BTCPay Server corrigió en la 2.4.2 un fallo crítico, explotado ya por atacantes, que permitía llevarse sin credenciales los ficheros de acceso de los nodos Lightning con LND y vaciarlos [8]. Entonces, el proyecto aseguró que las carteras en cadena, calientes incluidas, quedaban fuera de peligro [8]. Son precisamente esas las que ahora se han vaciado, en servidores que nunca recibieron aquel parche. El propio Dorier lo resumió al responder a un usuario, al que explicó que no parecía tratarse de una vulnerabilidad nueva [17].

La versión más reciente, la 2.4.7, salió el 29 de octubre con 85 hallazgos de seguridad corregidos, uno de ellos crítico, según sus notas [9]. El proyecto, eso sí, no ha dado cifra de pérdidas ni de servidores afectados [10][11].

«No solo la semilla»

Para quien mantenga una tienda, el mensaje del proyecto se resume en comprobar la versión, que aparece al pie de las páginas de administración, y actualizar a la 2.4.7 desde el menú de mantenimiento del servidor o con btcpay-update.sh, manteniendo la máquina apagada mientras tanto si no es posible hacerlo [1][8][12]. A partir de ahí, la respuesta depende de dónde estuviera cada uno.

Para quien ya hubiera pasado por la 2.4.2, Dorier quiso rebajar la alarma. «Al menos para quienes ya actualizaron una vez desde la publicación de la 2.4.2, no hay motivo para el pánico. Por favor, actualizad a menudo. Y no guardéis demasiado en vuestra cartera caliente», escribió [6]. Más tarde fue más allá y aseguró que, tras revisar todos los informes, nadie con una versión superior a la 2.4.2 se había visto afectado [6]. Él mismo, según contó, mantiene su servidor en la 2.4.7 con una cartera caliente [18].

Muy distinto es el caso de quien siguiera en la 2.4.1 o anterior. Preguntado por un usuario sobre si bastaba con cambiar la semilla, la respuesta de Dorier fue tajante. «No solo la semilla, deberían considerar el servidor quemado», contestó [13]. Lo que quede en esa cartera, por tanto, debería acabar en otra nueva cuya semilla nunca haya pasado por esa máquina. A los afectados, el equipo les pide además que envíen todos los detalles y registros a security@btcpayserver.org [2], y en el incidente de agosto ya recomendó denunciar ante las autoridades y avisar a los exchanges o servicios a los que llegue el dinero [12].

En cualquier caso, la lección que repite el proyecto trasciende una versión concreta. «No pongas en la cartera caliente más de lo que estés dispuesto a perder. No podemos garantizar que no vuelva a pasar», advirtió Dorier [17], en la línea de su blog, que aconseja guardar los fondos en frío siempre que se pueda y pasar allí el excedente con regularidad [12]. Una cartera que solo recibe, con la semilla fuera del servidor, puede seguir cobrando sin dar a un intruso nada con lo que firmar [7]. Lo mismo vale para el sistema que hay debajo, que necesita sus parches igual que el programa, como explicamos en la guía sobre el fallo CVE-2026-98432 de Linux.

Lo que cuenta la cadena

La dirección que publicó Dorier, bc1p0f7w…63r7, permite seguir el rastro del dinero [14]. La hemos leído entera en mempool.space, transacción a transacción, con el mismo método que aplicamos a la cartera caliente de Binance [15].

La dirección del atacante recibió 18,46 BTC en 567 transacciones, unos 1,44 millones de $, y 17,9 BTC de lo que sacó seguían sin gastar en nuestra lectura del 2 de noviembre [15].

Esas 567 transacciones de terceros sumaron 18,46 BTC, todos confirmados en nuestra lectura, que al precio de 77.984 $ que marcaba mempool.space equivalen a unos 1,44 millones de $ [15]. Gastaban monedas de 10.471 direcciones distintas, y 499 de ellas tenían una única salida hacia el atacante, el dibujo propio de un barrido que vacía una cartera de una sola vez [15]. La cadena, eso sí, no dice cuántas tiendas hay detrás, ya que una misma cartera puede barrerse más de una vez.

Cantidades modestas, en su mayoría. 459 de las 567 entradas no llegaban a 0,01 BTC, y solo cinco superaron 1 BTC, con 7,74 BTC entre todas ellas, siendo la mayor de 1,86 BTC [15].

Más llamativo resulta el calendario. La primera entrada data del 30 de octubre, más de un día antes del primer aviso público, y hasta el 1 de noviembre la dirección había recibido 0,61 BTC en 20 transacciones [15]. El grueso llegó la tarde de ese domingo, con 8,8 BTC en una sola hora [15]. Cuando BTCPay pidió apagar los servidores ya habían entrado 16,73 BTC, y después siguieron llegando otros 1,73 BTC en 246 transacciones [15]. Barridos pequeños, en definitiva, de servidores que seguían encendidos tras la alerta.

El dinero, quieto

El atacante ha gastado desde esa dirección en 19 ocasiones, casi siempre con el mismo patrón [15]. Junta varias entradas, envía una cantidad redonda o casi redonda a una dirección recién estrenada y devuelve el cambio a la suya. Así ha sacado 18,43 BTC hacia 18 direcciones distintas, entre ellas una que recibió 5,5 BTC y otra con 4,71 BTC [15].

Y ahí siguen. En nuestra lectura, 16 de esas 18 direcciones conservaban intacto lo recibido, 17,9 BTC en total, sin un solo gasto [15]. Las otras dos corresponden a las salidas más antiguas, del 30 de octubre. Una pasó sus 0,36 BTC a otra dirección nueva, que tampoco se ha movido, mientras la otra repartió 0,175 BTC entre una dirección quieta y un envío de 0,02 BTC que acabó en una dirección con actividad desde julio que no hemos podido atribuir [15].

En la propia dirección del atacante quedaban 0,028 BTC [15]. Ninguno de los destinos aparece etiquetado como perteneciente a un exchange en las fuentes públicas consultadas, y Dorier publicó además una dirección del atacante en Litecoin, que queda fuera de esta lectura [16].

Quedan pendientes la entrada técnica del blog, la cifra de pérdidas y el número de tiendas afectadas [6][10]. En la cadena, la incógnita es cuándo empiezan a moverse esas 16 direcciones y hacia dónde. Ocurrió con Electrum y con Keystone, y vuelve a ocurrir con BTCPay. En las herramientas de autocustodia, lo que se deja en manos de un programa conectado es lo primero que conviene vigilar.

Fuentes

Tipo de fuente entre corchetes. Horas en UTC. Consultadas el 2 de noviembre de 2026.

  1. BTCPay Server, mensaje en X, 22:25 UTC del 1 de noviembre de 2026. Petición de apagar las instancias con ./btcpay-down.sh; más de 600.000 visualizaciones en la consulta. (Primaria, proyecto)
  2. BTCPay Server, mensaje en X, 04:07 UTC del 2 de noviembre de 2026. Vector de ataque contra la 2.4.1 (23/07/2026) o anteriores, sin informes creíbles en la 2.4.7, contacto security@btcpayserver.org. (Primaria, proyecto)
  3. BTCPay Server, mensaje en X, 04:07 UTC del 2 de noviembre de 2026. Apagados automáticos de proveedores de alojamiento, agradecimiento a LunaNode. (Primaria, proyecto)
  4. Nicolas Dorier, mensaje en X, 00:28 UTC del 2 de noviembre de 2026. Servidores públicos con la 2.4.7 no atacados, casos anteriores a la 2.4.2, entrada como administrador. (Primaria, fundador del proyecto)
  5. Nicolas Dorier, mensaje en X, 01:52 UTC del 2 de noviembre de 2026. Rastros de vulnerabilidades anteriores a la 2.4.2. (Primaria, fundador del proyecto)
  6. Nicolas Dorier, mensaje en X, 04:10 UTC del 2 de noviembre de 2026, y respuesta, 04:22 UTC. Sin motivo para el pánico si se actualizó al menos una vez desde la 2.4.2; no guardar mucho en la cartera caliente; entrada de blog anunciada. (Primaria, fundador del proyecto)
  7. CoinDesk, BTCPay, a bitcoin payment tool, tells users to switch off their servers after reports of drained wallets, Omkar Godbole, 1 de noviembre de 2026 (hora de Nueva York). Funcionamiento de la cartera caliente y aviso de peligro de la documentación. (Secundaria, prensa)
  8. BTCPay Server, Security Advisory: Update BTCPay Server to 2.4.2 Immediately, 7 de agosto de 2026. Fallo de las credenciales de LND, carteras en cadena no afectadas entonces, comprobación de versión y ruta de actualización. (Primaria, proyecto)
  9. BTCPay Server, notas de la versión 2.4.7, GitHub, 29 de octubre de 2026. 85 hallazgos corregidos, uno crítico. (Primaria, proyecto)
  10. Cointelegraph, BTCPay Server warns of hot wallet thefts running on outdated software, 2 de noviembre de 2026. Sin cifra de afectados ni de pérdidas. (Secundaria, prensa)
  11. BeInCrypto, Is Your BTCPay Server Safe? What the Hot Wallet Drain Investigation Shows, 2 de noviembre de 2026. (Secundaria, prensa)
  12. BTCPay Server, BTCPay Server Security Incident: Our Response and Next Steps, agosto de 2026. btcpay-update.sh, denuncia ante autoridades y exchanges, fondos en frío. (Primaria, proyecto)
  13. Nicolas Dorier, respuesta en X, 04:11 UTC del 2 de noviembre de 2026 («Not only the seed, they should consider the server cooked»). (Primaria, fundador del proyecto)
  14. Nicolas Dorier, mensaje en X con la dirección del atacante, 04:13 UTC del 2 de noviembre de 2026, que enlaza a bc1p0f7w…63r7 en mempool.space. (Primaria, fundador del proyecto)
  15. mempool.space, lectura propia de la dirección del atacante (586 transacciones) y de sus 18 direcciones de destino y siguientes saltos, a las 07:44 UTC del 2 de noviembre de 2026; último movimiento confirmado en el bloque 974.229 (07:35 UTC), primera entrada en el bloque 973.827 (13:35 UTC del 30 de octubre). Precio de 77.984 $ de la API de mempool.space a las 07:40 UTC. (Primaria, cadena)
  16. Nicolas Dorier, mensaje en X con la dirección en Litecoin, 04:44 UTC del 2 de noviembre de 2026. (Primaria, fundador del proyecto)
  17. Nicolas Dorier, respuesta en X, 01:00 UTC del 2 de noviembre de 2026 («In this case, it doesn't seem to be a new vulnerability… Don't put more than you are ready to lose in hot wallet. We can't guarantee it won't happen again»). (Primaria, fundador del proyecto)
  18. Nicolas Dorier, respuesta en X, 03:22 UTC del 2 de noviembre de 2026, sobre su propio servidor con la 2.4.7 y cartera caliente. (Primaria, fundador del proyecto)

Más en Privacidad y autocustodia

Ver los 31 artículos de Privacidad y autocustodia →

Última actualización: 2 de noviembre de 2026