FirstVDS says attackers copied files from customer virtual-server disks on October 17 without running their stealing program inside those servers. A website could keep working while its passwords, private keys and other files were being taken. In an October 18 notice, the hosting provider told notified customers to treat their server data as copied and urgently replace the secrets stored there.
The important distinction is where the access happened: on part of the provider’s virtualization infrastructure, through a vulnerability in VMmanager 6. This was not simply a malicious process that a customer could find and terminate in their own operating system. If you received a notice, check its server list in your FirstVDS account and begin revoking exposed credentials from a trusted device.
The stealing program worked outside the customer OS
According to FirstVDS, the attackers placed a data-stealing program on some infrastructure servers. It attached customer virtual disks in read-only mode, searched their contents and sent collected data to an attacker-controlled server. The provider lists passwords, SSH and API keys, cloud credentials, tokens, configuration files, command histories, cryptocurrency wallets and user files among the material copied.
Read-only is a crucial detail. It describes how the program accessed the disks; it does not make the access harmless. The program could take information without altering the customer’s files. FirstVDS says it did not execute inside the affected virtual machines, which explains why the guest server could look normal and have no traces of that host-side activity.
A virtual machine’s operating system controls processes running within it. The provider’s host manages the underlying storage. In this incident, the reported route to the files came from that outer layer. Checking only the guest’s process list or whether the website responds therefore cannot establish that its stored secrets remained private.
The incident affects a subset of virtualization nodes, not the entire FirstVDS infrastructure. The provider says it has sent affected customers email and account notifications naming their servers. It also added further notifications at 15:25 Moscow time on October 18 after finding signs of possible compromise on additional nodes. No public affected-customer count appears in the notice.
Closing the management panel does not revoke copied keys
FirstVDS says it cut off external access to the virtualization management system after discovering the attack and blocked the destination server’s address within its network. Its notice says the vendor has supplied an interim patch and is working on a final fix; management access will remain restricted until the vulnerability is fully addressed. These are the provider’s reported containment measures, not an independently verified all-clear for every VMmanager installation.
The live status page separately showed authorization unavailable on several VMmanager panels when checked on October 18. That supports the presence of access restrictions, but an availability indicator cannot tell a customer which files were copied or whether a stolen token has already been used elsewhere.
This creates two separate response tasks. The provider must close the infrastructure access path. Affected customers must invalidate the credentials that may already have left it. Restoring a panel or changing one server password does not make an old API token stop working at its issuer. The same distinction matters in the AWS leaked-key response case: stopping one route is only part of containing exposed credentials.
Follow the secrets beyond the rented server
For notified customers, FirstVDS’s response instructions prioritize cryptocurrency wallets: move funds to new wallets created on a different, clean device. Then replace passwords, private SSH keys, API keys and tokens stored on the affected server. Its examples extend beyond root access to databases, website control panels, mail, cloud services, CI/CD and payment systems.
Revoke the old credentials at the services that accept them. Creating a replacement key alone can leave the copied one usable. For an SSH private key that was stored on the server, consider the other machines where its matching public key grants access; changing only the rented server’s root password does not withdraw that trust.
Review logins since October 17 both on the affected server and at services whose credentials it held. The provider specifically advises checking ~/.ssh/authorized_keys, unexpected users, cron jobs and systemd services if an attacker may have logged in before rotation. That is a check for possible follow-on access, distinct from the original read-only disk copy. Preserve relevant logs while investigating.
The wider lesson is the same as in credential theft from stolen backups: a copy of stored data can become access to another system. Reinstalling a server cannot recall an already copied secret, and a normal-looking guest cannot clear the provider’s storage layer.
If no notice has arrived, FirstVDS says it has not found attack traces on your nodes so far; it also says its investigation continues. Check the account directly rather than treating silence, uptime or the absence of an antivirus alert as a final exposure verdict. The provider plans a postmortem after the incident and investigation are closed.
References
- FirstVDS/CLO. Security incident notice. Official provider channel linked by firstvds.ru; October 18, 2026, including its 15:25 MSK update. Accessed October 18, 2026.
- FirstVDS. Service status panel. Live VMmanager access status; accessed October 18, 2026.
