Virtualmin's 25,656 app matches make a host control plane an inventory problem
Virtualmin manages virtual servers, mail, DNS, databases, SSL, backups, and users. A single exposed instance can concentrate authority over many hosted sites. That makes the product interesting in a ZoomEye dataset even before a specific vulnerability is known.
The count-only observation on 2026-11-09 at 18:44 UTC used sub_type=all, page 1, and page size 1. app="Virtualmin" returned 25,656. title="Virtualmin" returned 25,586. The two counts are close, which suggests a consistent application fingerprint, but the result is still an exposure count and not a list of vulnerable installations.
Search link for the selected query: ZoomEye app="Virtualmin".
Start with the public control plane
Virtualmin's remote API uses the same authentication system as the web interface. The documentation recommends POST because GET requests can expose command-line parameters in URLs. That guidance is a useful test of the deployment: if API calls appear in access logs with secrets in the query string, the logging and proxy configuration need review.
Restrict the administrative interface to an allowlisted network or a trusted access gateway. If it must be public, require TLS, strong authentication, and a second factor. Confirm the versions of Virtualmin, Webmin, the theme, and installed modules. Track updates through the supported package path rather than a manual file replacement.
Keep administrative and hosted-user authority separate
A hosting panel often has a master administrator and many domain owners. Review which users can log in to Virtualmin, which can use the remote API, and which can create login links. A link that grants temporary access should have a clear recipient, purpose, and expiry.
Test a domain owner's view against another domain's mail, database, and file permissions. Check the MySQL/MariaDB grants after a domain is moved or deleted. Review backup access, because a backup can contain mail, databases, keys, and configuration that are more sensitive than a website.
Use the count for ownership and coverage
The 25,656 app matches can support a broad exposure baseline. Split the set by country or ASN only if that comparison answers an operational question. Do not infer vulnerability from the product name or count. Validate a candidate with a controlled request, then compare it with DNS and hosting inventory.
Prioritize instances with public administrative ports, outdated components, no second factor, or credentials shared across hosting customers. Keep a record of the control plane owner and the sites it serves. The larger the instance, the more important it is to know who can reach the panel before a vulnerability becomes public.
Evidence limits
The near-identical app and title counts do not prove a single version or a consistent security posture. The page may be a login, a default installation, or a custom branded portal. Use ZoomEye to find the population and the product team to confirm which systems are in scope.
Top comments (0)