DEV Community

kozhevniko
kozhevniko

Posted on

When the hosting provider becomes the trust anchor

#security #zoomeye #vmmanager #hosting

When the hosting provider becomes the trust anchor

A customer renting a virtual server delegates the layer below the operating system to the provider. The FirstVDS incident reported on 19 October 2026 shows what that delegation costs when the delegated layer is breached: passwords, cloud credentials and wallets were copied from customer disks without the virtual machines themselves being compromised.
The interesting design question is not how the intruder entered VMmanager 6. It is why a hosting customer had cloud credentials and wallet keys sitting on a disk that someone else's management plane could mount.

What the provider controls

The provider controls the hypervisor, the storage backend and the management platform that ties them together. It also controls the audit trail for operations at that layer, which decides whether a disk attach is visible to anyone. None of these are usually in the customer's contract in specific terms.
A customer can influence them at three points: the choice of provider, the contract terms covering management-plane access, and the architecture of the workload itself. The third point is the only one fully under the customer's control, and it is the one most often skipped.

Designing for a management plane you do not own

The principle that follows from this incident is that a server disk should not hold anything whose disclosure is unrecoverable. Private keys for cryptocurrency wallets fit that description exactly, because a copied key cannot be revoked. Cloud API keys fit it partly, because they can be revoked if the owner learns quickly enough.
Credentials that must be present on the host can be narrowed in scope and lifetime. Short-lived tokens issued to the workload, scoped to a single resource, limit what a copied disk yields after the token expires. Secrets that cannot be narrowed, such as long-lived wallet keys, belong on hardware the customer physically controls or in a signing service that never exports the key.

What the contract should cover

Three clauses are worth negotiating. The first is notification: what the provider commits to disclose, to whom, and in what timeframe, when the management plane is breached. FirstVDS notified customers and told the recipients to assume their data had been stolen, which is the right instruction and also an admission that per-tenant scoping was impossible.
The second is audit visibility: whether the customer can obtain records of management actions affecting their instance, including disk-level operations. The third is isolation: whether the management plane is reachable from the tenant network or from the public internet at all.

The vendor side of the same question

ISPsystem, the platform vendor, published interim guidance on 20 October asking customers to block inbound and outbound connections to the platform and to the virtualisation nodes, to restrict SSH to trusted addresses and to rotate all passwords. That guidance is aimed at operators, and it works only if operators pass the relevant parts down to their own customers.
A hosting provider that quietly applies the patch and says nothing leaves its tenants holding compromised credentials. Telling tenants which secrets were exposed, at the granularity the provider actually has, is the part of incident response that determines the outcome for them.

Measuring the population that faces this

The exposure measurement is crude but useful for scale. On 27 October 2026, ZoomEye matched 2,823 interfaces for title="VMmanager", with 1,035 in Russia and 1,788 elsewhere. That suggests a large number of businesses depend on the same delegated trust model, in many jurisdictions, and that a customer wanting audit visibility is asking for something unusual rather than standard.

References

Top comments (0)