El ransomware ya ataca Proxmox directamente — y primero borra tus backups

Broadcom cambió los precios de VMware y muchas empresas se fueron. Se retiraron las licencias perpetuas, el licenciamiento por socket pasó a ser por núcleo y, en abril de 2025, la compra mínima pasó de 16 núcleos a 72 — un salto de 4.5x solo en el mínimo. Empresas medianas con diez o veinte hosts empezaron a ver renovaciones que pasaban de treinta o cincuenta mil al año a unos cientos de miles. Gartner prevé que en 2028 alrededor del 70% de los clientes empresariales de VMware habrán trasladado al menos la mitad de sus cargas de trabajo a otro lugar.

Para las pequeñas y medianas empresas, ese otro lugar ha sido muy a menudo Proxmox VE. Es capaz, es open source, funciona en hardware que ya tienes y la conversación sobre licencias desaparece.

Los atacantes leen el mismo mercado.

La amenaza ya no es genérica

Durante años, el ransomware que afectaba a un hipervisor era ransomware que casualmente se encontraba con un hipervisor. Cifraba archivos, y algunos de esos archivos eran imágenes de disco. Proxmox era un daño colateral.

Eso ha cambiado. Los investigadores de seguridad de Halcyon documentaron una variante para Linux de la familia de ransomware Pay2Key que fue diseñada desde cero para atacar entornos Proxmox, detectada por primera vez a finales de agosto de 2025. El FBI, la CISA y el DoD Cyber Crime Center evaluaron conjuntamente Pay2Key como una operación de información iraní. La campaña renovada no era un proyecto secundario: los investigadores contabilizaron al menos 51 pagos de rescate confirmados en un periodo de cuatro meses, por un total de más de cuatro millones de dólares.

Lo que hace que merezca la pena prestar atención a esta variante no es el cifrado. Es que el malware habla Proxmox.

No lucha contra la plataforma. Usa las propias herramientas de la plataforma:

• Detiene tus cargas de trabajo con tus propios comandos. qm stop --skiplock para las máquinas virtuales, pct stop --skiplock para los contenedores. El flag --skiplock existe para que los administradores puedan saltarse las propias protecciones de concurrencia de Proxmox. El malware lo usa exactamente para eso.
• Desactiva la protección de tus backups a través de la API. Antes de borrar nada, ejecuta pvesh set /nodes//storage//content/ --protected 0. No necesita burlar el flag de protección. Simplemente lo desactiva, igual que lo harías tú.
• Después cifra lo que queda. Imágenes de disco de las VMs (qcow2, vma, vmdk), bases de datos (sql, mdf, mdb) y archivos de backup (bak, img, backup), usando ChaCha20 con claves por archivo envueltas en Curve25519.

Hay una buena noticia enterrada en el análisis: el malware necesita root y termina inmediatamente si no lo tiene. Todo lo que sigue depende de ese hecho.

La frase que merece la pena releer

Si tu plan contra el ransomware es el flag "protected" de tus backups de Proxmox, no tienes un plan contra el ransomware.

Ese flag es un seguro contra el error humano — evita que borres por accidente, a medianoche, el backup del mes pasado. Nunca fue un control frente a un adversario, y este malware demuestra por qué: todo lo que un administrador puede activar o desactivar a través de la API, un atacante con root puede activarlo o desactivarlo a través de la misma API.

Es el error de concepto más común que encontramos en entornos Proxmox. Los equipos señalan los backups protegidos en el mismo host, o en un recurso compartido NFS en el que el host puede escribir, y los presentan como su garantía de recuperación. No son una garantía de recuperación. Están dentro del radio de impacto.

La otra puerta: escapar de la VM invitada

La segunda cosa que cambió en 2026 es la propia frontera del hipervisor.

CVE-2026-64561, apodada *Zapscape*, es un use-after-free en la shadow MMU de KVM en x86 — la capa de virtualización sobre la que está construido Proxmox. Durante el tratamiento de fallos de página provocados por la VM invitada, KVM puede recuperar páginas de la MMU e invalidar una shadow root que la ruta de gestión del fallo todavía está usando y, como esa ruta no vuelve a comprobarlo, la ejecución continúa bajo una raíz invalidada. La consecuencia práctica es contundente: alguien con root dentro de una sola VM puede, en las condiciones adecuadas, obtener root en el host — y, por tanto, sobre todas las demás VMs de ese host.

El código defectuoso se introdujo en 2020 y se corrigió upstream en Linux el 21 de julio de 2026. Tiene una puntuación base CVSS 3.1 de 7.0.

Lo que plantea la única pregunta que importa: ¿es el kernel de tu host más reciente que esa corrección?

En muchos entornos la respuesta honesta es "nadie lo ha comprobado". Y ese vacío es el verdadero tema de este artículo.

Es un problema de migración, no un problema de Proxmox

Proxmox no es menos seguro que lo que dejaste. Es una plataforma bien diseñada, con un equipo serio detrás.

El riesgo viene de cómo llegaron las organizaciones. Una migración impulsada por una renovación de licencias es una migración con fecha límite, y las fechas límite producen un conjunto predecible de atajos:

• El modelo operativo se trasladó sin cambios. El entorno antiguo lo administraba a través de vCenter un equipo que nunca necesitó disciplina de parcheo en Linux, porque ESXi era un appliance. Proxmox es Debian. Tiene un gestor de paquetes, un kernel y una carga de mantenimiento que ahora es tuya.
• La interfaz de gestión acabó siendo accesible. La interfaz web quedó expuesta, o detrás de una VPN con credenciales compartidas, para poder terminar la migración desde casa. Nadie volvió a revisarlo.
• Los backups se reprodujeron, no se rediseñaron. La nueva configuración replica la programación y la retención antiguas, y guarda los datos en un almacenamiento en el que el hipervisor puede escribir — que es precisamente el diseño contra el que se escribió Pay2Key.
• Nadie es responsable del parcheo. En el mundo VMware, las actualizaciones eran un evento con una ventana de cambios. En Proxmox son un martes cualquiera. Si nadie tiene ese martes en su calendario, el kernel del host se queda meses atrás y nadie se da cuenta hasta que un aviso de seguridad lo menciona.

Nada de esto es negligencia. Es lo que ocurre cuando la infraestructura cambia más deprisa que el modelo operativo que la rodea.

Lo que realmente te protege

Aproximadamente por orden de lo que te aporta por cada hora invertida:

• Pon una copia de tus backups fuera del alcance de un host comprometido. Externa, inmutable o basada en pull — lo importante es que el hipervisor no tenga credenciales que puedan borrarla. Si root en el host puede llegar a tu última copia buena, estás a una credencial de no tener ninguna.
• Restaura algo. Este mes. Un backup sin probar es una hipótesis. Restaura una VM real en un entorno aislado y cronométralo, para que, cuando importe, sepas que funciona y cuánto tiempo estarás sin servicio.
• Parchea el kernel, no solo los paquetes. apt upgrade en Proxmox no te lleva necesariamente a un kernel nuevo, y un kernel con live patching o fijado puede quedarse atrás sin que nadie lo note. Compara el kernel en ejecución con los avisos de seguridad que importan — Zapscape es el ejemplo actual más evidente.
• Saca la interfaz web de internet. Los planos de gestión deben estar en una red separada, detrás de MFA, con cuentas nominales. La interfaz de Proxmox en una IP pública es una invitación, y los escáneres la encuentran en cuestión de horas.
• Da a la API el mínimo privilegio que funcione. Proxmox tiene un sistema de roles de verdad y tokens de API con permisos granulares. Los trabajos de backup y la monitorización no necesitan permisos de administrador. El malware necesita root; cada cuenta que no lo tiene es una puerta que sigue cerrada.
• Crea alertas para las señales delatoras. Apagados con --skiplock que no programaste. El flag protected de un backup que se desactiva. Paradas masivas de VMs fuera de una ventana de cambios. Son señales inequívocas y, en la mayoría de los entornos, nada las vigila.
• Haz que alguien lo intente. Un test de penetración encuentra la interfaz de gestión expuesta, la credencial compartida y el host olvidado que un inventario en papel nunca saca a la luz.

Dónde encaja Privum

Operamos infraestructura de producción para clientes de toda Europa, y una parte cada vez mayor de las consultas que recibimos es exactamente esto: un entorno que salió de VMware deprisa y al que no se le ha dado el modelo operativo que ahora necesita.

En concreto, el trabajo suele ser:

• Una evaluación honesta de lo que está realmente expuesto. Nuestra área de ciberseguridad realiza tests de penetración externos y revisiones de hardening, e informa de lo que es accesible, no de lo que dice el diagrama. Publicamos un ejemplo anonimizado de una de ellas para que veas la forma del resultado antes de comprometerte.
• Un diseño de backup y recuperación que sobreviva a un host comprometido. Backup y recuperación ante desastres es la parte de todo esto que la gente aplaza y después lamenta. La pregunta de diseño no es con qué frecuencia haces backup; es quién puede borrarlo.
• Alguien vigilando a la hora en que esto ocurre. Los operadores de ransomware no trabajan en horario laboral. Nuestro NOC 24/7 cubre la franja en la que nadie de tu equipo está despierto, que es precisamente la franja para la que se escribió este malware.
• La disciplina Linux que ahora exige la plataforma. Consultoría Linux y trabajo de infraestructura — cadencia de parches, baselines de hardening, segmentación de red y asegurarse de que lo que te mantiene parcheado sea un proceso y no una persona que se acuerda.

No te vamos a decir que abandones Proxmox. Para la mayoría de las empresas que nos consultan, fue la decisión correcta y el ahorro fue real. Pero el ahorro en licencias y el modelo operativo son dos decisiones distintas, y muchos entornos solo tomaron la primera.

En resumen

El ransomware que entiende tu hipervisor ya no es hipotético. Detiene tus VMs con tus propios comandos, desactiva la protección de tus backups a través de tu propia API y después cifra las imágenes. Por otro lado, una vulnerabilidad de KVM corregida en julio de 2026 significa que una sola VM invitada comprometida puede, en las condiciones equivocadas, llevarse el host por delante.

Ambas cosas tienen la misma respuesta, y no es un producto. Es saber cómo es realmente tu entorno, mantenerlo parcheado y tener una copia de tus datos en algún lugar al que un host comprometido no pueda llegar.

Si no tienes claro en qué punto estás en esos tres aspectos, habla con nuestro equipo. Una evaluación breve es bastante más barata que la alternativa, y las empresas que pagaron esos cuatro millones de dólares también estaban bastante seguras de que todo iba bien.