VMmanager control planes share port 443 with the sites they manage
Of the 2,823 VMmanager interfaces that answered publicly on 27 October 2026, 1,592 responded on port 443. That is more than half the population serving an administration login on the same port the hosting business uses for customer websites, and it shapes what a firewall change looks like in practice.
Port distribution
| Query | Matching assets |
|---|---|
title="VMmanager" |
2,823 |
title="VMmanager" && port="443" |
1,592 |
title="VMmanager" && port="8443" |
15 |
title="VMmanager" && port="8080" |
1 |
The remaining assets either answer on other ports or were recorded without a port match in the scan. The concentration on 443 is the part worth planning around.
One port, two jobs
A control panel that shares 443 with tenant websites creates a conflict for whoever writes the firewall rule. Blocking the port protects the panel and simultaneously removes customer sites, which generates support load and commercial pressure. Adding an address allowlist to the panel instead keeps the port open and narrows who can reach the login. The second option costs less, which is why it is often the one that gets done.
The vendor's own guidance anticipated this conflict. ISPsystem asked customers to configure infrastructure firewalls to block inbound and outbound connections to the VMmanager platform and to the virtualisation nodes, allowing access only to trusted administrators and vendor support. An outbound block is unusual, and it interrupts update delivery and licence checks as well as attacker traffic. Operators who applied it on 20 October were choosing a short outage over continued exposure.
Verifying the change from outside
The measurement gives a way to confirm the rule actually took effect. Run the title query against your own ranges before the change and again afterwards. A panel that disappears from public results is evidence the inbound rule works. A panel still visible after the change suggests the rule is incomplete or the scan read a cached response. Record the query, the timestamp and the count for each round so the comparison is defensible in a later review.
This check does not replace reading the firewall configuration. It catches the case where the intended rule and the deployed rule diverge, which is common when several teams maintain the same perimeter.
Segmenting the management plane properly
Restricting SSH to trusted addresses and rotating local passwords were the other two steps the vendor listed, and both work better when the management plane sits on its own network segment. A panel reachable only from an administrative VLAN is not visible to a scan at all, so the problem of a shared port disappears rather than being managed. For hosting businesses with several offices, that segment also becomes the place to enforce multi-factor authentication for administrators instead of applying it per service.
The transition takes planning. Existing customer-facing configuration may assume the panel is reachable from the internet, and monitoring or backup jobs may authenticate to it from outside. Mapping those dependencies before the firewall change is cheaper than discovering them during it.
What the port count adds
The 1,592 figure is not a vulnerability count. It measures how many interfaces are exposed on the port most likely to be kept open for unrelated reasons. For an operator trying to argue for a segmentation project, that is a concrete number to bring to the discussion, and it can be reproduced with a single query on any future date.
References
- The Record, "Hackers steal customer data from major Russian hosting provider FirstVDS", 19 October 2026. https://therecord.media/russia-cyberattack-firstvds-cloud
- ISPsystem, "Security Incident Involving a Vulnerability in a VMmanager 6 Build", 20 October 2026. https://www.ispsystem.com/news/vulnerability-incident
- ZoomEye queries executed 27 October 2026. Counts describe reachable management interfaces, not confirmed vulnerable installations.
Top comments (0)