Vulnerabilidad crítica en BTCPay Server bajo ataque activo: actualiza ahora y rota las credenciales

Actualizado el 8 ago 2026

Vulnerabilidad crítica en BTCPay Server bajo ataque activo: actualiza ahora y rota las credenciales

Se está instando a los administradores de BTCPay Server a tomar medidas inmediatas después de que el procesador de pagos de Bitcoin de código abierto advirtiera sobre una vulnerabilidad crítica de seguridad que, según los reportes, ya está siendo explotada en la práctica. El proyecto ha indicado a los operadores de servidores que actualicen a la versión 2.4.2, verifiquen que la actualización se refleje en el pie de página del servidor y roten las credenciales que podrían haber quedado expuestas.

Para comerciantes, operadores de nodos y empresas nativas del ecosistema cripto que usan BTCPay Server para aceptar pagos en Bitcoin y Lightning Network, esto no es un aviso de mantenimiento rutinario. La advertencia implica la posibilidad de acceso no autorizado y, en el peor de los casos, pérdidas financieras directas.

¿Qué pasó?

BTCPay Server, una pila de procesamiento de pagos de Bitcoin autoalojada y muy utilizada, ha alertado a los administradores sobre una grave vulnerabilidad que afecta la seguridad del servidor. El problema fue reportado por un miembro de Bitcoin Red Team, un grupo centrado en seguridad que analiza infraestructuras relacionadas con Bitcoin.

Al momento de escribir esto, el equipo de BTCPay Server no ha publicado de forma pública todos los detalles técnicos de la vulnerabilidad. Este es un enfoque habitual y responsable durante una explotación activa, ya que divulgar demasiado pronto el funcionamiento del exploit puede ayudar a los atacantes a apuntar a sistemas sin parchear.

Lo que se sabe hasta ahora:

  • BTCPay Server ha lanzado la versión 2.4.2 como actualización de seguridad obligatoria.
  • Los administradores deben confirmar la actualización comprobando que el pie de página del servidor muestre la versión nueva.
  • Si no es posible actualizar de inmediato, el servidor debe apagarse temporalmente.
  • Los operadores deben rotar los materiales de autenticación expuestos, especialmente los macaroons relacionados con Lightning.
  • Los usuarios con billeteras hot on-chain creadas dentro de BTCPay Server deben mover los fondos de inmediato y recrear esas billeteras.
  • El proyecto aún no ha revelado cuándo comenzaron los ataques, cuántos servidores podrían verse afectados ni si ya se han robado fondos.

Los administradores pueden revisar la información más reciente del lanzamiento a través de la página oficial de lanzamientos de BTCPay Server en GitHub.

Por qué esto importa para la infraestructura de pagos de Bitcoin

BTCPay Server es popular porque permite a los comercios aceptar pagos en Bitcoin sin depender de un procesador custodial. Este modelo se alinea muy de cerca con la ética original de las criptomonedas: autocustodia, resistencia a la censura y liquidación directa.

Pero autoalojar también significa asumir responsabilidad propia.

Una instancia de BTCPay Server puede conectarse a:

  • Bitcoin Core u otro backend on-chain
  • nodos de Lightning Network
  • paneles de comercio
  • integraciones con API
  • billeteras hot
  • tiendas en línea y herramientas contables

Si un atacante obtiene acceso con privilegios, las consecuencias pueden ir más allá de la interfaz web. Según la configuración, unas credenciales expuestas podrían permitir manipular facturas, acceder al backend, interactuar con un nodo de Lightning o mover fondos desde billeteras hot.

Este incidente recuerda que la infraestructura de pagos cripto no es solo un sitio web. A menudo está conectada a liquidez real en tiempo real.

Medidas inmediatas para administradores de BTCPay Server

Si operas BTCPay Server, la prioridad es contener primero e investigar después.

1. Actualiza a BTCPay Server 2.4.2

Actualiza tu instancia a la versión 2.4.2 lo antes posible. Después de actualizar, no des por hecho que el proceso se completó correctamente. Inicia sesión y verifica que el pie de página del servidor muestre la versión nueva.

Si usas una implementación con Docker, sigue la guía oficial de actualización del proyecto en la documentación de BTCPay Server.

2. Apaga el servidor si no puedes aplicar el parche de inmediato

Si no puedes actualizar enseguida, desconecta el servidor hasta que puedas hacerlo. Mantener una instancia expuesta en línea durante una explotación activa crea un riesgo innecesario.

Esto es especialmente importante en servidores accesibles públicamente, integrados con procesos de pago de tiendas o conectados a backends de Lightning.

3. Rota los macaroons de Lightning Network

BTCPay Server recomendó específicamente reemplazar los macaroons que pudieran haberse expuesto. En la infraestructura de Lightning, los macaroons son tokens de autenticación que usan LND y servicios relacionados para controlar los permisos de acceso.

Si se filtra un macaroon, un atacante podría realizar las acciones permitidas por esa credencial. Según el alcance de los permisos, esto puede ser extremadamente delicado.

Los operadores deben volver a crear el archivo macaroons.db cuando corresponda y renovar las cadenas de autenticación para otros backends de Lightning Network. Para entender mejor cómo usa LND estas credenciales, consulta la documentación oficial de Lightning Labs sobre macaroons.

4. Mueve los fondos de cualquier billetera hot on-chain

Si creaste una billetera hot on-chain directamente dentro de BTCPay Server, mueve los fondos a una nueva billetera segura de inmediato.

Una billetera hot es cómoda para flujos de pago automatizados, reembolsos y operaciones comerciales, pero también queda expuesta al riesgo del lado del servidor. Si el servidor pudo haber sido comprometido, esa billetera debe considerarse potencialmente insegura.

Después de mover los fondos, recrea la billetera usando credenciales nuevas y una configuración limpia.

5. Revisa registros y patrones de acceso

Tras aplicar el parche y rotar credenciales, los administradores deberían examinar:

  • actividad reciente de inicio de sesión
  • uso de claves API
  • cambios en la configuración de la tienda
  • nuevos usuarios o cambios de permisos
  • actividad inusual de facturas
  • registros de acceso al nodo de Lightning
  • transacciones salientes
  • registros de acceso del servidor web

Aunque no parezca faltar dinero, los atacantes podrían haber creado mecanismos de persistencia o haber recolectado credenciales para usarlas más adelante.

La lección de seguridad más amplia: las billeteras hot necesitan límites estrictos

Esta vulnerabilidad pone de relieve uno de los principios de diseño más importantes en las operaciones cripto: minimizar el valor expuesto a los sistemas en línea.

Un servidor de pagos no debería custodiar más fondos de los que necesita para operaciones de corto plazo. Los comercios y las empresas deberían considerar una estrategia de billeteras por niveles:

  • usar una billetera hot solo para saldos operativos pequeños
  • transferir regularmente el exceso de fondos a almacenamiento en frío
  • separar la recaudación de pagos del almacenamiento de tesorería a largo plazo
  • restringir las claves API y las credenciales de Lightning al mínimo de permisos necesarios
  • mantener las copias de seguridad fuera de línea y con control de acceso
  • probar los procedimientos de respuesta a incidentes antes de que ocurra una emergencia

En el mundo cripto, la frontera entre mantenimiento de software y seguridad de activos es muy delgada. Una actualización de servidor omitida puede convertirse en un incidente de seguridad de una billetera.

Por qué los atacantes se están moviendo más rápido en 2025

El momento de este incidente encaja con una tendencia más amplia en la industria de los activos digitales. Investigadores de seguridad y atacantes están usando cada vez más herramientas asistidas por IA para revisar código, identificar patrones sospechosos y automatizar la búsqueda de vulnerabilidades.

Para los defensores, la IA puede acelerar auditorías y ayudar a que los proyectos de código abierto detecten errores antes. Para los atacantes, esa misma clase de herramientas puede reducir el tiempo necesario para explorar repositorios, generar hipótesis de exploit y probar despliegues vulnerables a gran escala.

Eso no significa que la IA sea la causa raíz de todos los ataques cripto. Pero sí implica que la ventana entre el descubrimiento de una vulnerabilidad y su explotación en el mundo real podría estar reduciéndose.

La industria ya ha visto más atención en torno a la investigación automatizada de vulnerabilidades, la revisión de código impulsada por IA y el riesgo de la cadena de suministro de software. El marco de seguridad OWASP sigue siendo una referencia útil para riesgos comunes en aplicaciones web, mientras que los equipos cripto también deben tener en cuenta claves de billetera, credenciales de nodos, permisos de contratos inteligentes e infraestructura de pagos.

Para los operadores de Bitcoin y Lightning, la lección es práctica: los retrasos en aplicar parches son cada vez más peligrosos.

Lista práctica de seguridad para operadores de pagos cripto

Si tu negocio acepta pagos en Bitcoin o Lightning a través de infraestructura autoalojada, considera adoptar los siguientes controles básicos:

  • habilitar monitoreo automático de nuevos avisos de seguridad
  • suscribirse a los anuncios oficiales del proyecto
  • restringir los paneles de administración mediante VPN o listas de अनुमति de IP cuando sea posible
  • usar credenciales de administrador fuertes y únicas
  • rotar claves API y macaroons con un calendario fijo
  • separar los saldos de la billetera hot de los fondos de tesorería
  • mantener las copias de seguridad del servidor cifradas y probadas
  • aplicar acceso de mínimo privilegio en todas las integraciones
  • contar con un plan de respuesta a incidentes por escrito
  • almacenar los activos a largo plazo en autocustodia offline o respaldada por hardware

Estos pasos no eliminarán todo el riesgo, pero sí reducen el radio de impacto cuando aparece una vulnerabilidad.

Dónde encaja OneKey en una configuración de tesorería más segura

Para comerciantes y equipos cripto, BTCPay Server puede ser una herramienta potente para aceptar Bitcoin sin renunciar a la soberanía sobre los pagos. Sin embargo, los servidores de pagos son sistemas en línea y no deberían tratarse como bóvedas a largo plazo.

Las hardware wallets de OneKey están diseñadas para ayudar a los usuarios a mantener las claves privadas fuera de línea, lo que las convierte en una opción práctica para almacenar fondos de tesorería por separado de la infraestructura de pagos hot. En una configuración así, BTCPay Server puede encargarse de las operaciones diarias de pago, mientras que los saldos mayores se trasladan periódicamente a autocustodia respaldada por hardware.

Esa separación importa. Cuando aparece una vulnerabilidad del lado del servidor, el objetivo es que solo estén en riesgo los fondos operativos limitados, no toda la tesorería.

Reflexiones finales

La vulnerabilidad de BTCPay Server es un recordatorio serio de que la infraestructura de Bitcoin autoalojada requiere mantenimiento activo. Los operadores deben actualizar de inmediato a la versión 2.4.2, rotar credenciales, recrear los componentes de billetera expuestos y retirar fondos de cualquier billetera hot potencialmente comprometida.

La autocustodia es poderosa, pero también exige una arquitectura de seguridad disciplinada. En 2025, con atacantes que cuentan con mejor automatización y herramientas asistidas por IA, los usuarios y las empresas de cripto necesitan responder con parches más rápidos, saldos más pequeños en billeteras hot y una separación más sólida entre los sistemas de pago y el almacenamiento a largo plazo.

Asegura tu viaje cripto con OneKey

View details for Comprar OneKeyComprar OneKey

Comprar OneKey

La cartera de hardware más avanzada del mundo.

View details for Descargar aplicaciónDescargar aplicación

Descargar aplicación

Opera con activos globales. Empieza en minutos solo con tu email.

View details for OneKey SifuOneKey Sifu

OneKey Sifu

Claridad cripto — a una llamada de distancia.