Por Canuto  

BTCPay Server atribuye los drenajes de hot wallets a ataques contra instancias antiguas, pero aún no ha precisado las pérdidas ni cómo obtuvieron acceso de administrador.
***

  • La investigación apunta a versiones 2.4.1 y anteriores; el equipo dice no tener reportes creíbles de drenajes en la versión 2.4.7.
  • Los atacantes iniciaron sesión como administradores, aunque BTCPay Server todavía no identifica cómo consiguieron ese acceso.
  • Nicolas Dorier recomendó no mantener en una hot wallet más fondos de los que el operador esté dispuesto a perder.

BTCPay Server investiga robos de hot wallets en instancias desactualizadas

BTCPay Server investiga una serie de ataques en los que intrusos obtuvieron acceso de administrador a servidores antiguos y vaciaron las hot wallets conectadas. El equipo pidió a los operadores apagar sus instancias mientras revisaba el incidente y luego delimitó el riesgo a la versión 2.4.1, publicada el 23 de julio de 2026, y a las anteriores; además, no reportó drenajes creíbles en la versión 2.4.7.

La investigación todavía no ofrece una cifra total de pérdidas ni explica cómo los atacantes consiguieron las credenciales o el acceso administrativo. Según informó BeInCrypto, el fundador Nicolas Dorier confirmó que los intrusos iniciaron sesión como administradores en los servidores afectados, mientras el equipo encontró indicios de vulnerabilidades anteriores a la versión 2.4.2.

Qué ocurrió y qué versiones están en riesgo

El equipo de BTCPay Server dio la alarma a última hora del 1 de noviembre de 2026 y pidió a quienes administran instancias propias que las apagaran hasta que concluyera la investigación. La recomendación inicial buscaba reducir la exposición mientras el equipo evaluaba el alcance de los ataques; una comunicación posterior concretó que el vector afecta a la versión 2.4.1 y a cualquier versión anterior.

La versión 2.4.1 salió el 23 de julio de 2026, y el equipo señaló que no cuenta con informes creíbles de drenajes de hot wallets entre usuarios que ya utilizan la versión 2.4.7. Esa distinción delimita lo que se conoce hasta ahora, pero no equivale a una garantía de seguridad absoluta ni resuelve por sí sola el caso de quienes corren versiones antiguas.

La investigación identificó rastros de vulnerabilidades anteriores a la versión 2.4.2, aunque BTCPay Server aún no ha establecido cómo los atacantes llegaron a las sesiones administrativas. Dorier indicó que los intrusos iniciaron sesión como administradores en los servidores afectados; el dato describe el nivel de acceso alcanzado, pero no revela si se obtuvo mediante una vulnerabilidad concreta, credenciales comprometidas u otro mecanismo.

El equipo no ha divulgado cuántos operadores resultaron afectados ni el valor de los fondos sustraídos. Por eso, el alcance financiero sigue sin conocerse y las advertencias públicas se centran, por ahora, en el rango de versiones y en la necesidad de apagar las instancias antiguas durante la investigación.

Por qué una hot wallet eleva el riesgo

BTCPay Server es un procesador de pagos gratuito y de código abierto que los comerciantes pueden alojar por cuenta propia para aceptar Bitcoin. En una configuración con hot wallet, el servidor guarda directamente las claves privadas y puede enviar fondos sin que el operador tenga que firmar cada transacción por separado.

Ese diseño facilita la operación de pagos, pero también concentra en el servidor una capacidad sensible: mover los fondos vinculados a las claves que almacena. Si una persona no autorizada logra acceso de administrador, puede llegar a controlar las funciones del sistema y, en esa configuración, disponer de las monedas conectadas, tal como refleja el incidente que investiga el equipo.

La diferencia importa porque una instancia autoalojada pone parte de la responsabilidad operativa en quien la administra. El software abierto y gratuito no implica que las actualizaciones se instalen solas ni elimina el riesgo asociado a mantener expuestos sistemas antiguos; en este caso, el equipo relacionó los ataques con versiones anteriores a la 2.4.2.

Dorier, fundador de BTCPay Server, advirtió que los usuarios no deberían guardar en una hot wallet más fondos de los que estén dispuestos a perder y afirmó que no pueden garantizar que algo así no vuelva a ocurrir. El comentario no presenta el episodio como una vulnerabilidad ya resuelta para todos los casos, sino como una advertencia sobre los límites de seguridad de cualquier servidor que conserva claves privadas.

El antecedente del parche de agosto y la respuesta

El episodio actual se suma a otro robo ocurrido al menos dentro de los tres meses previos, también contra fondos de instancias de BTCPay Server que utilizaban versiones anteriores a la 2.4.2. En agosto, esa versión corrigió una falla crítica que permitía a atacantes remotos apoderarse de credenciales de nodos Lightning y vaciar las billeteras conectadas.

La fuente indica que aquella falla ya estaba siendo explotada activamente cuando se conoció el parche. Sin embargo, la información disponible no establece que el incidente actual sea exactamente el mismo ataque ni confirma que el fallo de Lightning explique todos los drenajes investigados; el equipo solo ha dicho que encontró rastros de vulnerabilidades anteriores a la 2.4.2.

Algunos proveedores de alojamiento también reaccionaron ante el riesgo. El equipo señaló que LunaNode y otros servicios podrían haber apagado automáticamente instancias de clientes para bloquear ataques contra versiones antiguas, aunque presentó esa posibilidad con cautela y no como una medida confirmada para todos los proveedores o usuarios.

Como referencia sobre el estado de las versiones, Dorier dijo que él mismo ejecuta la 2.4.7 con una hot wallet. Esa decisión personal no contradice su advertencia de limitar los fondos almacenados: el equipo no reportó drenajes creíbles en la versión actual, pero tampoco prometió que ninguna instalación futura pueda sufrir un ataque.

Qué deja al descubierto el caso para los operadores

La investigación pone el foco en el mantenimiento de sistemas que gestionan pagos y claves, además de en la vulnerabilidad técnica que pudo permitir los accesos. El equipo relacionó el vector con versiones antiguas y pidió detener las instancias afectadas, mientras el antecedente de agosto muestra que un parche disponible no protege a quienes continúan usando software desactualizado.

La historia también ilustra una tensión propia del autoalojamiento: el operador conserva control sobre su infraestructura, pero debe atender las actualizaciones y decidir cuántos fondos expone a un servidor conectado. En una hot wallet, las claves permanecen disponibles para que el sistema pueda procesar movimientos, por lo que el acceso administrativo no autorizado puede tener consecuencias directas para los fondos.

Por ahora, los datos públicos no permiten determinar cuántas personas perdieron Bitcoin, cuánto dinero salió de las billeteras ni cuál fue el método inicial de intrusión. La investigación podría precisar esos puntos, pero la información divulgada hasta ahora solo confirma accesos administrativos, un alcance de versiones hasta la 2.4.1 y la ausencia de reportes creíbles de drenajes en la 2.4.7.

El incidente encaja además en una advertencia más amplia sobre nodos de Bitcoin sin parchear: Core Lightning también alertó recientemente que los atacantes están apuntando a instalaciones desactualizadas. Aunque ambos casos no deben confundirse ni darse por vinculados, comparten una lección operativa concreta: instalar una instancia una vez y dejarla sin actualizar puede convertir una herramienta útil en un punto débil.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados