Robos en billeteras de BTCPay Server: qué pasó y qué versiones están en riesgo

Información actualizada el 2 de noviembre de 2026. Este artículo sigue el comunicado completo de BTCPay Server, que reemplaza su alerta inicial de apagado por precaución.

BTCPay Server confirmó reportes de robos de Bitcoin y Litecoin desde billeteras calientes en instalaciones desactualizadas. Su comunicado de seguridad de noviembre identifica como objetivo las versiones 2.4.1 y anteriores.

La distinción importa: no se trató de una falla en las reglas de consenso de Bitcoin, ni el comunicado afirma que todas las billeteras de BTCPay hayan sido vaciadas. Los robos reportados involucraron billeteras cuyas claves de gasto estaban almacenadas en los servidores afectados.

Otro método de ataque contra una vulnerabilidad ya corregida

Según BTCPay, los atacantes utilizaron un método diferente para explotar una vulnerabilidad corregida en la versión 2.4.2, publicada el 7 de agosto de 2026. Una nueva oleada de robos no implica necesariamente una vulnerabilidad nueva y desconocida.

El aviso de agosto se centraba en credenciales expuestas de LND y el riesgo para nodos Lightning. Su afirmación de que las billeteras calientes on-chain del propio BTCPay no estaban afectadas describía los ataques examinados entonces. No debe utilizarse como garantía frente a los robos de noviembre.

La versión estable más reciente comprobada para este artículo es la 2.4.7, publicada el 29 de octubre, antes de la alerta de noviembre. BTCPay dice que no ha observado impacto de estos ataques en servidores que ya ejecutaban la versión 2.4.2 o posterior cuando emitió la advertencia. Es una observación sobre este incidente, no una promesa de que alguna versión sea invulnerable.

Importa dónde están tus claves

La guía de usuario de BTCPay distingue tres formas de conectar una billetera:

• Una billetera existente puede proporcionar información pública de recepción y mantener sus claves privadas en otro lugar.
• Una billetera de solo observación puede registrar los pagos entrantes sin conservar la clave privada en el servidor.
• Una billetera caliente guarda la clave privada en el servidor para gastar directamente desde la interfaz de BTCPay.

La última opción resulta práctica. También coloca la capacidad de gastar en una máquina expuesta a internet. BTCPay informa que los fondos cuyas claves de gasto estaban fuera del servidor, incluidas las billeteras de hardware, no se vieron afectados por estos robos. Eso no significa que se pueda ignorar un servidor de pagos comprometido: todavía hace falta investigar la configuración de cobro, las credenciales y la información que se muestra a los clientes.

Actualizar puede no bastar después de una intrusión

Para un servidor que ejecutaba la versión 2.4.1 o anterior, el aviso actual recomienda un servidor nuevo y una billetera nueva, aunque el saldo parezca intacto o se haya actualizado después de la advertencia del 1 de noviembre. Una actualización puede cerrar la vulnerabilidad sin eliminar el acceso que un intruso ya obtuvo.

Si hubo robo de fondos o señales de acceso no autorizado, considera comprometida toda la máquina y sus secretos y sigue el mismo proceso de recuperación, aunque ya hayas actualizado el software. Revoca y reemplaza las credenciales potencialmente expuestas desde un dispositivo confiable. Nunca introduzcas credenciales nuevas en el servidor antiguo.

Los operadores deben seguir las instrucciones completas de recuperación del proyecto. Una lista en un blog no sustituye la respuesta a un incidente. El procedimiento busca proteger los fondos restantes con una semilla nueva creada en un dispositivo confiable, conservar evidencia, aislar la máquina antigua, reconstruir con software de fuentes confiables y reemplazar las credenciales expuestas. Reutilizar la semilla anterior o restaurar toda la máquina comprometida anula ese propósito.

Los operadores de Lightning necesitan precauciones adicionales. La documentación de Lightning de BTCPay explica que un nodo tiene fondos on-chain y fondos en canales fuera de la cadena. Un respaldo de la semilla por sí solo no recupera el estado de los canales. No borres un nodo ni improvises una migración sin revisar los requisitos de recuperación de la implementación de Lightning que utilizas.

Lo que todavía no se sabe

BTCPay no ha establecido cuándo comenzó la explotación ni una cifra total confirmada de pérdidas. Advierte expresamente que los saldos y los historiales de las direcciones de destino reportadas no deben interpretarse como el monto robado en este incidente. No publicamos una cifra especulativa.

Los operadores afectados pueden escribir a security@btcpayserver.org con su historial de versiones, la hora del incidente y datos públicos de las transacciones. Nunca envíes una semilla de recuperación, una clave privada, una contraseña ni un token de acceso. Elimina los secretos de los registros antes de compartirlos.

Una lección práctica para los comercios en Panamá

En una tienda, fundación o negocio en línea que acepta Bitcoin, alguien tiene que hacerse cargo del mantenimiento. Conviene definir quién revisa las actualizaciones de seguridad, quién puede suspender el sistema de cobro y cómo se verificarán los pagos durante un incidente. Un servidor instalado una vez y olvidado sigue siendo una responsabilidad operativa.

Separa la infraestructura de cobro del ahorro a largo plazo cuando sea posible. Define cuánto necesita realmente el negocio en una billetera caliente y prueba la firma y la recuperación con montos pequeños antes de depender del sistema para ingresos importantes. La autocustodia da control al operador; también le deja la responsabilidad por las consecuencias de ese control.

El comunicado citado no presenta evidencia de que Panama Bitcoin o algún comercio panameño en particular se haya visto afectado. Esta es una advertencia para revisar la instalación, no una afirmación de pérdidas locales.

Consulta el aviso oficial de BTCPay para seguir la investigación y suscríbete a Panama Bitcoin para recibir noticias y educación práctica sobre Bitcoin.