FirstVDS Breach: VMmanager Flaw Exposed Server Secrets
In short: On October 17, 2026, attackers exploited a flaw in the VMmanager 6 virtualization control panel to breach part of the infrastructure of Russian hosting provider FirstVDS. Over roughly ten hours, a data-theft tool mounted client virtual server disks in read-only mode and copied passwords, SSH and API keys, cloud and AI-service tokens, GitHub/GitLab access, config files, command history, and crypto wallets. FirstVDS cut external access to the management panel, blocked the attackers' IP, and notified affected customers — while telling them to treat everything on the compromised servers as exposed.
What happened
FirstVDS disclosed on October 17, 2026 that part of its infrastructure had been breached through a vulnerability in VMmanager 6, a virtualization management panel built by Russian vendor ISPsystem and used by many hosting providers to run customer virtual servers. According to reporting, the attack began almost immediately after a platform update and ran from roughly 12:27 to 22:34 Moscow time. If you still keep server passwords in plain text files instead of an encrypted vault, incidents like this at an upstream provider are a good reason to rethink that habit — we cover the basics in our guide to password manager security.
What exactly was copied
This wasn't a targeted hit — it was systematic. The data-theft program mounted client VPS disks read-only and copied everything of value it could find: browser passwords and cookies, SSH keys, API tokens, GitHub and GitLab access, cloud platform tokens (including AWS, Google Cloud, and Microsoft Azure), AI-service API keys, configuration files, command history, crypto wallets and seed phrases, and user files. In its notice to customers, FirstVDS was blunt: the list isn't exhaustive, and clients should assume everything that was on an affected server — files, passwords, keys, tokens, configs, databases, and backups — is compromised.
Why this is more than "another breach"
The FirstVDS incident is a textbook supply-chain risk: attackers didn't hit a service directly, they hit the infrastructure that service trusts to run. The people affected aren't abstract end users — they're the developers, small businesses, and site administrators who rent VPS instances and run production code, customer databases, and payment-system credentials on them. If a compromised server held unencrypted customer data or payment API keys, the fallout extends well past one hosting incident, giving attackers a launchpad for follow-on attacks against the hosting customers' own users. The same chain-reaction logic drives mass credential theft via infostealer malware: one compromised node opens the door to dozens of other systems.
How FirstVDS responded
According to the company, external access to the VMmanager control panel was cut after the breach was discovered, and the attackers' server IP was blocked on the network. Affected customers received individual notifications in their account dashboard and by email, listing the specific affected servers and next steps. Customers who didn't receive a notice are told no traces of the attack were found on their nodes — though after an incident like this, it's worth checking your own access logs rather than relying on that alone.
What server owners — on FirstVDS or anywhere — should do now
Whether or not your server made the affected list, the response is the same. Change every password and reissue SSH and API keys that aren't already unique per service. Move crypto funds to new wallets — treat any seed phrase that touched the affected infrastructure as burned, no exceptions. Revoke old cloud and dev-platform tokens (AWS, Google Cloud, Azure, GitHub, GitLab) and issue fresh ones. Review login and activity logs for anything you didn't do yourself. More broadly: stop storing credentials in plain text files on a server — it won't stop the server itself from being compromised, but it sharply limits what attackers actually walk away with next time. A separate layer worth adding is an encrypted VPN tunnel when you administer servers or control panels over public or untrusted Wi-Fi — it won't patch a vendor's vulnerability, but it closes off interception of your own traffic in transit. See what that layer covers on the LiMP VPN apps page.
Sources
Frequently asked questions
What vulnerability did the attackers exploit?
A flaw in VMmanager 6, a virtualization control panel by ISPsystem that FirstVDS uses to run customer virtual servers. According to reporting, the attack began almost immediately after a platform update.
What data was put at risk?
Browser passwords and cookies, SSH and API keys, cloud and AI-service tokens, GitHub/GitLab access, config files, command history, and crypto wallets with seed phrases. The company explicitly recommends treating everything on affected servers as compromised.
How do I know if I was affected?
FirstVDS notifies affected customers in their account dashboard and by email with a list of specific servers. No notice is treated by the company as no sign of attack, but it's worth checking your own login logs as well.