In mid-October 2026, the infrastructure of several dozen hosting providers using VMmanager 6 Hosting in their IT environments faced a coordinated, multi-stage attack. The attacker exploited vulnerabilities that, given the specifics of hosting providers’ technical and business processes, widened the attack surface and led to the compromise of configuration data, secrets, and user files for a number of customers.
Working together with customers and partners, the ISPsystem development team began investigating and remediating the security incident as quickly as possible. In particular, it was established that the attack on VMmanager 6 was carried out using specialized AI tools. The vulnerabilities exploited during the attack have been fixed. The investigation continues in order to rule out other possible attack vectors and establish all the circumstances of the incident.
What Happened
On 13 Oct 2026 at 21:40 (UTC), the technical support team received a request from one of the hosting providers: suspicious activity had been detected in its infrastructure, on servers running VMmanager 6 Hosting.
Immediately afterward, the ISPsystem team promptly launched a joint investigation with the hosting providers. However, at the start of the response it had not been reliably established whether the entry point was the VMmanager 6 Hosting platform or the provider’s own infrastructure. Further analysis showed that the first traces of intrusion had been recorded on some customers’ systems on 12 Oct 2026. This is also supported by user discussions in specialist communities on social networks.
According to information from the providers, it was hypothesized that the attacker had entered the infrastructure through a vulnerability related to ISO images that had been reported and verified through the Bug Bounty program on 9 Oct 2026. In other words, an error of this kind presupposes initial user-level access, which can be obtained simply by buying a virtual machine from a hosting provider. The team had been working on fixing it. Strengthening security required certain architectural changes, so the release of the new platform version was scheduled for 15 Oct 2026.
On 14 Oct 2026 at 16:00 (UTC), to close the vulnerabilities urgently, hotfixes 2026.05.2-5 and 2026.09.1-1 were released instead of the planned patch; they were based on fixes scheduled for the new version. To speed up delivery, we did not include in these hotfixes a number of preventive architectural changes that had been planned for the 15 Oct 2026 release: they were included in the subsequent hotfixes. The ISPsystem team also promptly notified customers through technical support that these hotfixes needed to be installed, and provided the infrastructure-protection recommendations that were current at the time, including disabling users’ ability to upload their own ISO images on infrastructures that were already compromised. Because VMmanager and DCImanager share a number of services, a similar patch, 2026.09.1-1, was built and applied to DCImanager on 15 Oct 2026.
Unlike in the Enterprise segment, where infrastructure can be fully isolated within a closed corporate perimeter, the business model of hosting providers requires maximum public availability. For this reason, hosting providers typically run the platform in an open perimeter. It is important to clarify here: for a hosting provider, an “open perimeter” is not merely having internet access, but also having publicly accessible services on public (routable) IP addresses. It is precisely public IP addresses and externally exposed services that multiply the attack surface, which includes not only the platform itself but also the surrounding infrastructure. For Infrastructure customers, an “open perimeter” usually means only internet access. Therefore, the threat models for these two scenarios differ fundamentally.
On the morning of 17 Oct 2026 (UTC), a new wave of attacks began, as evidenced by requests to ISPsystem support. Their number kept growing throughout the day, and by the evening of 17 Oct 2026 the number had reached about 20. While analyzing the logs of the systems hit by the new phase of the attack, we found that the hotfix released earlier had done its job, but the attacker had additionally started exploiting a different vulnerability. At the same time, we took several further protective measures: we disabled the ability to issue SSH access in the platform, prohibited administrators from running scripts for nodes and VMs, and gave providers recommendations for “locking down” their infrastructure, which made it possible to limit the attacker’s room for maneuver and keep them from gaining a foothold in the system; meanwhile, we kept building hotfixes.
On 18 Oct 2026 at 01:00 (UTC), hotfixes 2026.05.2-6 and 2026.09.1-2 were released. We deliberately restricted some functionality, including running and executing scripts inside the platform. This made it possible to “paralyze” the attacker; however, we understood that the root cause of the incident had not yet been found, and we continued the investigation.
On 18 Oct 2026 at 15:00 (UTC), hotfixes 2026.05.2-7 and 2026.09.1-3 were released, closing additional potential paths for lateral movement inside the product.
On 19 Oct 2026, security updates for DCImanager 6 were released, 2026.09.1-3 and 2026.09.1-4. As mentioned earlier, the platform has an architecture similar to that of VMmanager 6, and we also protected it as part of the incident response.
On 19 Oct 2026 at 13:00 (UTC), during the investigation, we established that the attacker had gained access to the servers using HTTP Request Smuggling. This relied on a previously unknown zero-day vulnerability in our service, while the tendency of nginx to let such requests through made its exploitation possible. An HTTP request to establish a WebSocket connection, carrying a body, was sent to the system. According to the relevant , this client-side behavior is not recommended, but nginx lets such requests through, which made it possible to use HTTP request smuggling.
In nginx, starting with version 1.31.5 (2 Sep 2026), a directive called client_body_early_read, which makes it easy and convenient to configure blocking of such requests for both HTTP/1.1 and HTTP/2, has appeared (fortunately, we do not use HTTP/3). Unfortunately, this directive is not yet supported in the current stable version of nginx (1.30.6). Of course, the nginx behavior we found does not relieve us of responsibility for the incident, but we strongly recommend taking it into account if you use this solution in your own infrastructure.
As a result, the service contacted by the attacker rejects the request but does not read its body, and because the request contains a Keep-Alive header, the service reads the received body as a new request. For ordinary requests passed from nginx to the service (proxy_pass), we used an additional Connection: close header on our side, which prevents the system from being fooled in this way, but this cannot be done for WebSocket connections.
This is what allowed the attacker to execute a request inside the system with administrative privileges. Inside the Docker network, our services mark internal requests with a special HTTP header, which is not accepted from outside (nginx, used as the frontend, does not let this header through). But because nginx treated the second request as the body of the first, it did not analyze or modify it in any way.
On 19 Oct 2026 at 18:00 (UTC), hotfixes 2026.05.2-8 and 2026.09.1-4 were released, fixing the HTTP Request Smuggling vulnerability we had discovered; some functionality remained blocked, because the attacker was still inside the platform.
On 20 Oct 2026 at 01:00 (UTC), hotfixes 2026.05.2-9 and 2026.09.1-5 were released: WebSocket functionality that had previously been restricted by the hotfix against HTTP Request Smuggling, was restored, and a more precise fix for the main vulnerability was released that does not affect the core functionality of the platform.
In parallel, we were cleaning up the infrastructures: we searched for malicious files, backdoors, and persistence mechanisms, and we found and removed a significant portion of them ourselves. Third party Information Security Experts were additionally brought in to help find and eliminate traces of the attacker and indicators of compromise: our colleagues reinforced the cleanup work we had started. With the consent of those customers whose infrastructures were being checked, we audited their systems using specialized utilities and passed the analysis results for their infrastructures to the experts, along with scripts we had written ourselves to look for traces.
The team of information security experts also promptly updated its detection rules for identifying the attacker’s malicious software, using its own solutions. The rules continued to be updated as new data was obtained during the investigation.
On 20 Oct 2026 at 18:30 (UTC), hotfixes 2026.05.2-10 and 2026.09.1-6 were released, with architectural improvements and the restoration of a further part of the deliberately blocked functionality. Automatic blocking of the attacker’s known “implants” was added. A fix for DCImanager, 2026.09.1-5, was also released.
On 21 Oct 2026 at 16:00 (UTC), based on the analysis of data from hosting providers, the team of information security experts offered an additional set of specialized tools. It helped to identify the remaining malicious objects, such as binary files and other traces of the attacker. The tool was given to a number of providers for additional scanning. It proved effective, after which ISPsystem offered it to everyone affected by the incident.
On 22 Oct 2026 at 18:30 (UTC), we released fixes 2026.05.2-11 and 2026.09.1-7 with additional platform protection mechanisms against potential attacks and stability improvements for the hotfixes already released. In parallel, we continued to analyze the compromised infrastructures and to search for backdoors and anomalies.
On 23 Oct 2026, security updates were released for all products of the ecosystem: VMmanager 6 — stable v2026.05.2-12, regular v2026.09.1-8; DCImanager 6 — stable v2026.09.2-2, regular v2026.09.1-6; BILLmanager 6 — stable v6.154.5, regular v6.157.3; DNSmanager 6 — v6.5.2. We emphasize that these updates are additional protective measures, implemented following the analysis of the attack methods, and are aimed at strengthening the security of the ecosystem as a whole, including against vectors that were not used during the incident. They also include updated nginx components, fixing the known vulnerabilities CVE-2026-15176, CVE-2026-97205, and CVE-2026-93479. Since the 19 Oct 2026 patch was installed, no cases of compromise have been recorded in infrastructures that applied the update.
On 23 Oct 2026, together with the information security experts and the customers of hosting providers, we continued studying the compromised infrastructures. Once this work is complete, we will provide additional information on the recommendations that must be followed to fully clean up the infrastructure.
During the investigation, to verify the effectiveness of the fixes under real attack conditions, ISPsystem deployed a number of test environments in an open perimeter that imitate hosting providers’ infrastructure (honeypots): some with up-to-date security patches, others without them. The environments without fixes were deliberately left vulnerable and confirmed that the attacks are reproducible. The patched environments could not be compromised.
The attacker found the test environments quickly and over several days made attempts to break in: in total, more than 10,000 requests per environment, trying various vectors and calls. All attempts against the protected environments were repelled: the fixes proved their effectiveness under real attack conditions. At the same time, we are studying which vectors the attacker tried to use: this data will be taken into account in upcoming patches.
At this point, the joint investigation with the providers has established that the attack created a threat to the security of user data, including potential leakage of SSH keys, access passwords, access tokens for cloud services, configuration files, command history, crypto wallets, and user documents. For some end customers, the incident resulted in temporary unavailability of services, caused by the need for emergency technical work and the forced isolation of compromised nodes. The analysis of the incident found specialized malicious software on the nodes that was engaged in collecting data. At the same time, we can neither confirm nor rule out the volume, or even the fact, of data transfer. Therefore, a number of providers are taking a conservative view and treat the data as de facto compromised. We consider this approach justified.
As of today, the vulnerabilities exploited during the attack have been closed. The necessary security fixes have been deployed in customers’ infrastructures. The investigation nevertheless continues: together with customers and partners, we are studying the compromised infrastructures, analyzing the attacker’s behavior, and looking for backdoors planted by the attacker that were not previously detected.
Response and prevention measures:
- In the course of the response, close cooperation was established with a number of hosting providers; their feedback, assistance in checking installations, and willingness to take part in diagnostics were used to contain the incident and to verify the effectiveness of the measures taken.
- We informed customers through closed channels: mailings, the customer account area, and in-product banners. We made no public statements while the attacker remained active: premature disclosure of details could have increased the number of victims. The priority was reducing risk for customers, not the speed of public communication. In addition, we have been removing earlier versions of security patches from the official website so that customers are not confused when installing the current version. We strongly urge you to pay attention to messages from the vendor and not to postpone installing security updates.
- On the product side, changes were made to the internal framework used by all system services: control over HTTP request processing was strengthened, and additional checks for internal requests were introduced to reduce the risk of their forgery if an attacker penetrates the internal network.
- Platform protection mechanisms against potential attacks have been strengthened; the changes are already included in the latest release. Work on improving the platform’s security continues, and we will release further updates in the near future. Please install the current versions and follow our recommendations. Using old versions of the product greatly complicates, or entirely rules out, an investigation if an incident occurs, and also makes it possible to use vulnerabilities for intrusion and hacking that the vendor has already fixed in the current versions of the platform.
- We have already transformed our internal vulnerability lifecycle management process. This will allow us to strengthen vulnerability discovery, control, and handling, and to move to a model of end-to-end preventive and rapid incident response. This approach has already been applied in the iterative delivery of the latest hotfixes. Why does this matter? When attackers work with automated tools, only hours pass between a vulnerability being found and being exploited.
- Another line of work is automated, continuous AI-driven penetration testing. This practice was used before, but during the incident response it was stepped up: the frequency of testing increased and its coverage expanded. This makes it possible to identify hidden vulnerability chains faster.
- Cooperation with the information security experts will continue, with the aim of auditing the compromised infrastructures and conducting a full investigation to reconstruct the whole picture of the incident, including searching for the threat actors’ persistence mechanisms and new indicators of compromise (IoCs), and cleaning up the infrastructures.
- Important information for users who closed the perimeter because of the incident: please keep the perimeter closed a little longer: we are completing the analysis of the attacker’s actions and plan to release several more patches that strengthen security. We will let you know when it is possible to reopen the perimeter and resume normal operation. In addition, we recommend that all users use reliable protection against cyber threats. The solutions we have proposed effectively detect the malicious software used in this attack. You can also check your infrastructure with a free tool; for this purpose, we recommend contacting the vendor’s technical support.
Important information for users of VMmanager Infrastructure licenses: we have prepared additional measures to strengthen platform security, based on the incident analysis data, and we recommend installing the patches as they are released.
Conclusion
We faced an attack of unprecedented scale, directed at both our products and hosting providers at the same time. As of today, it has been established that the attack was carried out using specialized AI-based tools. In particular, this is indicated by the presence of characteristic, AI-specific patterns, by comments left in the attacker’s scripts, and by the number of attacks, as well as by the fact that in different infrastructures a parallel process of selecting attack methods ran simultaneously, with the attacker’s behavior changing dynamically depending on the settings of a particular provider’s infrastructure, and by a number of other observations made in the course of studying the incident.
Today, AI-based tools are increasingly used to find vulnerabilities, including in widely used components: PHP, the Linux kernel, nginx, and PostgreSQL. Over recent weeks, both foundational components and application platforms have come under attack. The use of such tools substantially changes the requirements for how quickly software developers must respond to such threats. Of course, security is not a property of code written once, but a continuous process. AI does not cancel this process, but sets a higher tempo for it.
Security requires constant work; to prevent such situations, we will continue to release updates with strengthened protection mechanisms and to analyze infrastructures. The investigation will not be complete until we are sure that no persistence mechanisms or backdoors planted by the attacker remain in the affected environments.
We understand that this incident required additional effort from our customers and partners; we apologize, and we thank everyone who is helping with diagnostics and with verifying the fixes.
