BTCPay Server ha advertido a los comerciantes y a los operadores de sistemas de pago autogestionados que desconecten sus servidores tras conocerse informes de que unos atacantes estaban sustraiendo bitcoins de monederos calientes conectados.
El aviso de emergencia, publicado en la cuenta oficial del proyecto aproximadamente a las 22:25 UTC del 1 de noviembre de 2026, indicó a los operadores que apagaran sus instancias de BTCPay Server mientras los desarrolladores investigaban los compromisos de seguridad denunciados.
El incidente genera preocupación entre los comerciantes que utilizan infraestructura de pagos de Bitcoin autogestionada para evitar a los intermediarios de pago tradicionales. También pone de relieve un desafío de seguridad para el software de código abierto: una solución a una vulnerabilidad solo protege las instalaciones que reciben y aplican la actualización.
Al momento de los primeros informes, los desarrolladores no habían confirmado cuánto Bitcoin fue robado, cuántos comerciantes resultaron afectados ni cómo obtuvieron acceso los atacantes inicialmente.
Los desarrolladores indican a los operadores que desconecten los servidores de BTCPay
El mensaje de emergencia del proyecto informó que atacantes no autorizados estaban vaciando las billeteras calientes conectadas a instalaciones de BTCPay Server.
Se indicó a los operadores que detuvieran sus instancias mediante el comando ./btcpay-down.sh hasta que los investigadores pudieran determinar el alcance y la causa del incidente.
El colaborador principal Uncle Rockstar Developer reforzó la advertencia, describió la situación como urgente e indicó a los operadores con billeteras calientes que apagaran sus servidores.
BTCPay Server es un software de pagos de código abierto que permite a los comerciantes aceptar Bitcoin directamente, sin depender de un procesador de pagos convencional. Las empresas pueden alojar el software por su cuenta y conservar el control de su infraestructura de pagos y de la gestión de sus billeteras.
Este modelo ofrece mayor independencia operativa, pero también responsabiliza al operador del mantenimiento del servidor, las actualizaciones del software y la seguridad de las billeteras.
Nicolas Dorier señala versiones antiguas del software
El fundador de BTCPay Server, Nicolas Dorier, compartió posteriormente hallazgos preliminares que centraron la investigación en instalaciones antiguas.
Según Dorier, las instalaciones afectadas ejecutaban versiones anteriores a la 2.4.2. Al parecer, los atacantes obtuvieron acceso de administrador; los rastros forenses apuntan a vulnerabilidades presentes en esas versiones anteriores.
Dorier también indicó que los servidores públicos y de demostración que ejecutaban la versión 2.4.7 no habían sido atacados.
Esta distinción es importante porque no señala a la versión más reciente como el origen aparente de los compromisos reportados. Sin embargo, esta observación no debe interpretarse como prueba de que todas las instalaciones que ejecutan la versión 2.4.7 sean inmunes a los ataques.
Los investigadores aún no habían publicado una explicación técnica completa, por lo que el punto de entrada exacto y la relación entre los robos reportados y las vulnerabilidades divulgadas previamente seguían sin resolverse.
Una vulnerabilidad anterior de Lightning Network aporta contexto
La investigación también vuelve a llamar la atención sobre otro problema de seguridad de BTCPay Server, divulgado en agosto.
Esa vulnerabilidad permitía a atacantes no autenticados obtener credenciales macaroon de Lightning Network Daemon (LND). Estas credenciales funcionan como tokens de autorización que conceden acceso a operaciones específicas de Lightning Network.
Los desarrolladores corrigieron el problema en la versión 2.4.2. En ese momento, afirmaron que las billeteras propias de BTCPay Server en la cadena no estaban expuestas a través de esa vulnerabilidad en particular.
No se ha determinado si los informes de noviembre sobre el robo de billeteras están relacionados con la misma vulnerabilidad, con otra que afectaba a versiones anteriores o con una combinación de problemas de seguridad.
La distinción es importante. Una vulnerabilidad corregida anteriormente puede ayudar a explicar la exposición en instalaciones desactualizadas, pero no puede considerarse la causa confirmada sin un informe forense publicado.
La versión 2.4.7 corrigió 85 problemas de seguridad días antes del incidente
El momento en que se emitió la advertencia de emergencia ha atraído más atención porque BTCPay Server había publicado una importante actualización de seguridad apenas tres días antes.
El 29 de octubre de 2026, el proyecto publicó la versión 2.4.7 tras recibir informes de vulnerabilidades generados mediante la iniciativa de análisis de seguridad de código abierto de Anthropic.
La actualización abordó 85 hallazgos reportados, desglosados de la siguiente manera:
1 crítica
13 de gravedad alta
52 de gravedad media
19 de gravedad baja
Los hallazgos surgieron en medio de una expansión más amplia de la investigación de vulnerabilidades asistida por IA. En 2026, los sistemas desarrollados por Anthropic, OpenAI y Google demostraron capacidades cada vez más avanzadas para identificar posibles debilidades de software.
La iniciativa de análisis de Anthropic informó de más de 29.000 vulnerabilidades potenciales en seis meses, aunque solo una parte se sometió a revisión manual.
El incidente de BTCPay Server ilustra la diferencia entre encontrar vulnerabilidades y proteger el software que ya está funcionando en producción. Un proyecto puede publicar correcciones, pero los servidores operados de forma independiente no se actualizan automáticamente.
Una instalación que siga usando una versión anterior puede continuar exponiendo a sus usuarios a vulnerabilidades que los desarrolladores ya han corregido.
Los comerciantes desconectan su infraestructura de pagos
La advertencia llevó a empresas, entre ellas Coincards, a desconectar sus instalaciones de BTCPay Server.
Para los comerciantes, la decisión implica una disyuntiva operativa inmediata. Mantener disponible un servidor de pagos permite realizar transacciones con normalidad, pero dejar conectada una billetera caliente potencialmente comprometida podría exponer los fondos a más transferencias no autorizadas.
Dorier también reiteró la importancia de mantener los saldos de las billeteras calientes limitados a cantidades que los operadores puedan permitirse perder.
Las billeteras calientes están conectadas a sistemas en línea y, por lo general, se utilizan para transacciones rutinarias. Su accesibilidad las hace útiles para procesar pagos, pero también significa que requieren controles de seguridad rigurosos y límites para los fondos que contienen.
Por lo tanto, el incidente reportado ha vuelto a centrar la atención en la exposición de las billeteras, los permisos de acceso a los servidores, las prácticas de actualización y la separación de los fondos operativos de las reservas más grandes.
El desafío más amplio de la seguridad en los pagos de criptomonedas autogestionados
El modelo de BTCPay Server ofrece a los comerciantes control directo sobre los pagos con Bitcoin, pero el autoalojamiento no elimina la necesidad de una gestión continua de la seguridad.
Los operadores deben supervisar las versiones del software, aplicar parches, proteger las credenciales de administrador y evaluar los riesgos asociados con las billeteras conectadas. Las actualizaciones tardías pueden dejar los sistemas expuestos incluso después de que los desarrolladores hayan puesto una corrección a disposición.
La investigación de seguridad asistida por IA puede aumentar la velocidad con la que se descubren y se reportan las vulnerabilidades. Esto puede mejorar la seguridad del software con el tiempo, pero también presiona a los responsables del mantenimiento y a los operadores para que revisen los hallazgos, publiquen correcciones e implementen actualizaciones rápidamente.
El desafío es especialmente pertinente para la infraestructura de código abierto utilizada por empresas que quizá no cuenten con equipos de seguridad dedicados. La responsabilidad de aplicar un parche puede recaer en comerciantes individuales o en operadores de servicios.
La investigación continúa mientras las pérdidas siguen sin confirmarse
Las actualizaciones disponibles no incluían una estimación confirmada del Bitcoin robado, un recuento verificado de los comerciantes afectados ni una descripción completa del método del ataque.
Los desarrolladores estaban preparando una explicación más completa, pero en las actualizaciones proporcionadas no se había anunciado ningún parche definitivo específico para el incidente ni una confirmación de que todo estuviera fuera de peligro.
Hasta que los investigadores publiquen más detalles, la relación entre los robos reportados, las versiones antiguas del software y las vulnerabilidades divulgadas previamente sigue siendo preliminar.
Publicado originalmente en CryptosNewss.com