Ransomware Now Targets Proxmox Directly — And It Deletes Your Backups First

Broadcom repriced VMware and a lot of companies left. Perpetual licences were withdrawn, per-socket became per-core, and in April 2025 the minimum purchase went from 16 cores to 72 — a 4.5x jump on the floor alone. Mid-market shops running ten or twenty hosts started seeing renewals go from thirty or fifty thousand a year to a few hundred thousand. Gartner expects that by 2028 around 70% of enterprise VMware customers will have moved at least half their workloads somewhere else.

For small and mid-sized companies, the somewhere else has very often been Proxmox VE. It is capable, it is open source, it runs on hardware you already own, and the licence conversation disappears.

Attackers read the same market.

The Threat Is No Longer Generic

For years, ransomware that hit a hypervisor was ransomware that happened to find a hypervisor. It encrypted files, and some of those files were disk images. Proxmox was collateral damage.

That has changed. Security researchers at Halcyon documented a Linux variant of the Pay2Key ransomware family that was built from the ground up to attack Proxmox environments, first detected in late August 2025. Pay2Key was jointly assessed by the FBI, CISA and the DoD Cyber Crime Center as an Iranian information operation. The renewed campaign was not a side project: researchers counted at least 51 confirmed ransom payments over a four-month stretch, totalling more than four million dollars.

What makes this variant worth paying attention to is not the encryption. It is that the malware speaks Proxmox.

It does not fight the platform. It uses the platform's own tools:

• It stops your workloads with your own commands. qm stop --skiplock for virtual machines, pct stop --skiplock for containers. The --skiplock flag exists so administrators can override Proxmox's own concurrency protections. The malware uses it for exactly that.
• It disarms your backup protection through the API. Before deleting anything, it calls pvesh set /nodes//storage//content/ --protected 0. It does not need to defeat the protection flag. It simply turns it off, the same way you would.
• Then it encrypts what is left. VM disk images (qcow2, vma, vmdk), databases (sql, mdf, mdb) and backup files (bak, img, backup), using ChaCha20 with per-file keys wrapped in Curve25519.

There is one piece of good news buried in the analysis: the malware requires root and exits immediately without it. Everything that follows depends on that fact.

The Sentence Worth Rereading

If your ransomware plan is the "protected" flag on your Proxmox backups, you do not have a ransomware plan.

That flag is a safety catch against human error — it stops you deleting last month's backup at midnight by accident. It was never an adversary control, and this malware demonstrates why: anything an administrator can toggle through the API, an attacker with root can toggle through the same API.

This is the single most common misconception we meet on Proxmox estates. Teams point at the protected backups on the same host, or on an NFS share the host can write to, and describe them as their recovery position. They are not a recovery position. They are in the blast radius.

The Other Door: Escaping the Guest

The second thing that changed in 2026 is the hypervisor boundary itself.

CVE-2026-64561, nicknamed *Zapscape*, is a use-after-free in the shadow MMU of KVM on x86 — the virtualisation layer Proxmox is built on. During guest-triggered page fault handling, KVM can reclaim MMU pages and invalidate a shadow root that the fault path is still using, and because the path does not re-check, execution continues under an invalidated root. The practical consequence is blunt: someone with root inside a single VM can, under the right conditions, obtain root on the host — and therefore over every other VM on that host.

The flawed code was introduced in 2020 and fixed upstream in Linux on 21 July 2026. It carries a CVSS 3.1 base score of 7.0.

Which raises the only question that matters: is your host kernel newer than that fix?

For a lot of estates the honest answer is "nobody has checked." And that gap is the real subject of this post.

This Is a Migration Problem, Not a Proxmox Problem

Proxmox is not less secure than what you left. It is a well-engineered platform with a serious team behind it.

The risk comes from how organisations arrived. A migration driven by a licence renewal is a migration with a deadline attached, and deadlines produce a predictable set of shortcuts:

• The operating model came across unchanged. The old estate was administered through vCenter by a team who never needed Linux patching discipline, because ESXi was an appliance. Proxmox is Debian. It has a package manager, a kernel, and a maintenance burden that belongs to you now.
• The management interface ended up reachable. The web UI got exposed, or put behind a VPN with shared credentials, so the migration could be finished from home. Nobody went back.
• Backups were reproduced, not redesigned. The new setup mirrors the old schedule and the old retention, and lands on storage the hypervisor can write to — which is precisely the design Pay2Key was written against.
• Nobody owns patching. In the VMware world, updates were an event with a change window. On Proxmox they are a Tuesday. If no one has that Tuesday in their calendar, the host kernel drifts months behind and nobody notices until an advisory names it.

None of this is negligence. It is what happens when infrastructure changes faster than the operating model around it.

What Actually Protects You

In rough order of how much it buys you per hour spent:

• Get one copy of your backups out of reach of a compromised host. Offsite, immutable, or pull-based — the point is that the hypervisor must not hold credentials that can delete them. If root on the host can reach your last good copy, you are one credential away from having none.
• Restore something. This month. An untested backup is a hypothesis. Restore a real VM into an isolated environment and time it, so that when it matters you know both that it works and how long you will be down.
• Patch the kernel, not just the packages. apt upgrade on Proxmox does not necessarily put you on a new kernel, and a live-patched or pinned kernel can quietly stay behind. Check the running kernel against the advisories that matter — Zapscape being the obvious current example.
• Take the web interface off the internet. Management planes belong on a separate network, behind MFA, with named accounts. The Proxmox UI on a public IP is an invitation, and it is found by scanners within hours.
• Give the API the least privilege that works. Proxmox has a real role system and API tokens with granular scopes. Backup jobs and monitoring do not need administrator. The malware needs root; every account that does not have it is a door that stays shut.
• Alert on the tells. --skiplock shutdowns you did not schedule. A backup's protected flag being cleared. Mass VM stops outside a change window. These are unambiguous signals, and on most estates nothing is watching for them.
• Have someone try it. A penetration test finds the exposed management interface, the shared credential and the forgotten host that an inventory on paper never surfaces.

Where Privum Fits

We run production infrastructure for clients across Europe, and a growing share of what we are called about is exactly this: an estate that moved off VMware quickly and has not been given the operating model it now needs.

Concretely, the work tends to be:

• An honest assessment of what is actually exposed. Our cybersecurity practice runs external penetration tests and hardening reviews, and reports what is reachable rather than what the diagram says. We publish an anonymised example of one so you can see the shape of the output before you commit.
• A backup and recovery design that survives a compromised host. Backup and disaster recovery is the part of this that people postpone and then regret. The design question is not how often you back up; it is who can delete it.
• Someone watching, at the hour this happens. Ransomware operators do not work business hours. Our 24/7 NOC covers the window where nobody on your team is awake, which is the window this specific malware is written for.
• The Linux discipline the platform now requires. Linux consulting and infrastructure work — patch cadence, hardening baselines, network segmentation, and making sure the thing that keeps you patched is a process rather than a person who remembers.

We are not going to tell you to leave Proxmox. For most of the companies asking us, it was the right call and the savings were real. But the licence saving and the operating model are two separate decisions, and a lot of estates only made the first one.

The Bottom Line

Ransomware that understands your hypervisor is no longer hypothetical. It stops your VMs with your own commands, turns off your backup protection through your own API, and then encrypts the images. Separately, a KVM vulnerability patched in July 2026 means a single compromised guest can, in the wrong conditions, take the host with it.

Both of those have the same answer, and it is not a product. It is knowing what your estate actually looks like, keeping it patched, and holding one copy of your data somewhere that a compromised host cannot reach.

If you are not certain where you stand on those three, talk to our team. A short assessment is considerably cheaper than the alternative, and the companies that paid that four million dollars were all fairly sure they were fine too.