FirstVDS Disk Theft Exposes a Live VMmanager Flaw

Hackers copied passwords, cloud keys and crypto wallets from FirstVDS customer disks on October 17 through a VMmanager 6 flaw. The program ran on virtualization hosts, not inside the virtual machines.

FirstVDS, a Russian VPS company operating since 2002, said only some nodes were hit and that the guests kept running. Stolen files went to a server the attackers controlled. The company has not said how many customers were involved, and no CVE has been published.

Attackers Mounted Guest Disks and Left the VMs Running

The break-in used VMmanager 6, ISPsystem’s platform used to manage virtual servers across physical boxes. That panel lives on the host. From there a disk can be opened without logging into the guest.

FirstVDS said attackers started a data-theft program on part of its virtualization nodes. The program attached customer virtual disks in read-only mode, copied files, and sent them out. It did not change those disks and did not run inside the virtual machines.

The program changed nothing on the virtual servers’ disks and did not run inside them. So there are no traces of the attack on the server itself, and it is working as usual.

FirstVDS, security incident notice, October 18, 2026

That is why a tenant who greps auth.log or lastb can come up empty. The copy happened one layer down, on the machine that holds the disks. Wallet files and seed phrases are easy to find once those disks are mounted, and guest logs will not record the read.

FirstVDS cut external access to the management system after it found the attack, which it said is what now blocks a repeat of the same path. It also blocked the attackers’ server address on its own network. Anyone who did not get a ticket or an email was told that no attack traces had been found on their nodes, though the company said the inquiry was still open.

A Security Note Aimed at Every VMmanager Shop

FirstVDS is the only host that has described customer disks being copied. The vendor note that followed was not written as a single-customer apology.

On October 18, ISPsystem told VMmanager 6 operators to install a security update at once. The wording assumed the attacker might already be present, not that FirstVDS had suffered a one-off misconfiguration.

It should be installed to remove the attacker from the infrastructure if they already gained access: the fix removes persistence left by the attacker and closes the vector through which access was obtained.

ISPsystem, VMmanager 6 security update notice, October 18, 2026

The same notice asked operators to restrict access to the platform with allow-lists while the threat stayed active, then to check for odd activity after the update. A separate DCImanager 6 security notice went out the same day in milder language, closing a vulnerability and asking for a prompt upgrade. The public notes do not say the two products share one exploit.

ISPsystem sits inside Astra Group. VMmanager is sold to hosting companies that need to spin up VPS instances, and the product pages also show public-sector moves off VMware, including a Tomsk regional health department project. A bug that can mount every guest disk is a FirstVDS story this week. It is also a problem for any shop that left that panel reachable from the internet.

What FirstVDS Customers Were Told to Rotate

Personal notices said files on affected servers could be read on October 17 from 12:27 to 22:34 Moscow time, a span of 10 hours and 7 minutes. FirstVDS told those customers to treat everything on the disk as copied, then to move money and revoke keys rather than only mint new ones.

The notice said the thieves were after access and secrets first. It listed the classes of files the company believes were in scope, and it warned that the list was incomplete.

SECRETS FIRSTVDS SAID TO TREAT AS STOLEN

• Login material: SSH keys and authorized_keys, plus password files such as shadow,.pgpass,.netrc,.htpasswd and.git-credentials, and KeePass and GPG stores.
• Cloud and build keys: AWS, Google Cloud, Azure, OpenStack, kubeconfig, Docker, Terraform, GitHub, GitLab and npm tokens.
• App and database configs:.env files, docker-compose.yml, application.yml, web.config, and connection strings for PostgreSQL, MySQL, MongoDB and Redis.
• Crypto material: wallets, seed phrases, validator keys and exchange API keys, with a first step of moving funds to a new wallet created on a clean device.
• Model APIs: OpenAI and Anthropic API keys stored on the server.
• Browser and shell leftovers: saved browser passwords and cookies, plus command history from bash, zsh, mysql, psql, redis and python.
• Backup secrets: Restic and Borg backup passwords, with an order to check that the copies themselves were not touched.

If an attacker signed in with a stolen key before it was revoked, FirstVDS told tenants to inspect authorized_keys, new user accounts, cron jobs and systemd services, and to review login logs after October 17. Cloud consoles, GitHub, GitLab and payment providers were named as places where old tokens must be revoked, not merely replaced.

Tenants who store other people’s personal data were told they may have to notify Roskomnadzor within 24 hours of learning of the incident. That clock sits on the customer as operator, not only on FirstVDS. At 15:25 Moscow time on October 18 the company said it had sent extra notices to owners of servers on nodes with signs of a possible compromise.

From October 14 the Patches Came Without a CVE

ISPsystem’s public changelog listed security-only builds dated October 14 on both the regular and stable branches, three days before the copy job ran. The notes say “security bug fixes” and nothing else. There is still no CVE, and the company has not named the versions that were exploitable.

VMMANAGER BUILDS MARKED AS SECURITY FIXES

A 2026.09.1-5 regular build is listed as the latest on October 20, but the detailed log does not attach a security note to it, so it is not counted here as a fix. FirstVDS said on October 19 at 07:20 Moscow time that an overnight vendor fix had already been installed, that the flaw was still not fully closed, and that the vendor did not recommend opening the panel while more patches were in the works.

THE WEEK AROUND THE COPY JOB

1. October 17, 2026, 12:27 to 22:34 MSK: FirstVDS later tells notified customers that files on affected servers could be read in this window.
2. October 17 to 18, 2026: FirstVDS disables external access to the virtualization manager and blocks the attackers’ server on its network.
3. October 18, 2026: ISPsystem tells all VMmanager 6 operators to patch in order to remove attacker persistence; FirstVDS publishes the incident notice and, at 15:25 MSK, sends extra mail to more node owners.
4. October 19, 2026, 07:20 MSK: FirstVDS says another vendor fix is in place, the flaw is not fully closed, and management access stays shut.
5. October 20, 2026: The stable branch adds 2026.05.2-9 as a security build. FirstVDS still has not named a victim count or an attacker.

Other VMmanager operators who still expose that interface to the open internet are leaving the same door on the latch. Allow-listing admin access is the control the vendor asked for while the threat stayed active.

The Same Manager Under Hospital Networks

FirstVDS sells virtual servers to people who run sites, apps and databases. ISPsystem sells the manager those hosts use, and it also sells that manager as a VMware stand-in for Russian public-sector networks.

Product case studies on the VMmanager site include a Tomsk regional health department cluster and other government and hospital migrations onto Astra Linux stacks. Those projects are not FirstVDS tenants, and nothing in the company’s notice says a hospital disk was copied on October 17.

They do run the same class of control software. A read-only mount from the host does not care whether the guest is a WordPress box, a billing panel or a clinical database. The useful stolen object is still a key, a token, a wallet file or a.env with a production password.

Amsterdam, Almaty and a Panel Still on a Leash

FirstVDS lists data centers in Moscow, Amsterdam and Almaty, including its own WEB DC in Moscow. The status board names NorthC Amsterdam 1 in the Netherlands and Ahost in Almaty, Kazakhstan, and on October 20 it showed those links as up.

The company has not said which sites housed the hit nodes. Disks in Amsterdam and Almaty still sit behind the same kind of manager as the Moscow fleet, so a tenant who picked “EU” or “Kazakhstan” at checkout does not automatically sit outside this flaw.

WHAT WE KNOW

• The method: A program on some FirstVDS virtualization nodes mounted guest disks read-only on October 17 and copied files to an attacker-owned server.
• The window: Notified customers were told files could be read from 12:27 to 22:34 Moscow time.
• The vendor line: ISPsystem told every VMmanager 6 operator to patch to remove persistence and to keep the platform on an allow-list.
• The October 20 state: Another stable-branch security build shipped, and FirstVDS still has not published a customer count or a CVE.

WHAT IS UNCONFIRMED

• Scale: How many servers and customers were copied, and whether Amsterdam or Almaty nodes were among them.
• The bug: Which VMmanager 6 versions were exploitable, how the attackers first reached the panel, and whether stolen keys have been used.
• Other hosts: Whether any second VMmanager shop has found the same persistence the vendor told operators to remove.
• The actors: Who ran the copy job, and whether the goal was wallets, cloud accounts, or both.

The FirstVDS service status page, last updated at 04:35 on October 20, still described the platform as running with restrictions. FirstVDS said a postmortem will be published after the incident is closed and the inquiry is finished. Until that lands, notified tenants are still being told to assume the disk was copied and to revoke every secret that lived on it.