← All news
#Updates

Hosting providers breached via VMmanager 6: what leaked, what we did and what you should do

Hosting providers breached via VMmanager 6: what leaked, what we did and what you should do

On the night of 16 to 17 October attackers hit hosting providers running VMmanager 6 — the ISPsystem panel that runs VPS for us and for many other providers. They had infected the panels in advance, from 11 to 16 October, through a critical vulnerability: they reached the panel database, and at some providers the nodes with client servers as well. We were affected too. We investigated together with colleagues: a shared chat of 37 people from different hosting companies, some of them running more than 30,000 machines.

Our client servers kept running the whole time, but the panel stayed closed while we investigated. We apologise for the time without it.

What leaked

The attackers had the panel database:

  • 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 got to the nodes and ran a collector there. It searched client machines’ disks for secrets:

  • Access and passwords: SSH keys, authorized_keys, system password hashes, saved database and git passwords, password managers, GnuPG keys.
  • Cloud and DevOps: AWS, Google Cloud, Azure, OpenStack, Kubernetes, Docker and Terraform credentials, npm, GitHub and GitLab tokens.
  • Applications and databases: .env files, application and database connection configs, docker-compose.yml, Vault configs.
  • Cryptocurrency: wallet files, seed and mnemonic phrases, validator keys, exchange API keys.
  • Browsers and history: passwords and cookies saved in browsers, shell and database client history.
  • Keys inside files: private keys, GitHub, GitLab and Slack tokens, AWS keys and AI service API keys, database and Redis connection strings, restic and Borg backup passwords.

We found no traces of the collector on our nodes — we checked files, services, processes and logs on every node. But we cannot fully confirm or rule it out, so we recommend playing it safe — see what to do below. The same applies to clients of most other hosting providers running VMmanager 6.

On the panel’s own server the collector ran with root privileges on the evening of 16 October. There is no client data on that server apart from the panel database, and we rotated everything service-related that was stored on it — see below.

How it unfolded

  • 11–16 October. The attackers infected VMmanager 6 panels through the vulnerability. Our first traces date to 12 October; on the evening of 16 October the collector ran on our panel’s server.
  • Night of 16 to 17 October. The attack on hosting providers: the attackers went into panel databases, and at some providers the nodes with client servers as well.
  • 17 October. We detected the breach and closed public access to the panel. We found and removed the attackers’ access and reconstructed what happened from logs and backups.
  • Night of 17 to 18 October. ISPsystem released a fix — version 2026.05.2-6. We installed it, verified the vulnerability is closed, and rotated keys and service passwords.
  • 18 October. The panel is open again.

What we did

  • Installed the vendor fix the night it came out and verified the holes are closed.
  • Rotated everything stored on the panel server: access keys to the nodes, service passwords of the billing and support integrations, DNS and backup keys.
  • Reopened the panel only through Cloudflare with additional filtering.
  • Checked every node that runs client servers and found no signs of tampering.

The client area and payments at my.forestsnet.cloud run on a separate server, and the panel has no access to it.

What you should do

If you set the root password in the panel and have not changed it since, change it — even if everything on the server looks fine.
  • Switch to SSH key login. And turn off password login — see How to harden SSH.
  • Rotate the secrets that were stored on the server: SSH keys, tokens and API keys, database passwords, cloud and CI credentials. If the server held wallets or seed phrases, move the funds to new addresses.
  • Check the server: unfamiliar users, keys in ~/.ssh/authorized_keys, cron jobs, unfamiliar processes and services. Step by step — in the VPS security checklist.
  • Have servers with other providers on VMmanager 6? Take the same steps there too.
  • Found something foreign or not sure? Contact support: we will help you sort it out and reinstall the server if needed.