BTCPay: la auditoría acabó el 5 de agosto y el 7 caían los nodos

El 5 de agosto de 2026, la mayor auditoría de seguridad de la historia del ecosistema Bitcoin cerró con 4.962 hallazgos en 27,5 horas; en la noche del 6 al 7, un fallo que no figuraba en ese informe empezó a vaciar nodos Lightning a través de BTCPay Server. BTCPay es el procesador de pagos autoalojado que usan comercios y proyectos para aceptar bitcoin sin intermediarios, y el fallo permitía a un atacante remoto, sin ninguna autenticación, descargar los ficheros .macaroon — las credenciales de administrador de LND (la implementación de nodo Lightning más extendida). Con ese fichero, los atacantes cerraron canales a la fuerza y barrieron fondos de víctimas con nombre: Foundation, el fabricante de la hardware wallet Passport; Citadel21, la publicación de hodlonaut; y el propio desarrollador de Sparrow Wallet, Craig Raw, que reconstruyó el ataque desde los logs de su servidor tras perder fondos. El parche 2.4.2, publicado el 7 de agosto, cierra la vía de entrada, pero las credenciales ya robadas siguen funcionando hasta que se rotan. Este artículo fija la cronología del 4 al 10 de agosto, el mecanismo del macaroon, lo que el barrido asistido por IA no listó y los pasos que el advisory exige más allá de actualizar.

¿Qué pasó con BTCPay Server entre el 4 y el 10 de agosto de 2026?

Setenta y dos horas separan el arranque del barrido del Bitcoin Red Team (tarde del 4 de agosto) del advisory formal de BTCPay (7 de agosto). En medio caben el cierre de la auditoría, los primeros nodos vaciados, la alerta de emergencia y el reconocimiento público de que el informe asistido por IA no contenía el fallo que se estaba explotando. La secuencia, contrastada contra el advisory oficial, The Defiant, The Block y Crypto Briefing, queda así:

Dos detalles de la cronología pesan más que el resto. El primero: la explotación ya estaba en marcha cuando salió la alerta — Foundation y Citadel21 perdieron fondos antes de poder leer nada. El segundo: la auditoría más masiva que ha recibido el ecosistema y el exploit vivo se cruzaron en la misma semana, sobre el mismo stack, sin tocarse.

¿Por qué un fichero .macaroon de BTCPay da control total del nodo Lightning?

Un macaroon es la credencial de la API de LND: un token portador, comparable a una cookie de sesión de administrador que no caduca. El nodo no comprueba quién presenta el fichero; comprueba que el fichero es válido. LND emite varios macaroons con permisos escalonados — de solo lectura, de facturación, de administración — y BTCPay necesita guardarlos en el servidor para hablar con el nodo: ahí estaba el fichero que el fallo dejaba al alcance de cualquiera. El de administrador autoriza todas las operaciones — abrir y cerrar canales, firmar y mover fondos — sin contraseña ni segundo factor adicionales. Por eso el advisory del 7 de agosto resume el fallo en una sola frase: la vulnerabilidad permitía a «un atacante remoto no autenticado obtener los ficheros de credenciales .macaroon de LND».

Ese diseño explica también por qué la remediación exige un paso manual. Los macaroons descienden de una clave raíz que guarda el propio nodo; mientras esa clave no se regenere, cualquier copia del fichero — esté donde esté — sigue autenticando. Rotarlos significa invalidar la emisión anterior y regenerar los ficheros, reconfigurando después cada aplicación conectada al nodo. El parche automatiza esa rotación en los despliegues estándar, pero no puede saber cuántas copias del fichero salieron ni a dónde — la revisión del historial sigue siendo del operador.

El detalle técnico del vector no se ha publicado. El advisory no asigna CVE ni GHSA a 20 de agosto de 2026, y The Defiant señala que el fallo explotado tampoco coincide con lo visible en el changelog: el 4 de agosto BTCPay había corregido un bypass de la autenticación de dos factores en su API Greenfield (el validador solo comprobaba llaves FIDO2, dejando pasar email y contraseña en cuentas protegidas con aplicación autenticadora), un problema distinto del que vació los nodos.

El alcance sí está acotado: todas las versiones anteriores a 2.4.2, incluidas las release candidates de la propia 2.4.2, y solo en despliegues conectados a LND. Las carteras on-chain de BTCPay, incluidas las calientes, quedan fuera — aunque el propio proyecto tardó en confirmarlo: la guía inicial pedía mover todos los fondos y la actualización del advisory lo acotó después de revisar el caso («confirmamos que solo LND está impactado»).

¿Quién perdió fondos por el exploit de BTCPay y cuánto se robó en total?

Tres víctimas tienen nombre y declaración pública. Zach Herbert, CEO de Foundation, publicó el 7 de agosto que el nodo Lightning de la compañía había sido «drenado durante la noche», con los canales cerrados a la fuerza y los fondos barridos; la cartera caliente on-chain de su BTCPay quedó intacta, coherente con el alcance del fallo. hodlonaut avisó en caliente — «esto es un ataque en curso contra usuarios de BTCPay Server; el nodo Lightning de Citadel21 acaba de ser barrido» — matizando que el nodo guardaba poco saldo. Y Craig Raw, desarrollador de Sparrow Wallet, perdió fondos de su propio nodo y usó los logs de su servidor para reconstruir el vector; BTCPay le acredita la divulgación responsable en el advisory. Dorier lo resumió sin adornos: «tuvimos muchísima suerte de que el afectado fuera un desarrollador capaz de analizar los logs y entender qué estaba pasando».

La divulgación fue deliberadamente rápida. Según reconstruye TFTC, el equipo que analizó el fallo comprimió el calendario habitual de divulgación responsable con un argumento explícito: «otros encontrarán los mismos fallos». Con la explotación ya en marcha, cada hora de silencio adicional trabajaba para el atacante, y la alerta y el parche salieron la misma mañana del 7 de agosto — con la instrucción de apagar el servidor como medida puente para quien no pudiera esperar.

La cifra total robada no existe públicamente. BTCPay no ha publicado ni el número de servidores comprometidos ni el bitcoin total drenado, y ninguna de las víctimas ha puesto cantidad a su pérdida a 20 de agosto de 2026. Tampoco hay denominador: BTCPay es software autoalojado sin registro central de despliegues, así que no existe censo público de cuántas instancias corren LND ni de qué fracción quedó expuesta. Cualquier cifra global que circule a mediados de agosto de 2026 es una estimación sin base verificable.

¿Qué arregla BTCPay 2.4.2 solo y qué queda en manos del operador?

El parche corrige el código que exponía los ficheros y, en los despliegues Docker estándar, hace dos cosas más: regenera automáticamente los macaroons al subir LND a 0.21.1 y retira temporalmente el acceso público a la API de LND — una cartera externa como Zeus deja de poder conectarse por el dominio o la dirección onion hasta que el proyecto considere seguro restaurarlo. Lo que ningún parche puede hacer es alcanzar los nodos que siguen en versiones anteriores: ahí el macaroon robado el 7 de agosto abre el nodo igual de bien el 20, porque la credencial vive en LND hasta que se regenera. El advisory ordena la secuencia completa:

1. Actualizar a BTCPay Server 2.4.2 con LND 0.21.1 (en Docker estándar, la actualización regenera los macaroons por sí sola).
2. En instalaciones manuales o no estándar, rotar los macaroons a mano.
3. Revisar la actividad del nodo en busca de cierres de canal y transacciones no autorizadas.
4. Apagar el servidor si la actualización no puede ser inmediata.

Es la segunda vez en el mismo mes que un parche del ecosistema llega con esta letra pequeña. El fallo de entropía de Coldcard, corregido por firmware a primeros de agosto, dejó intactas las semillas débiles ya generadas: actualizar el dispositivo no repara las claves que produjo. En BTCPay, actualizar el servidor no invalida las credenciales que salieron de él. En Coldcard, el firmware corregido no repara las semillas ya generadas. En BTCPay la 2.4.2 sí regenera los macaroons de los despliegues estándar; lo que nada actualiza son los nodos que siguen en versiones vulnerables, y ahí el daño previo permanece operativo.

¿Qué encontró la auditoría del Bitcoin Red Team y qué no encontró en BTCPay?

El Bitcoin Red Team es un grupo de voluntarios — 16 investigadores, según The Defiant — que entre el 4 y el 5 de agosto apuntó herramientas de análisis asistido por IA contra 390 proyectos open-source del stack Bitcoin, con unos 40.000 dólares de financiación de OpenSats y un arnés propio de 171.599 líneas de código que no solo marca hallazgos: los prueba, reproduce y documenta. El resultado, 4.962 hallazgos en 27,5 horas con 85 críticos, es el mayor barrido de seguridad que ha recibido el ecosistema, montado además como reacción al caso Coldcard de la semana anterior. El grupo ha anunciado que abrirá el código de sus herramientas y que ofrecerá el arnés para auditar también implementaciones de código cerrado, lo que convierte el experimento del 4-5 de agosto en la primera edición de un programa recurrente.

El fallo de BTCPay no estaba en ese informe. Lo dijo el propio Nicolas Dorier en X el 7 de agosto, con el exploit aún activo: «El informe de IA que recibimos del red team no incluía este. Pero este bug era realmente escurridizo; no me sorprende que un simple escaneo no lo encontrara, o lo considerara de bajo riesgo» («The AI report we got from red team didn't include this one. But this bug was really sneaky, I am not surprised a simple scan didn't find it, or thought it was low risk»).

Conviene leer el dato en su tamaño exacto. Es una muestra de uno: un falso negativo no invalida una metodología que produjo 85 hallazgos críticos verificables en 27,5 horas, igual que un acierto no la consagraría. Lo que sí documenta, con fecha y caso concreto, es en qué capa rinde peor el escaneo a escala: los errores de lógica de aplicación — quién puede pedir qué fichero bajo qué condición — que un análisis estático puede clasificar como ruido de bajo riesgo. El propio desenlace subraya la complementariedad entre capas: el mismo Red Team cuyo informe no listaba el fallo hizo la divulgación coordinada y el análisis del exploit junto a BTCPay, y recibió 0,21 BTC del proyecto por ello. La brecha entre lo que la IA detecta y lo que se llega a parchear tiene sus cifras propias; el caso BTCPay documenta la primera auditoría masiva con un falso negativo fechado y explotado días después.

¿Es el exploit de BTCPay el primer caso Bitcoin de la tesis del perímetro?

En junio documentamos que los grandes robos de 2026 ya no atacan el contrato sino el perímetro: credenciales, infraestructura de despliegue, herramientas del desarrollador. Todo el universo de esa taxonomía era DeFi sobre EVM. BTCPay la extiende al stack Bitcoin con un caso de manual: el atacante no rompió criptografía, no explotó un fallo de Lightning ni de LND, no tocó el protocolo. Robó un fichero de un servidor de pagos y operó el nodo como su administrador legítimo.

El detalle incómodo es que Lightning funcionó exactamente según diseño. El cierre forzoso de canales es una operación prevista del protocolo, disponible para quien presenta la credencial de administrador; los fondos salieron por transacciones válidas firmadas por el nodo de la víctima. Igual que en los casos EVM de junio, el perímetro — un fichero accesible donde no debía — convirtió toda la seguridad criptográfica de las capas inferiores en irrelevante, porque el atacante entró por encima de ella. Para el modelo de amenaza de quien autoaloja pagos en bitcoin, el caso reordena prioridades: la superficie que vigilar incluye cada pieza del servidor que guarda o sirve credenciales del nodo, y las apuestas no son menores — el informe anual de 2025 del propio proyecto presume de pagos individuales procesados de hasta 2 millones de dólares, el de Namecheap.

¿Cómo encaja BTCPay en el agosto de la custodia bitcoin?

El exploit de BTCPay es el tercer vector distinto que cede en el mismo mes, y ninguno de los tres es el protocolo. Agosto de 2026 deja un fallo de dispositivo (la entropía débil de Coldcard), una brecha de datos en el proveedor logístico de Trezor explotada para phishing dirigido, y ahora unas credenciales de infraestructura expuestas en el servidor de pagos autoalojado. Cada caso tiene un remedio distinto — regenerar semillas, desconfiar del correo postventa, rotar macaroons — y los tres comparten la economía del atacante: comprometer el eslabón operativo que rodea a las claves cuesta órdenes de magnitud menos que atacar la criptografía que las protege. La tabla resume qué falló y qué quedó intacto en cada caso:

La reacción del mercado a esta serie ya tiene medición propia: tras Coldcard, la cuota de bitcoin en el flujo hacia ETF apenas pasó del 67,7% al 71,2%, sin señal de huida de la autocustodia. El caso BTCPay tampoco altera esa lectura: golpea a un perfil muy específico — operadores que autoalojan pagos con nodo Lightning propio — y deja fuera al tenedor medio de bitcoin, con una cuantía total que ni siquiera es pública.

¿Qué debe hacer un operador de BTCPay con LND tras el exploit?

La versión de BTCPay Server es visible en el pie de página de la propia instancia: si es anterior a 2.4.2, el orden del advisory sigue vigente — actualizar de inmediato o apagar. Con el servidor ya en 2.4.2 y LND en 0.21.1, quedan los pasos que el parche no hace solo: revisar el historial del nodo en busca de cierres de canal y transacciones no reconocidas, y rotar los macaroons. La rotación merece hacerse aunque no haya señales de intrusión: los logs de Foundation demuestran que el barrido precedió a la alerta pública, así que la ausencia de avisos durante esos días no acredita ausencia de copia de credenciales.

La revisión del nodo tiene señales concretas que buscar. Un cierre forzoso deja rastro doble: figura en el historial de canales del propio LND y queda escrito en la cadena como transacción de cierre unilateral, de modo que un operador puede auditar si todos los cierres de la primera semana de agosto los inició él. Cualquier cierre no reconocido, pago saliente sin factura asociada o conexión API fuera de horario en los logs del servidor convierte la rotación de macaroons en urgente y justifica mover el saldo restante a un nodo con credenciales limpias.

Para los fondos ya robados hay una vía abierta desde el 10 de agosto: partidarios del proyecto ofrecen el 10% de lo recuperado como recompensa, con tope de 3 BTC por recuperación completa, según recogió The Block. A 20 de agosto no se ha hecho pública ninguna recuperación. Lo que sí está pagado es la otra factura del incidente: 0,42 BTC de BTCPay a quienes divulgaron y analizaron el fallo de forma responsable — la mitad al desarrollador que lo encontró leyendo sus propios logs después de perder dinero, la otra mitad al equipo — del que el propio Raw forma parte — cuyo escáner, dos días antes, había pasado por encima sin verlo.

Fuentes y enlaces: Advisory oficial de BTCPay Server 2.4.2 (7-10 de agosto de 2026) · The Defiant · The Block — recompensa de recuperación · Crypto Briefing — hallazgos del Bitcoin Red Team · TFTC · CoinDesk