El proyecto ha publicado una actualización de emergencia porque hay un fallo siendo explotado ahora mismo, con nodos Lightning vaciados en instalaciones reales. Aquí tienes por qué es urgente, cómo actualizar paso a paso, y cómo revisar si alguien ha estado dentro de tu servidor. Incluye el registro completo de nuestra propia actualización.
Si tienes un BTCPay Server, actualiza a la 2.4.2 antes de seguir leyendo. No es una actualización de mantenimiento. El propio proyecto ha pedido a quien no pueda parchear de inmediato que apague el servidor hasta poder hacerlo. La fuente vinculante es el aviso oficial; esta guía lo traduce y lo ordena, no lo sustituye.
BTCPay Server es el software libre que mucha gente usa para cobrar en Bitcoin sin intermediarios: lo instalas en tu propio servidor, genera las facturas, vigila la cadena y te avisa cuando el pago entra. No hay pasarela, no hay comisión de terceros, no hay nadie que pueda congelarte los cobros. Esa es su gracia — y también el motivo por el que un fallo en él se paga en bitcoins, no en disculpas.
El 7 de agosto de 2026 el proyecto publicó la versión 2.4.2 con un aviso muy poco habitual por lo directo:
«This release contains fix of a critical vulnerability that is being actively exploited. You need to update as fast as you can.»
— Notas de la versión 2.4.2
Tres cosas que conviene leer despacio de esa frase:
Los medios especializados han reportado nodos Lightning vaciados en instalaciones de terceros, con casos públicos como el fabricante de monederos Foundation y la revista Citadel21. La divulgación responsable la hizo el Bitcoin Red Team.
No se ha publicado. Y hay una confusión circulando que merece aclararse, porque puede llevar a alguien a pensar que no le afecta:
El changelog de la 2.4.2 incluye la corrección de un bypass de doble factor a través de la autenticación Basic de la API Greenfield. Es un fallo real y está arreglado. Pero el proyecto ha aclarado que ese NO es el fallo que se está explotando activamente. Son dos cosas distintas que viajan en la misma versión.
Que no se publique el detalle del vector explotado mientras quedan servidores sin parchear es la práctica correcta: publicarlo sería entregar el guion a quien todavía no lo había encontrado. El detalle técnico suele salir semanas después, cuando el parche ya está extendido.
La consecuencia práctica para ti es incómoda pero clara: no puedes descartar que te afecte razonando sobre el fallo, porque no sabes cuál es. Solo puedes parchear y revisar.
En InfoBitcoin cobramos las suscripciones PRO con nuestro propio BTCPay Server, en un servidor nuestro. No usamos pasarela de terceros: si predicamos autocustodia e infraestructura propia, lo mínimo es aplicárnoslo. Eso significa también que este aviso nos apuntaba directamente.
Veníamos de la 2.3.9, así que arrastrábamos además los cambios de la 2.4.0 y la 2.4.1. Este fue el registro real, en horario UTC del 8 de agosto de 2026:
btcpay-update.sh. Descarga de imágenes y reinicio ordenado de contenedores.Interrupción total del servicio: unos 3 minutos, repartidos entre el backup y el reinicio. Merece la pena decirlo porque el miedo a la caída es la excusa habitual para posponer un parche urgente, y aquí la caída es trivial.
Administración del servidor → Mantenimiento → Actualizar. Al terminar, comprueba la cadena de versión en el pie de página: debe decir 2.4.2.
Ojo con una trampa: si tu instalación tiene BTCPAY_ENABLE_SSH=false (lo habitual si te preocupaba dar al contenedor acceso al servidor anfitrión), el botón de actualizar de la interfaz no funciona. Tendrás que ir por consola. Es nuestro caso.
El orden importa. No te saltes el backup:
# 1. Copia de seguridad (volcado de base de datos + configuración)
sudo bash /opt/btcpayserver-docker/btcpay-backup.sh
# 2. Actualizar
sudo btcpay-update.sh
# 3. Comprobar la versión que ha quedado corriendo
sudo docker ps --format "{{.Names}}\t{{.Image}}" | grep -E "btcpayserver|nbxplorer"El script hace el git pull del repositorio de despliegue, regenera el fichero de composición, descarga las imágenes nuevas y reinicia los contenedores en orden. Deberías terminar con btcpayserver 2.4.2 y nbxplorer 2.6.10.
Actualiza NBXplorer también. La 2.6.10 venía explícitamente recomendada junto al parche. Si actualizas por consola con el script oficial, viene solo.
Dos avisos por experiencia propia:
docker image prune -af) si tienes BTCPAY_UPDATE_CLEAN=true. Libera espacio — a nosotros 3,12 GB — pero borra imágenes sin usar de todo el servidor, no solo de BTCPay. Si compartes la máquina con otros servicios, tenlo presente.Parchear cierra la puerta. No te dice si alguien había entrado antes. Como el fallo llevaba tiempo explotándose, esta parte no es opcional.
Revisa estas cinco cosas, en este orden:
| Qué mirar | Dónde | Qué esperas ver |
|---|---|---|
| Usuarios registrados | Administración del servidor → Usuarios | Solo los tuyos. Cualquier cuenta que no reconozcas es una alarma. |
| Claves de API | Ajustes de cuenta → Claves de API | Solo las que creaste tú, y que puedas nombrar una por una. |
| Pull payments | Tienda → Pull payments | Ninguno, si no los usas. Es el mecanismo natural para sacar fondos. |
| Payouts | Tienda → Payouts | Ninguno que no hayas autorizado. |
| Cartera y canales | Tienda → Cartera / Lightning | Saldo y transacciones que cuadren con tu contabilidad. |
Si prefieres consultarlo directamente contra la base de datos, en una instalación Docker estándar:
sudo docker exec generated_postgres_1 psql -U postgres -d btcpayservermainnet \
-c 'SELECT "UserName","Created","TwoFactorEnabled" FROM "AspNetUsers";' \
-c 'SELECT "Id","Label" FROM "ApiKeys";' \
-c 'SELECT count(*) FROM "PullPayments";' \
-c 'SELECT count(*) FROM "Payouts";'En nuestro caso: un solo usuario (el nuestro, con doble factor activado), una sola clave de API (la del panel de suscriptores), cero pull payments y cero payouts. Sin rastro de intrusión. No teníamos Lightning configurado, que es por donde se ha materializado el robo en las instalaciones afectadas.
Si encuentras algo que no reconoces, no lo borres todavía. Primero corta el acceso: revoca las claves de API, cambia la contraseña, saca los fondos a una dirección que controles desde un dispositivo limpio. Y conserva los registros — si borras las huellas, te quedas sin saber qué pasó ni por dónde.
La 2.4.2 trae un cambio de comportamiento que conviene conocer antes de que te sorprenda:
La autenticación Basic de la API Greenfield (usuario y contraseña) queda deshabilitada por defecto cinco minutos después de crear la cuenta. Se puede reactivar de forma explícita desde los ajustes de la cuenta o por API.
Si tienes algún script, integración o tienda que se autentique contra tu BTCPay con usuario y contraseña, dejará de funcionar. Si usa una clave de API — que es lo normal y lo recomendado — no le afecta. El propio proyecto indica que no le consta ningún usuario impactado, precisamente porque la autenticación por clave es la práctica generalizada.
Nosotros lo verificamos antes de dar la actualización por buena: nuestro panel de suscriptores se autentica con clave de API y siguió respondiendo con normalidad.
Saltar dos versiones menores significa que además del parche entran unos cuantos cambios. Los que más se notan:
| Versión | Lo relevante |
|---|---|
| 2.4.2 7 ago 2026 | Parche de la vulnerabilidad crítica. Corrección del bypass de 2FA vía Greenfield Basic. Límite de tasa en creación pública de facturas. Mejoras en firma y finalización de PSBT multifirma (compatibilidad con HWI y firmware Jade recientes). |
| 2.4.1 23 jul 2026 | Importación de etiquetas BIP-329. Comentarios de factura editables. Zona horaria configurable en filtros de fecha. Interfaz adaptada a idiomas de derecha a izquierda. Soporte de tarifas por debajo de 1 sat/vbyte. |
| 2.4.0 25 jun 2026 | Carteras multifirma. Autenticación con passkeys. Búsqueda global. Permisos granulares de cartera. Impuestos en el TPV. Rupturas: se retiran LNBank, Lightning Charge y la integración obsoleta de Shopify Scripts; los plugins de Boltcards y Shopify v2 requieren actualización. |
De todo lo retirado en la 2.4.0, revisa especialmente si usabas LNBank o Lightning Charge: ahí sí tienes trabajo de migración por delante.
Aquí está lo que de verdad hay que llevarse de este incidente, y aplica tengas el software que tengas.
Cuando configuras una tienda en BTCPay puedes hacerlo de dos formas:
| Cartera caliente | Solo lectura (xpub) | |
|---|---|---|
| Dónde está la clave privada | En el servidor | Fuera del servidor, en tu cartera fría |
| Puede recibir pagos | Sí | Sí |
| Puede gastar | Sí | No |
| Si comprometen el servidor | Se pueden llevar el saldo | Ven tus cobros; no pueden mover nada |
Para cobrar no necesitas una cartera caliente. Configurando la tienda con la clave pública extendida (xpub) de una cartera fría, BTCPay genera las direcciones, vigila la cadena y detecta los pagos igual de bien — pero no tiene con qué firmar una transacción de salida. Un atacante que entre en el servidor se encuentra con la contabilidad, no con el dinero.
Solo necesitas cartera caliente si haces reembolsos automáticos o pagos salientes desde el propio servidor. Si tu caso es cobrar suscripciones o pedidos, el modo solo lectura te sobra — y es exactamente el escenario en el que un fallo como este no te cuesta nada.
El mismo razonamiento vale para Lightning: un nodo necesita claves calientes para funcionar, no hay forma de evitarlo. Por eso la regla práctica es tratar el saldo de los canales como caja del negocio, no como ahorro: lo justo para operar, barriendo con regularidad hacia almacenamiento en frío. Los nodos vaciados en este incidente lo fueron porque tenían dentro más de lo que necesitaban tener.
📘 Relacionado: qué es una wallet fría · autocustodia · qué es un nodo · cómo montar tu propio nodo con Bitcoin Core · el fallo de entropía de Coldcard.
Es tentador sacar la conclusión perezosa: «para esto, mejor una pasarela de terceros». Guardemos la proporción.
Autoalojar tu cobro te quita intermediarios y te da control real. A cambio te entrega una responsabilidad concreta y perfectamente asumible: estar al día. No hace falta ser administrador de sistemas para eso. Hace falta:
La alternativa —delegar en un tercero— no elimina el riesgo, lo traslada. Ese tercero también tiene vulnerabilidades, y cuando le pasa algo tú te enteras después, no puedes hacer nada, y además puede congelarte los cobros por motivos que no tienen que ver con la seguridad. Aquí, en cambio, el aviso salió, el parche existía el mismo día y aplicarlo costó tres minutos de caída.
Sí, hay que actualizar igual. El robo reportado se ha producido vaciando nodos Lightning, pero eso describe cómo se ha materializado el daño en las víctimas conocidas, no el alcance del fallo. Y si tu cartera onchain es caliente, la clave privada está en el servidor.
No. La explotación estaba activa cuando se publicó el aviso, y ahora hay además mucha más gente mirando. Si de verdad no puedes parchear hoy, la recomendación del propio proyecto es apagar el servidor mientras tanto.
Falta lo importante: revisar si alguien había entrado antes. Usuarios, claves de API, pull payments, payouts, saldos. Está en la sección 5 de esta guía.
En nuestro caso, cuatro minutos en total con backup incluido, y unos tres de interrupción real. Es un servidor modesto con un nodo podado. Con un nodo completo el reinicio puede alargarse algo más, pero no cambia el orden de magnitud.
Por eso el backup va primero. Con el volcado de la base de datos y los volúmenes de configuración puedes volver al estado anterior. Eso sí: volver a una versión vulnerable solo tiene sentido como medida temporal y con el servidor aislado de Internet.
A fecha de publicación de esta guía no hay detalle técnico público del fallo explotado, y no aparece publicado en los avisos de seguridad del repositorio. Es deliberado, para no facilitar el trabajo a los atacantes mientras quedan servidores sin parchear.
Los incidentes de seguridad con impacto real en tus bitcoins entran en nuestro radar diario y los contamos en cristiano, sin alarmismo y sin vender nada.
Únete gratis al canal →
· BTCPay Server — notas de las versiones 2.4.0, 2.4.1 y 2.4.2
· BTCPay Server — aviso oficial en X
· Decrypt — BTCPay warns critical flaw is under active attack
· Crypto Briefing — BTCPay Server warns of critical vulnerability
· The Crypto Times — critical flaw that risks Bitcoin funds
Esta guía resume información pública a 8 de agosto de 2026 y remite en todo momento a los avisos oficiales del proyecto, que son la fuente vinculante y pueden actualizarse. Los tiempos y comandos descritos corresponden a nuestra propia instalación; adapta las rutas y nombres de contenedor a la tuya. Contenido informativo: no es asesoramiento financiero ni sustituye a una revisión técnica de tu configuración.