FirstVDS is one of Russia's oldest hosting providers, operating since 2002. The company has confirmed that attackers got into part of its virtualization infrastructure through a vulnerability in VMmanager 6, the virtualization management platform built by Russian vendor ISPsystem. From there they copied passwords, SSH and API keys, cloud credentials, tokens, configuration files, command histories, cryptocurrency wallets and user files from customer virtual servers. The attack took place on Saturday, October 17, 2026. The Record, citing the company, says it was discovered the same day. FirstVDS has not said how many customers or servers were affected, and no threat actor has been named. The investigation is ongoing (1275.ru). Accounts of exactly when the company disclosed the incident vary a little. 1275.ru and Xakep date the disclosure to October 17. Gridinsoft cites an October 18 customer notice. The Record says only that the company spoke "over the weekend."
What Happened
All sources say the same thing about the core sequence. The attackers exploited a flaw in VMmanager 6 and gained access to some of FirstVDS's virtualization nodes. On those nodes they deployed a data-theft program. That program mounted the disks of customer virtual machines in read-only mode, collected their contents and sent the data to a server the attackers controlled (The Record, Xakep, 1275.ru, Gridinsoft).
FirstVDS stresses that only part of its infrastructure was affected. Customers whose servers ran on the compromised nodes were notified by email and in their account dashboard. The notice includes a list of affected servers and remediation instructions. The provider told customers who did not receive a notice that no traces of the attack were found on their nodes (1275.ru, Xakep).
LiMP VPN reports that the attack began almost immediately after a platform update and ran from about 12:27 to 22:34 Moscow time, a window of roughly ten hours. The other sources reviewed do not confirm this timeline, so treat it as unverified.
After detecting the attack, FirstVDS closed external access to the VMmanager management interface and blocked the attackers' server address on its network (Xakep, LiMP VPN). Reports on the fix differ slightly:
- Xakep: ISPsystem has released an interim patch and is working on a final fix.
- Undercode News: FirstVDS has installed an additional vendor fix, but the vulnerability is still not fully resolved.
Both outlets agree that external access to the management system will stay closed until a complete fix ships.
What Was Taken
FirstVDS's own list of copied data, as relayed across sources, includes:
- Passwords
- SSH keys, API keys and keys for server access
- Cloud service credentials and tokens
- Configuration files and command (shell) histories
- Cryptocurrency wallets
- Arbitrary user files
LiMP VPN gives a more detailed breakdown that the other outlets do not repeat. It lists browser passwords and cookies, GitHub and GitLab access tokens, AWS, Google Cloud and Microsoft Azure tokens, AI-service API keys, and wallet seed phrases. According to LiMP VPN, FirstVDS told customers that the list is not exhaustive and that they should assume everything on an affected server was compromised, including databases and backups. 1275.ru and Xakep carry the same guidance from the company: anyone who received a notice should assume their server's data was copied.
Volume: FirstVDS has not disclosed a number of affected customers, servers or records, and none of the sources gives one.
Why It Matters
This is a supply-chain-style compromise at the hypervisor layer. The data was never touched from inside the customer's operating system. Gridinsoft notes that the theft program never executed inside the guest VMs and changed nothing on their disks. FirstVDS put it this way: "there are no traces of the attack on the affected virtual servers, which continue to operate normally" (The Record). Endpoint detection, process monitoring and file-integrity checks inside the guest would have seen nothing. Websites stayed online while their secrets were being copied.
The main risk is secret sprawl, not downtime. 1275.ru points out that stolen keys and tokens can open cloud consoles, code repositories and payment systems, and that this access survives the closing of the original vulnerability. Repository credentials could also let attackers alter code or tamper with build pipelines, which extends the blast radius to downstream users of affected customers' software.
The exposure may also reach beyond FirstVDS. VMmanager 6 is used by many hosting providers (LiMP VPN), and as of the latest reporting the flaw is only partially patched. Any provider running VMmanager 6 with its management interface reachable from the internet should consider itself at risk.
Customers who process personal data on their servers have regulatory duties as well. FirstVDS's own guidance on Russia's personal data law (152-FZ) reminds customers that this makes them data operators under the law. 1275.ru reports that the provider advises customers holding personal data to take this into account when responding.
The Attack Technique
- Initial access: exploitation of an undisclosed vulnerability in ISPsystem's VMmanager 6 virtualization management platform. No CVE or technical details have been published.
- Execution: a data-theft tool deployed on compromised virtualization hosts, not inside customer VMs.
- Collection: customer virtual disks were mounted read-only from the host side and searched for high-value material such as credentials, keys, tokens, configs, wallets and shell history. LiMP VPN describes the collection as systematic rather than targeted.
- Exfiltration: the collected data was sent to an attacker-controlled external server, which FirstVDS has since blocked.
- Stealth: because nothing ran in the guest and nothing was written to the disks, the affected VMs show no forensic traces of the intrusion.
Attribution is unknown. None of the sources names a group or says whether the motive was financial or espionage. The focus on crypto wallets and cloud tokens points toward monetization, but that is an inference, not a confirmed finding.
What Organizations Should Do
- Assume full compromise if you were notified. Treat every secret that was on the affected server as stolen, including databases and backups. Do the remediation work from a clean, trusted device.
- Move crypto funds first. FirstVDS advises transferring assets from any wallet that was on an affected server into a new wallet created on a clean device (Xakep). Wallet theft is immediate and cannot be reversed.
- Rotate and revoke all credentials, not just the server password. This covers SSH keys, API keys, cloud IAM keys (AWS, GCP, Azure), Git tokens, CI/CD secrets, database passwords and AI-service keys. Then review cloud and repository audit logs from October 17 onward for unfamiliar access.
- Audit code and pipelines. If repository or build credentials were on the server, look for unauthorized commits, new deploy keys, changed workflows and unexpected releases.
- If you run VMmanager 6, lock down the management plane. Remove internet exposure of the management interface, apply ISPsystem's interim patch, watch for the final fix, and hunt for unexpected disk-mount activity and outbound transfers on hypervisor hosts.
- Stop storing secrets in plaintext on VPS disks. Use a secrets manager or vault, short-lived credentials and scoped tokens. A host-level compromise then yields far less, and you have fewer secrets to rotate.
Sources: Hackers steal customer data from major Russian hosting provider Fir... | FirstVDS сообщил о краже данных клиентских серверов через уязвимост... | FirstVDS Breach: Virtual Disks and Stored Secrets Copied | FirstVDS Breach: VMmanager Flaw Exposed Server Secrets | Компания FirstVDS сообщила о взломе — Хакер | FirstVDS Confirms Customer Data Theft Through VMmanager 6 Vulnerabi... | Обработка персональных данных — как клиентам FirstVDS выполнить тре... | Хакеры получили доступ к конфиденциальным данным ...