Asegurar BTCPay Server: por qué la actualización a 2.4.4 no protege por sí sola tu nodo Lightning

Vamos directos a lo que te ha traído hasta aquí: la actualización a BTCPay Server 2.4.4 cierra la ruta pública predeterminada hacia tu nodo Lightning. Lo que no retira es una ruta que hayas construido tú. Quien en algún momento expuso la interfaz LND de su servidor a través de su propio proxy inverso tiene, por tanto, dos tareas: actualizar y volver a eliminar ese acceso. El proyecto que está detrás de BTCPay Server escribe exactamente eso en su anuncio del 8 de septiembre de 2026.

El motivo no es un robo nuevo. El proyecto observa programas automatizados que rastrean de forma selectiva servidores en los que ese acceso se ha vuelto a abrir a mano. Hasta ahora no se ha comunicado ninguna toma de control lograda por esa vía, y el proyecto tampoco establece relación alguna con los autores del incidente de agosto. Esa es la buena noticia del asunto: existe una ventana en la que el problema puede resolverse sin daños.

Para ti, como tenedor o como comerciante, aquí hay en juego algo más que un detalle de servidor. Un servidor de pagos autoalojado es el punto donde confluyen los pagos entrantes en bitcoin, las claves de tu nodo Lightning y tu saldo de explotación. Quien pierde el acceso ahí pierde dinero real, no configuración. Por eso sobre la misma mesa va una segunda pregunta: ¿cuánto saldo necesita permanecer de forma continua en un nodo conectado a la red y qué corresponde a la custodia en frío? Si todavía no has trazado esa separación, nuestra comparativa de carteras de hardware es mejor punto de partida que cualquier otra regla de proxy.

Qué está ocurriendo: los bots llaman a un punto de acceso LND desprotegido

El proyecto describe el patrón abiertamente. Programas automatizados llaman repetidamente a una ruta concreta de la interfaz de programación de LND: el punto de acceso para cambiar la contraseña de la cartera, en /lnd-rest/btc/v1/changepassword. Están afectados de forma expresa los servidores en los que ese acceso se volvió a activar manualmente después de que BTCPay Server lo desactivara por defecto en agosto.

El punto que vuelve delicado el asunto: ese punto de acceso no exige identificación alguna mientras la cartera LND siga bloqueada. No es un fallo en sentido estricto, sino el diseño de la interfaz. Una cartera bloqueada todavía no puede autenticar a nadie, así que la vía para desbloquearla y para cambiar la contraseña tiene que ser accesible sin credencial. Mientras esa vía solo sea accesible dentro del servidor, resulta inofensiva. Solo su publicación en la red abierta la convierte en una puerta de entrada.

Macaroon, LND y proxy inverso: los tres conceptos sin los que el resto no se sostiene

LND es una de las implementaciones extendidas de la red Lightning, es decir, de la capa de pagos que liquida las transferencias de bitcoin en segundos y por fracciones de céntimo. Si tu BTCPay Server acepta pagos Lightning, por regla general es LND lo que hay debajo.

Un macaroon es la credencial con la que LND permite órdenes. Puedes imaginarlo como un archivo de clave con derechos graduados. El macaroon de administración es la llave maestra: quien lo tiene dispone de la cartera y de los canales de pago del nodo.

Un proxy inverso es el servicio de servidor que recibe las peticiones entrantes de internet y las traslada al servicio interno correcto. BTCPay Server trae uno propio. Muchos operadores han instalado un segundo al lado o delante, por ejemplo para que una cartera de móvil hable con su nodo desde fuera de casa. De esa redirección construida a mano trata justamente todo esto.

Por qué se abre siquiera la ventana tras reiniciar LND

La secuencia no tiene nada de espectacular, y por eso resulta eficaz. Tras cada reinicio de LND la cartera queda bloqueada al principio. BTCPay Server dispone de un desbloqueo interno que aporta la contraseña automáticamente. Entre el arranque del servicio y el momento en que ese desbloqueo actúa transcurre un intervalo breve.

Si durante ese intervalo la interfaz es accesible desde la red abierta, un atacante puede ser más rápido. El proyecto describe la consecuencia con sobriedad: quien en ese momento envía la contraseña conocida puede fijar una nueva y hacer que LND le expida un macaroon de administración con el que gobernar el nodo. A partir de ahí la llave maestra pertenece a otro.

Un detalle del pasado lo ha agravado: las instalaciones antiguas de BTCPay creaban sus carteras LND con una contraseña predeterminada común. No había, pues, nada que adivinar. Quien sabía cuál era el valor de fábrica solo tenía que llamar a la puerta en el momento oportuno.

El robo de agosto y el sondeo de septiembre son dos sucesos distintos

La distinción importa, porque la cobertura en alemán se quedó en agosto y ambos hechos se confunden con facilidad en uno solo.

El suceso más antiguo, 7 de agosto de 2026. El proyecto publicó un aviso de seguridad sobre la versión 2.4.2. Todas las versiones anteriores contenían un agujero por el que un atacante remoto sin identificar podía hacerse con los archivos macaroon de LND. El proyecto confirma de forma expresa que el agujero fue explotado, que hubo usuarios afectados y que salieron fondos. Las carteras on-chain propias de BTCPay Server no quedaron comprendidas en ello, tampoco las calientes; el saldo de la cartera on-chain de LND, en cambio, pertenece al nodo afectado. Más tarde, el proyecto y quienes lo respaldan ofrecieron una recompensa del 10 % de los bitcoin recuperados, con un tope de tres BTC, unos 190.000 dólares por entonces.

El suceso nuevo, 8 de septiembre de 2026. Aquí no hay hasta la fecha daño comunicado alguno. Se trata de bots que buscan una vía de ataque y de una medida preventiva del proyecto. Quien mezcla ambas cosas afirma una pérdida que ninguna fuente acredita.

Qué cierra realmente la actualización a BTCPay Server 2.4.4

Según su propia exposición, el proyecto actúa por dos vías contra la secuencia descrita.

Primero: se acabó la contraseña común. La nueva imagen de LND ya no crea carteras con una contraseña predeterminada compartida. Cada cartera recién generada recibe su propia contraseña aleatoria. Las carteras existentes que aún estén en el valor de fábrica antiguo se migran automáticamente al arrancar. Desaparece así la parte del ataque que se apoyaba en un conocimiento previo.

Segundo: bloqueo en el borde de la red. La instalación en Docker bloquea ya en el proxy inverso incluido las vías no autenticadas para crear y desbloquear la cartera. Por la ruta pública predeterminada, la ventana del reinicio queda cerrada.

Con la 2.4.4 llegaron otros cambios que pueden afectarte en la operación diaria, aunque no guarden relación con el ataque. Los pagos por NFC en el cobro vienen ahora desactivados de fábrica y hay que volver a activarlos en los ajustes de la tienda. Las facturas sin importe se bloquean por defecto. La configuración de Boltcards mediante un lector de tarjetas conectado al ordenador ha desaparecido; en su lugar, BTCPay Server abre la aplicación correspondiente. Quien use la conexión con WHMCS necesita, por un cambio no retrocompatible, la versión 4.0.0 del módulo adicional y una clave de API recién generada. Los usuarios de tienda invitados tienen que aceptar antes su invitación. Y en el módulo de caja ha desaparecido la posibilidad de pasar una dirección de aviso propia por petición; rige la que esté guardada en el módulo.

La instalación estándar en Docker ha dado al mismo tiempo un salto mayor: Bitcoin Core pasa de 29.2 a 31.1 y LND a 0.21.3-beta. La compatibilidad con Bitcoin Knots se ha retirado después de que Knots, según el proyecto, siguiera una cadena que se separó de la principal. Quien emplee Knots de forma deliberada debería leer esto antes de la actualización y no después. A ello se suma una vinculación más estrecha con la máquina anfitriona: en lugar de un acceso SSH amplio, el contenedor de la aplicación solo recibe ya una clave para una lista corta de órdenes de administración permitidas.

Por qué tu propia regla de proxy inverso queda intacta tras la actualización

Aquí está el núcleo, y es la misma frase que el proyecto ya escribió en agosto: una actualización de BTCPay Server no cierra vías de acceso que gestiones al margen de ella. Una redirección en tu propio proxy inverso, un puerto redirigido en el router, un servicio Tor creado por ti — la actualización no conoce nada de eso y no puede retirarlo.

La instrucción del proyecto es por ello inequívoca: no expongas a mano la interfaz LND a la red mediante un proxy inverso propio. Si ya lo has hecho, retira ese acceso y actualiza tu servidor. Ambas cosas, leídas en ese orden, no como alternativa.

Quien ya estuviera expuesto en agosto por una vía propia debería además renovar las credenciales de su nodo. La actualización a 2.4.2 regeneró automáticamente los macaroons de la instalación estándar; para las rutas gestionadas por uno mismo eso no vale. La misma lógica la conoces del caso de la vulnerabilidad de Core Lightning de finales de agosto, que desmenuzamos en este análisis del fallo de Core Lightning: la suposición peligrosa nunca es el agujero en sí, sino la creencia de que un salto de versión resuelve todo lo demás.

El acceso externo a Lightning vuelve, pero solo con activación expresa

Para muchos operadores, la desactivación de agosto fue dolorosa, porque con ella caía también la vía legítima: una cartera de móvil como Zeus manejando el nodo propio desde fuera. El proyecto nunca lo ha negado y en septiembre anunció una vuelta ordenada.

El estado a día de hoy: el 11 de septiembre se incorporó un cambio en el control de rutas que ofrece una posibilidad admitida para el acceso remoto, mientras las interfaces de LND y de Core Lightning siguen desactivadas de fábrica. Esa es la diferencia decisiva respecto a la situación anterior: el acceso existe, pero tienes que activarlo conscientemente, y discurre entonces por la ruta que mantiene el proyecto en lugar de por tu trabajo manual.

En la práctica eso significa para ti: si necesitas acceso remoto, usa el interruptor previsto y no construyas más redirecciones propias. Y aprovecha para comprobar qué cartera de tu teléfono debe tener acceso a tu nodo. Qué carteras de software admiten qué tipos de conexión lo encuentras en la comparativa de carteras de software enlazada más abajo; no todas traen los mismos niveles de permisos, y un acceso remoto con un macaroon limitado es bastante más inofensivo que uno con la llave maestra.

La lista de comprobación para operadores: lo que despachas hoy

Por orden, y da igual que te sientas afectado o no:

1. Determina la versión. La versión en marcha figura en el pie del área de administración. Si aparece algo por debajo de 2.4.4, ese es tu primer movimiento.
2. Actualiza. En una instalación con Docker, por Server Settings › Maintenance › Update. En una instalación gestionada de otro modo, por tu vía habitual.
3. Busca tus propias redirecciones. Repasa tu configuración de proxy y vigila cualquier regla que saque al exterior algo por debajo de /lnd-rest/. Piensa también en los puertos redirigidos del router y en los servicios Tor que hayas creado tú.
4. Elimina las vías que encuentres. No las comentes para dejarlas ahí: sácalas y recarga el servicio.
5. Renueva los permisos si tu nodo fue accesible por una ruta gestionada por ti. Genera macaroons nuevos, invalida los antiguos y vuelve a configurar las conexiones guardadas en las carteras de móvil.
6. Vuelve a montar el acceso remoto si lo necesitas, mediante el ajuste previsto en lugar de con reglas propias.

Si te falta tiempo para despachar con limpieza los puntos tres y cuatro, el consejo del aviso de agosto sigue valiendo en su sentido: un nodo que no es accesible tampoco puede ser rastreado. Mejor unas horas sin acceso remoto que un punto de acceso abierto todo el fin de semana.

Cómo reconoces si tu nodo LND ha sido comprometido

El proyecto publicó para el incidente de agosto una rutina de comprobación que también sirve aquí. Busca en tu nodo pagos que no hayas ordenado. Fíjate en cierres de canal que no hayas iniciado y en contrapartes que no conozcas. Coteja tu saldo on-chain y los saldos de tus canales con tus propios registros. Todo lo que no puedas explicarte es motivo para seguir buscando, no para tranquilizarte.

Una indicación para situar el asunto, y que aquí no cunda el pánico: hasta la fecha nadie ha comunicado una toma de control por la vía observada en septiembre. La comprobación es diligencia, no recuento de daños.

Al margen debe considerarse un tercer incidente que el proyecto revela en el mismo comunicado: el servidor propio para compilar módulos adicionales fue comprometido, algo descubierto el 2 de septiembre. Según la exposición del proyecto, están afectados exclusivamente los desarrolladores de módulos, no sus usuarios. Tras la comprobación, los módulos publicados no habían sido sustituidos por versiones maliciosas y todos los tokens de acceso se renovaron. Las direcciones de correo guardadas eran probablemente consultables; quien esté registrado ahí debería contar con intentos de phishing en las próximas semanas y tratar en consecuencia los mensajes inesperados.

Qué significa el incidente para los comerciantes alemanes que cobran en bitcoin

En Alemania, BTCPay Server se emplea sobre todo entre pequeños comercios, talleres, asociaciones y tiendas en línea que quieren aceptar bitcoin sin intermediario. El atractivo está en que el pago va directo a la cartera propia. No hay ningún prestador de servicios que retenga el saldo mientras tanto.

Ese diseño tiene una cara B que el caso actual pone por delante: donde nadie se interpone, tampoco hay nadie que responda, que bloquee o que reembolse. En un proveedor con custodia, un ataque sería su problema. En tu propio servidor es el tuyo. La responsabilidad de las actualizaciones, de las vías de acceso y del reparto entre saldo de explotación y reserva recae por entero en ti.

De ahí se sigue una regla de explotación sencilla que vale con independencia de cada vulnerabilidad concreta: en el nodo queda solo lo que necesita el tráfico de pagos corriente. Todo lo que exceda migra con regularidad a una custodia que no esté conectada a la red. Quien automatiza esa salida y la ejecuta semanalmente en lugar de trimestralmente limita el daño de cualquier incidente futuro a una suma manejable.

Registro e impuestos: qué exige Hacienda en los pagos con bitcoin

Un punto que en los temas de seguridad suele quedar en el olvido, pero que te saldrá al paso a más tardar en la próxima inspección: si tu empresa acepta bitcoin como pago, la entrada es un ingreso de explotación. Lo determinante es el valor en euros en el momento de la entrada, y ese valor hay que acreditarlo. El plazo de tenencia de un año del artículo 23 de la ley alemana del impuesto sobre la renta, que puede dejar exentas las ventas privadas, no rige para el patrimonio empresarial. Las ganancias y las pérdidas de una venta posterior se quedan en la empresa y discurren por el artículo 15 de esa misma ley.

En el IVA la situación está aclarada desde hace tiempo: el Tribunal de Justicia de la Unión Europea resolvió en el asunto C-264/14 que el cambio de moneda convencional por bitcoin y a la inversa está exento de IVA; el Ministerio Federal de Hacienda alemán lo trasladó a Alemania con un escrito del 27 de febrero de 2018. Tu entrega o tu prestación propiamente dicha sigue siendo imponible al margen de ello, medida en euros.

En la práctica eso significa: necesitas, por cada pago, el momento, el importe en bitcoin, el tipo de cambio en euros aplicado y la procedencia de ese tipo. BTCPay Server guarda esos datos en su facturación y permite exportarlos. Aprovéchalo antes de que una mudanza de servidor o un incidente dejen la base de datos inservible. Que los registros estén sujetos a conservación obligatoria y que el acceso deba seguir siendo posible durante el plazo de conservación se desprende del artículo 147 del código tributario alemán y vale tanto para una base de datos SQL como para un archivador.

Cuándo compensa el nodo propio y cuándo no

Tras dos avisos de seguridad en cinco semanas, la pregunta de si el esfuerzo sigue guardando proporción es legítima. Una respuesta honesta tiene que nombrar ambos lados.

A favor del nodo propio habla que nadie retiene tu dinero, que nadie puede congelarte la cuenta y que no se va ninguna comisión por transacción a un prestador. Para importes pequeños en la red Lightning eso marca una diferencia perceptible, porque un descuento porcentual en una compra de dos euros resultaría desproporcionado.

En contra habla la carga de explotación, y esa es real. Necesitas a alguien que lea los avisos de seguridad, aplique las actualizaciones y documente las vías de acceso. Si esa persona falta en la empresa, un proveedor de pagos con custodia es la elección más honesta pese a sus comisiones. Un nodo propio mal mantenido sale más caro que cualquier comisión, y lo hace exactamente una vez.

Una vía intermedia que funciona bien en la práctica: nodo propio para el día a día con saldo limitado, salidas fijas hacia la custodia en frío y una cita en el calendario que te obligue una vez al mes a leer las publicaciones del proyecto. Todos los avisos de las últimas semanas se habrían visto así a tiempo.

Asegurar BTCPay Server: lo que te llevas de aquí

1. Actualiza a 2.4.4 y elimina tus propias redirecciones de LND. La actualización por sí sola no basta si has construido una vía propia hacia el exterior. En el mismo movimiento, reduce el saldo del nodo a lo que pida la explotación; el resto corresponde a una custodia sin conexión a la red, como la que contrapone nuestra comparativa de carteras de hardware.
2. Vuelve a montar el acceso remoto si lo necesitas. Usa el ajuste previsto en vez de una regla de proxy propia y otorga en ese mismo paso un macaroon con derechos limitados. Qué cartera de móvil domina qué tipo de conexión y qué niveles de permisos lo muestra nuestra comparativa de carteras de software.
3. Asegura tus justificantes de pago antes de tocar el servidor. Exporta los datos de facturación con el momento, el importe y el tipo de cambio en euros aplicado. Quien lo hace de forma continua en lugar de una vez al año encontrará las herramientas adecuadas en nuestro repaso al software fiscal y los rastreadores de cartera.

Las dos fuentes primarias en su literalidad: el anuncio de BTCPay Server 2.4.4 del 8 de septiembre de 2026 y el aviso de seguridad sobre la versión 2.4.2 del 7 de agosto de 2026.

(16 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)