ISPsystem Releases VMmanager Updates After Zero-Day Attack
ISPsystem has released security updates for VMmanager and reworked its security architecture after a zero-day attack. Checks of providers’ infrastructure are ongoing.
ISPsystem has released security updates for VMmanager and reworked the product’s security architecture after an attack exploiting a previously unknown vulnerability. As Habr reported on October 27, 2026, the incident affected one build of VMmanager 6 Hosting, which hosting providers use to provision virtual machines automatically. Checks of affected infrastructure are ongoing: installing the fixes does not mean the search for evidence of the attack is over.
What We Know About the Attack
Providers were running the vulnerable build in an internet-facing environment. According to ISPsystem, the attackers exploited a zero-day vulnerability, and the way Nginx allowed such requests through made exploitation possible. The published report does not contain enough technical detail to independently assess a specific VMmanager installation.
ISPsystem says artificial intelligence was used in the attack: the tactics were adapted to individual providers, while different avenues of attack were tested in parallel. Kaspersky Lab also reported the use of malware written with the help of AI. These are accounts from participants in the investigation; the report does not provide a detailed technical analysis of the attackers’ actions.
The consequences were known before the vendor’s latest statement. On October 18, FirstVDS said attackers had exploited the VMmanager 6 vulnerability to gain access to part of its network infrastructure and some customer data. The provider conducted its own technical investigation and continues to review its security with ISPsystem.
Fixes and the Search for Signs of Compromise
ISPsystem urgently released unscheduled fixes, expanded its support capacity and set up a round-the-clock response. The vendor temporarily blocked remote management and the execution of internal scripts to limit the attackers’ options and prevent them from establishing persistence. The company also said it had reworked the security architecture of its VMmanager products.
Specialists from Kaspersky Incident Response and Kaspersky Threat Research took part in checking customer infrastructure. Kaspersky Lab experts provided updated databases of indicators of compromise and the Kaspersky Virus Removal Tool (KVRT) to scan provider nodes and remove malicious binaries. The checks are not complete: ISPsystem is working with customers and partners to find remaining traces of the attack, examine the attackers’ behaviour and investigate backdoors planted earlier.
To test the fixes against a real attack, the vendor deployed internet-facing test environments resembling hosting providers’ infrastructure. Some received the latest patches; others were deliberately left vulnerable. The report does not yet include the results of those tests.
No date has been given for the investigation’s completion. ISPsystem says it withheld technical details while the work was under way to avoid giving the attackers additional information. As a result, the current statement does not provide a complete list of indicators of compromise or establish the status of any individual node.
What This Means for Site Owners and Teams
If your site is hosted by a provider that uses VMmanager, server availability and access to management tools are worth considering separately. On October 20, FirstVDS warned customers that the virtualization panel would remain closed for the time being. The company is moving essential server management functions to the customer account and has not ruled out keeping that arrangement in place.
On October 21, FirstVDS said that, according to the vendor, the vulnerability had been fixed, but access would not be restored until the affected nodes had been fully recovered and checked. The infrastructure remained isolated. On October 23, the provider clarified that customer servers were running, although management operations might take longer than usual. For a site team, this means a project being available to visitors and the usual pace of server operations are separate issues.
For those who manage VMmanager themselves, I would suggest checking that the fixes are installed and not putting off the search for signs of compromise on their nodes. Provider customers should find out which management functions are currently available and whether checks of the affected infrastructure are complete. The report gives no general timetable for restoring access, so you will need to follow updates from your own provider.
My View: Patching and Checking Serve Different Purposes
I would distinguish between closing the vulnerability and dealing with the consequences of an attack that has already happened. Installing the fix quickly matters, but its installation alone cannot tell you whether malicious files or backdoors remain on the nodes. That is why I understand FirstVDS’s decision not to reopen the panel immediately after the vendor announced that the vulnerability had been fixed.
For a site owner, that delay is inconvenient, especially if server settings need to be changed. I would check with the provider in advance which interface to use for necessary operations and what restrictions still apply. In situations like this, what matters to me is not only the release of patches but also a thorough, methodical check of the infrastructure and clear updates on recovery progress.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
Experienced full-stack developer
I develop web services and CMS integrations, and most often help teams remove unnecessary layers. My advice to beginners: choose a simple architecture you’ll be able to maintain.
All posts by the authorRelated articles
Linux Kernel Vulnerability Allows Attacks via Incoming TCP Connections
A critical Linux kernel flaw allows attackers to target servers through incoming TCP connections without a password. Server owners should check their distribution’s patch status and install the update.
PHP Core Vulnerabilities Patched That Could Allow Remote Code Execution
PHP has patched core vulnerabilities that could lead to remote code execution and process memory disclosure. Website owners should check their PHP version and install the security update.
Attackers Used DebugBear’s DNS to Replace a Website Monitoring Script
After an attack on DebugBear’s infrastructure, attackers replaced its Real User Monitoring script. Site owners using it to track Core Web Vitals are advised to remove the tag and check accounts.
Discussion 4
Borislav Ganev
One practical addition: keep the vulnerable VMmanager build and its Nginx config as evidence before changing anything, where your incident process allows it. A clean upgrade closes the entry point, but preserving logs and timestamps can make the separate compromise check much more useful.
Marc Llorente
@borislav.ganev good call—especially since the checks are still ongoing. I’d want the Nginx config and timestamps preserved too, not just the VMmanager build; patching first and investigating later can erase useful context.
Tomas Vaičiūnas
@borislav.ganev, I’d also capture the exact package/build identifier and the Nginx configuration in effect at the time, then record hashes and timestamps for the collected artifacts. That gives the team a defensible baseline when comparing provider nodes and helps avoid treating a patched system as proof that it was never compromised.
Hayk Ohanyan
How would you handle that baseline if providers have many nodes—hash each Nginx config separately, or keep a shared config fingerprint plus per-node timestamps?