BTCPay Server rastrea los vaciados de hot wallets hasta instalaciones anteriores a la 2.4.2
BTCPay Server pidió a los operadores el 2 de noviembre que apagaran sus instancias tras recibir reportes de vaciados de hot wallets de Bitcoin. El proyecto acotó después el vector de ataque sospechado a las versiones 2.4.1 y anteriores, y afirmó que no tiene reportes creíbles de vaciados en la versión 2.4.7.
Escrito por la redacción de IA de CoinArticle · a partir de 2 fuentes citadas. Cómo trabajamos
Advertencia de apagado y alcance
BTCPay Server, el procesador de pagos de Bitcoin autoalojado y de código abierto, pidió a los operadores el 2 de noviembre que apagaran temporalmente sus instancias tras recibir reportes de barridos no autorizados de hot wallets conectadas. La instrucción inicial, que ejecutaba el script ./btcpay-down.sh, se aplicaba a todos los usuarios mientras el equipo investigaba cómo los atacantes estaban obteniendo acceso.
Una actualización posterior de la respuesta al incidente acotó el vector de ataque sospechado a las instalaciones que ejecutan la versión 2.4.1, publicada el 23 de julio de 2026, o anteriores. El proyecto indicó que no tiene reportes creíbles de vaciados de hot wallets que involucren la versión 2.4.7 y volvió a instar a los operadores a mantener su software actualizado.
Versiones afectadas: relatos contradictorios
Las fuentes difieren en el punto de corte exacto. El aviso del proyecto identifica la versión 2.4.1 y anteriores como el rango afectado. El cofundador Nicolas Dorier, en una declaración aparte el mismo día, dijo que las instalaciones afectadas parecían ejecutar versiones anteriores a la 2.4.2, una descripción más acotada que, en la forma en que se formula el límite, excluye en la práctica a la 2.4.1 del conjunto vulnerable. Los lectores deben tomar el rango de la 2.4.1 y anteriores del aviso oficial como la guía vigente, y tener en cuenta que el planteamiento de Dorier apunta a la misma línea práctica: actualizar más allá de las versiones de punto 2.4.x que precedieron a la 2.4.2.
Dorier también afirmó que los servidores públicos del propio proyecto, que ejecutan la 2.4.7, no fueron atacados. Dijo que el atacante obtuvo un inicio de sesión con nivel de administrador en las instancias afectadas, pero que el equipo aún no ha establecido cómo se obtuvo ese acceso.
Incógnitas y antecedentes
El proyecto no ha revelado cuánta criptomoneda fue sustraída, cuántos servidores fueron comprometidos ni cuántos usuarios han reportado pérdidas. Tampoco ha descrito públicamente la debilidad técnica que permitió las intrusiones.
El episodio sigue a una brecha de seguridad de agosto, cuando BTCPay Server advirtió sobre una vulnerabilidad explotada activamente que podía provocar el robo de fondos y pidió a los usuarios actualizar a la versión 2.4.2 o apagar sus servidores si no podían instalar la corrección. A los usuarios que crean que sus servidores fueron comprometidos se les ha pedido enviar los detalles del incidente y los registros del sistema al contacto de seguridad del proyecto.
Lo que se pide a los operadores
La guía del proyecto es ejecutar la versión más reciente, confirmar la versión instalada y enviar los registros si se sospecha un compromiso. Las hot wallets siguen expuestas cuando los atacantes obtienen control administrativo, ya que pueden iniciar transacciones desde las wallets conectadas; por ello, el hecho de que la causa raíz siga sin publicarse significa que los operadores con versiones antiguas no tienen más detalles específicos de la corrección aparte de la actualización de versión.
Por qué importa
Para los traders
Las pérdidas no están cuantificadas y el proyecto no ha publicado cifras totales, por lo que es poco probable que el impacto en el precio de Bitcoin sea significativo en los próximos días.
Para los inversores
El incidente es una historia de custodia propia y seguridad operativa para una herramienta de pagos de nicho, no un cambio en el perfil de riesgo de la capa base de Bitcoin.
Para los desarrolladores
Cualquier integración que dependa de hot wallets de BTCPay Server debe verificar la versión desplegada y tratar el acceso de nivel administrador como el límite crítico que hay que reforzar.
Este artículo es solo informativo y no constituye asesoramiento financiero. Lee el aviso legal completo.
