BTCPay Server advirtió a los operadores el 7 de agosto de 2026 que una vulnerabilidad crítica se está explotando de forma activa y puede provocar pérdida de fondos, y publicó el mismo día la versión de emergencia v2.4.2. La instrucción del proyecto fue directa: actualiza ya, o apaga el servidor hasta poder hacerlo.

Seis horas después, BTCPay publicó un aviso de seguridad más completo que acotó el radio de daño y retiró una de sus propias instrucciones de emergencia. Si actuaste con el primer hilo y dejaste de leer ahí, la sección de abajo es la que te importa.

Qué falló

BTCPay Server es software libre y autoalojado que permite a comercios y particulares aceptar bitcoin (en cadena y por Lightning) sin pasar los cobros por un procesador custodio. Tú corres el stack; tú asumes las llaves y el riesgo operativo.

El fallo explotado permitía que un atacante remoto sin autenticar obtuviera archivos de credenciales .macaroon de LND, una de las implementaciones de nodo Lightning. Los macaroons son las credenciales al portador que autorizan acciones sobre ese nodo: si caen en manos ajenas, quien las tenga puede controlarlo y sacar los fondos. BTCPay dice que los ataques que revisó apuntaron solo a archivos con extensión .macaroon.

BTCPay todavía no publica los detalles técnicos, para que los operadores tengan tiempo de actualizar: una decisión defendible en pleno incidente, que de momento deja la clase exacta de bug fuera del dominio público.

El alcance importa, porque el aviso es más estrecho de lo que sugería la primera alerta:

  • El riesgo de credenciales afecta a los despliegues con LND. Otras implementaciones de Lightning, y las instancias que no usan Lightning, no están expuestas a ese riesgo, aunque BTCPay insiste en que todos actualicen igual.
  • Los monederos en cadena del propio BTCPay, incluidos los calientes, no están afectados. Los fondos que estén en el monedero interno en cadena de LND sí forman parte del nodo comprometido y pueden seguir en riesgo.

La 2.4.2 además sube LND a la 0.21.1 y regenera sus macaroons automáticamente en instalaciones estándar, y quita temporalmente el acceso público a la API de LND en despliegues con Docker: por ahora una billetera externa como Zeus no podrá conectarse a través de tu dominio BTCPay ni de tu dirección onion. El crédito por la divulgación es de Craig Raw, de Sparrow Wallet, con el esfuerzo del Bitcoin Red Team ayudando a analizar el exploit.

El otro arreglo de la misma versión

Conviene separarlo, porque se ha confundido mucho: la 2.4.2 también corrige un bypass de doble factor TOTP en la API Greenfield, y ese es un problema distinto, no el que estaba bajo explotación activa.

Según el pull request #7491, fusionado el 4 de agosto por el mantenedor Nicolas Dorier y reportado por Ben Carman (@benthecarman), la autenticación Basic solo comprobaba si la cuenta tenía credenciales FIDO2. Quienes protegían el inicio de sesión de la interfaz solo con una app de autenticación TOTP podían llamar a toda la API con correo y contraseña, y con permisos sin restricción: un desfase entre el modelo de seguridad de la interfaz y el de la API, aunque los límites de tasa seguían frenando el adivinado de contraseñas.

Un cambio relacionado desactiva la autenticación Basic de Greenfield por defecto cinco minutos después de crear la cuenta, con opción de reactivarla en ajustes o por API.

Quién lo sufrió

BTCPay no ha publicado un total robado; solo confirma que hubo usuarios afectados y fondos sustraídos. CoinDesk nombró al fabricante de monederos de hardware Foundation —cuyo CEO, Zach Herbert, dijo que su nodo fue vaciado de un día para otro, con canales cerrados y fondos barridos— y a la publicación bitcoin Citadel21 entre los operadores que reportaron nodos vaciados. Trata esos reportes como cobertura multi-medio de un incidente en curso, no como un inventario forense cerrado.

Lo que BTCPay se desdijo

El primer hilo, publicado esa misma tarde, pedía a los operadores renovar los macaroons y macaroons.db, renovar las cadenas de autenticación de otros backends Lightning y, si habías generado un monedero caliente en cadena dentro de BTCPay, mover esos fondos y recrear el monedero.

Esa última instrucción quedó retirada. En el aviso formal, BTCPay escribió que había recomendado sacar fondos de los monederos en cadena de BTCPay «por exceso de precaución», y que tras revisarlo confirmó que solo LND está afectado. Los monederos en cadena, calientes incluidos, no lo están.

Mover monedas no sale gratis: pagas comisiones, tocas llaves y te arriesgas a equivocarte de dirección bajo presión. Quienes siguieron el primer hilo gastaron ambas cosas en una precaución que resultó innecesaria. No es un escándalo: así se ve una respuesta de emergencia de buena fe mientras el cuadro todavía se forma. Sí es una razón para seguir un incidente hasta su resolución en vez de actuar una vez y cerrar la pestaña.

Qué deben hacer los operadores ahora

  1. Actualiza a la 2.4.2 desde Server Settings → Maintenance → Update. Confirma que el pie de página muestra 2.4.2 y que LND reporta la 0.21.1. Si corres LND y aún no puedes actualizar, saca el servidor de línea: no dejes un despliegue afectado accesible desde internet.
  2. Audita tu nodo LND. Busca pagos que no hiciste, cierres de canal inesperados, pares desconocidos y saldos que no cuadren con tus propios registros.
  3. Ocúpate de las credenciales que gestionas tú. La actualización regenera los macaroons automáticamente en instalaciones estándar, pero si expones LND por tu propio proxy inverso, servicio Tor o puerto redirigido, rota esas credenciales por tu cuenta: actualizar BTCPay no cierra las vías de acceso que están fuera de él.
  4. Cuenta con el bache de Zeus y otras billeteras externas en instalaciones con Docker, hasta que BTCPay restaure el acceso público a la API de LND.
  5. Prefiere API keys Greenfield con permisos acotados frente a Basic auth de larga vida. El freno por defecto de esta versión empuja en la misma dirección.

Esto es riesgo de capa de aplicación, no una rotura de las reglas de consenso de Bitcoin: el modo de fallo es el software que guarda permisos Lightning junto al motor de facturas.

Por qué importan los rieles de comercio

BTCPay está donde la ideología se encuentra con el inventario: el café o la cooperativa que cobra en sats sin pasar cada venta por un exchange. Ese modelo es popular justo porque evita intermediarios, y el precio es que tú eres el equipo de seguridad: no hay un proveedor SaaS empujando un parche silencioso a todos los inquilinos a la vez.

Para los comercios de América Latina que ya usan rieles de bitcoin para turismo, freelancing o coberturas ante la inflación, la lección va tanto de atención como de arquitectura. Autoalojarte te pone en la lista de correo de tus propias emergencias: tienes que ver el aviso, aplicarlo y seguir mirando mientras se afina. Suscríbete a las publicaciones del proyecto, no solo a su cuenta de X. Y como higiene ordinaria, no como respuesta al incidente, guarda la tesorería en frío y con multisig, y deja en el nodo solo el flotante de trabajo.

Para llevar

El 7 de agosto, BTCPay Server dijo que un fallo crítico estaba bajo explotación activa, publicó la 2.4.2 y pidió a los operadores sin parche apagar el servicio hasta actualizar. El bug explotado exponía credenciales macaroon de LND a atacantes sin autenticar; el bypass de 2FA TOTP de la misma versión es un problema aparte. BTCPay confirmó después que el riesgo es específico de LND y que los monederos en cadena, calientes incluidos, no están afectados, retirando su consejo inicial de mover esos fondos.

Si corres BTCPay con LND, trátalo como incidente vivo hasta que el pie muestre la 2.4.2 y la 0.21.1 de LND y el historial de tu nodo se vea limpio. Los pagos autoalojados siguen ganando a la custodia de terceros, pero solo si el operador aplica el parche y lee el seguimiento. Esto es una nota de operaciones de seguridad, no consejo de inversión.

Fuentes