# El robo a BTCPay Server sacó 1,62 millones en 682 barridos > Un fallo corregido en agosto sirvió para vaciar monederos calientes en instancias con la 2.4.1 o anteriores. Bitquery contó 682 barridos y 1,62 millones. > Por José Maldonado · Ciberseguridad · 2026-11-06 BTCPay Server confirmó el 1 de noviembre que estaban robando bitcoin y litecoin de monederos calientes en instalaciones con la versión 2.4.1 o anteriores. La corrección llevaba casi tres meses publicada, desde el 2.4.2 que salió el 7 de agosto, y el proyecto lo admitió en su [aviso de seguridad](https://blog.btcpayserver.org/btcpay-server-security-incident-2-4-1-and-earlier/) con una frase poco habitual: le habría gustado hacer más para avisar a quienes seguían en versiones antiguas. El análisis on-chain de Bitquery puso cifras al incidente tres días después: 1,62 millones de dólares en 18,38 bitcoin y 3.405 litecoin, retirados en 682 barridos distintos. El 87 % del dinero salió en una sola oleada el 1 de noviembre entre las 14:12 y las 22:16 UTC, y el barrido más antiguo que los investigadores pudieron fechar ocurrió el 30 de octubre, menos de un día después de que el proyecto publicara la versión 2.4.7. La historia sirve para algo más que para contar un robo. BTCPay existe precisamente para que un comercio cobre en cripto sin depender de un intermediario, así que el incidente deja al descubierto el reverso de la autocustodia: si tú guardas las claves, tú administras el servidor que las guarda. La diferencia no es retórica, porque un exchange puede congelar tus fondos mientras un servidor sin actualizar los pierde sin avisar a nadie. ## ¿Qué versiones quedaron expuestas? El aviso del proyecto es preciso con el alcance. Los ataques se dirigieron a servidores con la versión 2.4.1, publicada el 23 de julio de 2026, o cualquier anterior. La 2.4.2, del 7 de agosto, corregía la vulnerabilidad, y los atacantes usaron un método distinto para explotar el mismo fallo, lo que en la práctica significa que aplicar el parche de agosto cerraba la puerta conocida y dejaba abierta la que ahora se ha usado. Desde entonces el proyecto publicó la 2.4.4, la 2.4.5 y la 2.4.7. Esta última corrige una vulnerabilidad crítica y varias de severidad media que encontró el escáner de código abierto de Anthropic. Las instancias que estaban en la 2.4.2 o superior cuando llegó el aviso del 1 de noviembre no mostraron impacto, y el proyecto insiste en que no tiene constancia creíble de robos en la 2.4.7. Los monederos con las claves de gasto fuera del servidor, como los de hardware, quedaron al margen. Ese detalle es la mejor guía de diseño que deja el incidente, y el propio proyecto lo convirtió en recomendación permanente: cobrar en un monedero cuyas claves no viven en la misma máquina que la tienda. ## Vaciando un monedero sin tocar la clave Un monedero caliente guarda en el propio servidor las claves necesarias para gastar. Esa decisión es cómoda, porque permite pagar comisiones, consolidar saldos y mover fondos sin intervención manual, y es la razón por la que un fallo en la aplicación se convierte en un robo de dinero y no en una fuga de datos. El proyecto no ha publicado el detalle técnico del vector, y conviene no inventarlo. Lo que sí está documentado es el resultado: direcciones de depósito vaciadas, transferencias agrupadas hacia dos direcciones publicadas por el equipo, una de bitcoin y otra de litecoin, y un patrón de retiradas que se repite cientos de veces con importes muy distintos. Ese patrón importa para la investigación. Casi la mitad de los barridos movió menos de 100 dólares, mientras que 32 operaciones concentraron el 77 % del dinero. Un atacante que automatiza el barrido de todas las carteras que encuentra produce exactamente ese perfil, con muchas operaciones pequeñas que no llaman la atención y unas pocas grandes que justifican el trabajo. Los proveedores de alojamiento también movieron ficha. LunaNode y otros dieron de baja instancias como precaución, algo que el proyecto agradeció públicamente y que explica por qué algunos comercios se encontraron la tienda caída sin haber hecho nada. ## Actualizar no borra el acceso que ya existe El aviso del proyecto es explícito en el punto que más se salta la gente: actualizar no elimina el acceso que un atacante ya pudo obtener. Un saldo intacto tampoco descarta un ataque anterior, porque el atacante pudo copiar claves y esperar. Por eso la recomendación para quien estuvo en la 2.4.1 o anterior es reconstruir, y no solo parchear. El procedimiento que describe el equipo tiene cuatro pasos y ninguno es opcional: crear un monedero nuevo con una semilla nueva en un dispositivo de confianza, barrer lo que quede del monedero caliente, apagar el servidor viejo conservando registros, y levantar una máquina nueva con la última versión sin restaurar el sistema antiguo encima. El paso que más se incumple es el de la semilla. Reutilizar la semilla vieja en el servidor nuevo devuelve el problema al punto de partida, y eso incluye las copias de seguridad que muchos administradores restauran por costumbre. La rotación de credenciales alcanza hosting, SSH, aplicaciones, API y Lightning, siempre desde un dispositivo distinto del comprometido. El [análisis técnico del incidente](https://www.0xcert.com/advisory/0xCERT-2026-0302) recoge la cronología completa y las dos direcciones de destino publicadas. ## La autocustodia también es administración de sistemas La conversación sobre autocustodia suele plantearse como una elección entre confiar en un exchange o confiar en uno mismo, y el incidente de BTCPay muestra que la segunda opción tiene requisitos que no aparecen en la comparativa. Un servidor hay que actualizarlo, vigilarlo y reconstruirlo cuando toca, y esas tareas no las hace la convicción ideológica. El paralelismo con otros incidentes de la misma semana es directo. El backdoor que se sirvió por el [canal de actualizaciones de cPGuard](https://observatorioblockchain.com/ciberseguridad/cpguard-backdoor-canal-actualizacion-hosting/) y el paquete envenenado de [LiteLLM 1.107.0](https://observatorioblockchain.com/ciberseguridad/litellm-107-0-comprometido-supply-chain/) comparten la misma raíz: alguien con acceso al mecanismo de distribución y muchos usuarios que instalan sin comprobar. Para un comercio que cobra en cripto, la lección práctica cabe en tres decisiones. Mantener en el monedero caliente solo el saldo de la operativa diaria, sacar el resto a un monedero con claves fuera del servidor, y tratar la actualización de la aplicación como parte de la contabilidad y no como una tarea de mantenimiento que se puede aplazar hasta el viernes. La lista completa de medidas para un equipo pequeño está en [las nueve capas de defensa para pymes](https://observatorioblockchain.com/ciberseguridad/ciberseguridad-pymes-nueve-capas-defensa/).