VMmanager 6 Security Incident: What Happened and What to Do

In October 2026, attackers targeted several Russian hosting providers at once through a critical vulnerability in VMmanager 6, a virtualization management panel developed by ISPsystem (part of Astra Group). This panel runs VPS for us and for many other providers. We were affected too.

Your servers continue to run. Below is what happened, why, what we have already done, and what you need to do.

The cause: a vulnerability in the vendor's product

The attack was made possible by a critical vulnerability in the VMmanager 6 software itself. This was not a misconfiguration at an individual provider: the same vulnerability was exploited simultaneously against many hosting companies.

FirstVDS, ForestsNet Cloud, MHost, HSH Network and YaColo have publicly reported breaches via VMmanager 6. The vendor has confirmed the incident: according to an Astra Group representative, the vulnerability was in one of the VMmanager builds.

What the vendor has still not disclosed

As of publication, ISPsystem has not provided hosting providers with enough information to confidently remediate the vulnerability and verify their infrastructure. The following has not been published:

• a description of the vulnerability and the initial access method;
• a CVE identifier and the list of affected versions;
• indicators of compromise (IoCs): attacker server addresses, file and process names, signs of persistence;
• confirmation that the released fixes fully close the vulnerability.

The first fix was released on the night of October 18, followed by several more. According to other affected providers, the vendor itself advised against reopening access to the panel until further patches are released. Without technical details, each provider has to reconstruct the attack on its own, from its own logs and by sharing findings with peers.

We have asked the vendor for full technical information and will publish it as soon as we receive it. We believe that responsibility for the vulnerability, and for timely disclosure of information about it, lies with the product's developer.

What may have leaked

The attackers gained access to the panel database, which contained:

• the list of servers and their IP addresses;
• email addresses of panel accounts;
• root passwords set through the panel when ordering, reinstalling or changing the password;
• VNC console passwords.

At some providers, the attackers also reached the virtualization nodes. There they ran a program that mounted client server disks in read-only mode and searched them for secrets:

• SSH keys, authorized_keys, password hashes, password managers, GnuPG keys;
• cloud and DevOps credentials: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, GitHub, GitLab and npm tokens;
• .env and docker-compose.yml files, application and database configs;
• crypto wallets, seed phrases, exchange API keys;
• browser passwords and cookies, shell history;
• AI service API keys, restic and Borg backup passwords.

The program ran at the infrastructure level and never executed inside the servers. As a result, it leaves no traces on the server itself, even if data was copied.

We found no traces of this program on our nodes, but given the lack of information from the vendor, we cannot fully rule out that it ran.

What we did

Without waiting for full information from the vendor, we carried out our own investigation and closed the access paths known to us:

1. Closed public access to the control panel immediately after detecting the attack.
2. Found and blocked unauthorized administrator accounts in both of our panels, created by the attackers for persistence. Details have been preserved for the investigation and shared with the vendor.
3. Installed all fixes released by ISPsystem.
4. Rotated everything stored on the panel server: node access keys, service passwords for billing and support integrations, DNS and backup keys.
5. Checked the nodes hosting client servers: files, services, processes and logs.

What was not affected

Based on our investigation, the incident did not affect:

• backup servers;
• personal data in billing;
• payment details;
• any services other than the affected virtualization management platform.

Separating these systems made the difference: access to part of the virtualization management environment did not give access to billing data, client accounts or the backup infrastructure.

What you need to do

The main risk is that the attackers will use stolen passwords and keys. Do the following as soon as possible, even if everything on your server looks normal.

1. Crypto wallets first. If the server held wallets or seed phrases, move the funds to new wallets created on a different, clean device.
2. Change your root password if you set it through the panel and have not changed it since.
3. Switch to SSH key login and disable password login.
4. Rotate all secrets stored on the server: user and database passwords, SSH keys, API keys and tokens, access to cloud services, CI/CD, email, payment systems and AI services.
5. Revoke old keys instead of just creating new ones: in cloud consoles, GitHub, GitLab and with payment providers.
6. Check the server: unfamiliar users, keys in ~/.ssh/authorized_keys, cron jobs, unfamiliar processes and systemd services.
7. Check login logs on the server and in the services whose keys were stored on it: look for logins from unfamiliar addresses after October 11.

If you have servers with other providers running VMmanager 6, take the same steps there too.

Need help?

Found something suspicious on your server, or not sure? Contact our support team — we will help you sort it out and reinstall the server if needed.

We apologize for the inconvenience, including the time without access to the panel. We will update this article as new information from the vendor becomes available and will publish a detailed post-mortem once the investigation is complete.