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
In its October 18 notice, FirstVDS said it cut off external access to the virtualization management system after discovering the attack and blocked the destination server’s address within its network. That notice said the vendor had supplied an interim patch and was working on a final fix; management access would 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.
October 21 update: a patch and a clean host are different milestones
In its October 21, 15:00 Moscow-time update, FirstVDS said its own technical review was complete and customer notifications had gone out in three stages because the malware left different traces on different nodes. It did not expect to identify additional affected nodes from that completed review. The provider still could not confirm the full volume of exported data and continued to tell notified customers to treat all server data as copied.[3]
The newly reported detail is persistence: FirstVDS found hidden services disguised as routine infrastructure processes on some nodes, capable of restoring attacker access. It says it is removing that foothold and checking each affected node before returning it to service. According to the provider, the vendor had reported the vulnerability closed, but the infrastructure would remain isolated during restoration. Management functions are moving to the customer account, with missing operations handled through support. Patching the entry route and removing an existing foothold are separate jobs.
ISPsystem’s October 20 statement independently confirms a vulnerability in a VMmanager 6 build. Its published precautions call for restricting management-platform and virtualization-node connections to trusted administrators and vendor support, limiting SSH by trusted IP address and rotating passwords. It does not disclose a count of affected operators or technical access details.[5] The FirstVDS restoration status should therefore not be treated as a blanket verdict for another provider’s installation.
Another provider caught the management foothold earlier
Senko Digital’s October 19 postmortem describes an earlier start and a different outcome. It dates its platform compromise to October 12 and says the attacker created two administrator API tokens valid until 2036. During a separate security review on October 14, the team found and revoked those tokens and restricted public panel access. Deleted activity records were recovered during the investigation.[4]
Senko says its subsequent audit found no evidence that customer VM disks were read or copied, and that later campaign stages observed at other providers did not run in its infrastructure. That is Senko’s finding, not a reversal of FirstVDS’s disk-copy warning. For a customer, the questions are provider-specific: when did access begin, did it reach the hosts or disks, and were attacker tokens and persistence removed? October 17 is not a universal starting point for investigating the wider campaign.
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.
In its October 18 notice, FirstVDS said customers without a notification had no attack traces found on their nodes at that stage, while its investigation continued. Its October 21 update supersedes that interim status: the provider says its own technical review and three notification stages are complete, with no additional affected nodes expected from that review. Restoration and checks for persistent access are still under way. Check the account directly; silence, uptime or the absence of an antivirus alert is not a final exposure verdict. The October 18 notice also promised a postmortem after the incident and investigation were 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.
- FirstVDS/CLO. Technical-review and restoration update. Official provider channel, October 21, 2026, 15:00 MSK; accessed October 21, 2026.
- Senko Digital. VMmanager security incident postmortem. October 19, 2026; accessed October 21, 2026.
- ISPsystem. Security incident involving a VMmanager 6 build. October 20, 2026; accessed October 21, 2026.
