BTCPay Server, el software de procesamiento de pagos de código abierto y autoalojado que permite a los comerciantes aceptar Bitcoin sin depender de un custodio externo, ha publicado una actualización de emergencia para corregir una vulnerabilidad crítica que actualmente está siendo explotada para robar fondos de los usuarios.

Según se detalla en el pull request #7491 de GitHub, la falla permite a los atacantes eludir la autenticación de dos factores basada en TOTP a través de la autenticación básica de la API de Greenfield de BTCPay. La causa raíz radica en que el mecanismo de autenticación verificaba si había credenciales FIDO2 válidas registradas, en lugar de confirmar si la autenticación de dos factores estaba realmente activada. Como resultado, las cuentas protegidas por una aplicación autenticadora TOTP podían ser accedidas a través de la API usando únicamente un correo electrónico y una contraseña. La API de Greenfield es la interfaz basada en REST de BTCPay utilizada para la integración programática con plataformas de comercio electrónico, sistemas de punto de venta y flujos de trabajo automatizados, lo que significa que los comerciantes con configuraciones basadas en API enfrentan la mayor exposición.

La vulnerabilidad existe dentro de la capa de aplicación de BTCPay y no afecta al protocolo de Bitcoin (BTC) en sí. BTCPay publicó la versión 2.4.2 de su software el 7 de agosto y aconsejó a todos los usuarios que se aseguren de haber actualizado también NBXplorer a la versión 2.6.10.

BTCPay abordó el incidente públicamente a través de su cuenta de X.

La respuesta del mercado se mantiene estable

A pesar de la preocupación de seguridad, el precio de mercado y la valoración de Bitcoin se han mantenido relativamente estables. Según CoinMarketCap, Bitcoin se negocia a aproximadamente $64,889, un incremento del 0,82% respecto al día anterior, mientras que su capitalización de mercado de $1,3 billones ha aumentado solo un 0,79%. Aunque el volumen de operaciones en 24 horas aumentó un 20,98%, el precio y la capitalización estables sugieren que el incidente no ha afectado materialmente la valoración general de mercado de Bitcoin.

La reacción moderada del mercado es coherente con la naturaleza de la vulnerabilidad. La falla de BTCPay afecta a comerciantes y operadores individuales, no a las reglas de consenso ni a los fundamentos criptográficos de Bitcoin. Sin embargo, el impacto no debe subestimarse. BTCPay sirve como puente entre la red de Bitcoin y los sistemas de pago de las empresas, gestionando facturación, procesamiento de pagos y administración de billeteras. El diseño no custodial de la plataforma significa que los comerciantes mantienen el control directo de sus claves privadas, una razón clave por la que muchos la eligieron sobre los procesadores alojados. Una omisión de autenticación que otorga a los atacantes acceso a cuentas de operadores socava directamente ese modelo de seguridad, exponiendo potencialmente las funciones de gestión de billeteras y los datos de pago, aunque los fondos no estén custodiados por un tercero.

Guía de remediación para operadores

La solución inmediata es sencilla: actualizar BTCPay Server a la versión 2.4.2 y, para los integradores, actualizar NBXplorer a la versión 2.6.10. BTCPay recomienda usar claves de API en lugar de autenticación básica, ya que las claves de API permiten controles de permisos más granulares.

El parche introduce cambios en el proceso de autenticación que verifican si el 2FA está realmente activo, cerrando la brecha que anteriormente permitía a las cuentas protegidas con TOTP omitir el segundo factor de autenticación. Debido a que BTCPay es autoalojado, los operadores no pueden depender de un proveedor central para aplicar el parche y deben tomar medidas de forma independiente, una realidad que también significa que la ventana de exposición puede permanecer abierta para implementaciones que no se monitorean ni mantienen activamente. Hay documentación adicional disponible en BTCPay.

Un patrón de vulnerabilidades en la infraestructura de pagos

El anuncio de BTCPay sigue a una semana turbulenta para la infraestructura de pagos de Bitcoin. Como se informó anteriormente, ZEUS, un proveedor de billeteras Lightning, desconectó su infraestructura de pago debido a un problema de seguridad, y otros proveedores de servicios Lightning también resultaron afectados.

Estos incidentes no indican fallas en los protocolos de pago centrales de Bitcoin. Sin embargo, sí ponen de relieve los riesgos de seguridad introducidos por las capas de software construidas alrededor de la cadena de bloques. Para los comerciantes que evalúan plataformas de pago con Bitcoin, la naturaleza recurrente de estas revelaciones subraya que la selección de infraestructura ahora conlleva un riesgo operativo continuo comparable a la gestión de pasarelas de pago tradicionales, incluyendo la necesidad de seguimiento de parches, auditoría de accesos y planificación de respuesta a incidentes.

Un estudio de 2024 realizado por investigadores de Northeastern University y TU Delft utilizó modelado formal para identificar debilidades de seguridad en el protocolo de pago de un solo salto de Lightning, incluyendo un ataque recientemente descrito de "Payout Race". Un estudio separado de 2026 examinó ataques de descubrimiento de saldos y encontró que los atacantes podían inferir información sobre los saldos de los canales Lightning. La mitigación propuesta redujo la fuga de información hasta en un 62% en simulaciones.

Ambos estudios subrayan una realidad más amplia: la seguridad de Bitcoin se extiende mucho más allá de la propia cadena de bloques. Las billeteras, las API, los procesadores de pagos y la infraestructura Lightning introducen todas superficies de ataque adicionales.

El historial de vulnerabilidades de BTCPay

Este no es el primer error crítico de BTCPay. En enero de 2023, el proyecto divulgó la vulnerabilidad CVE-2022-32984, una fuga de información crítica que afectaba a las versiones 1.3.0, 1.4.0 y 1.5.3 de BTCPay. Esa falla podía exponer detalles sensibles de las tiendas, incluyendo un xpub y credenciales Lightning vinculadas a un nodo externo, a través de aplicaciones de punto de venta accesibles públicamente. BTCPay resolvió el problema en la versión 1.5.4 y otorgó al investigador Antoine Poinsot una recompensa de $5,000.

La distinción entre ambos incidentes es notable: la vulnerabilidad de 2023 era un problema de divulgación de información, mientras que la falla actual implica una omisión de autenticación que elude la seguridad TOTP a través de la API de Greenfield. La progresión de la exposición de datos a la elusión activa de la autenticación refleja la creciente sofisticación de las vulnerabilidades que se identifican en el software relacionado con Bitcoin.

Los riesgos crecen para los comerciantes

El perfil de riesgo para los comerciantes se está intensificando a medida que se acelera la adopción de Bitcoin para pagos. Una investigación de River publicada en febrero de 2026 encontró que el uso promedio de Bitcoin por parte de los comerciantes aumentó un 74% solo en 2025, mientras que el uso de Lightning se incrementó un 300%, superando los $1.000 millones en volumen mensual.

La infraestructura circundante es considerable. BuiltWith ha detectado 248 sitios web que utilizan BTCPay Server, incluyendo 74 instalaciones activas, cifras que no incluyen implementaciones privadas o de otro tipo no detectables. Mientras tanto, la última instantánea de 1ML muestra 6.280 nodos Lightning, 21.221 canales y una capacidad total de red de 2.818,49 BTC.

A esa escala, las vulnerabilidades en la infraestructura circundante conllevan consecuencias significativas, incluso cuando la capa base de Bitcoin permanece sin afectar. El incidente de BTCPay no indica una falla en el propio Bitcoin; más bien, demuestra que las empresas construidas sobre Bitcoin heredan una carga de seguridad más amplia. La cadena de bloques puede seguir funcionando según lo diseñado, pero las aplicaciones en las que confían los comerciantes pueden convertirse en puntos de falla.

Para los operadores de BTCPay, las prioridades son claras: actualizar a la versión 2.4.2, revisar los registros de autenticación y acceso en busca de señales de compromiso y cambiar de la autenticación básica a claves de API específicas siempre que sea posible.