FirstVDS told affected customers to change passwords and access credentials after the VMmanager 6 incident it disclosed on 19 October 2026. The list of copied data explains why a password reset is not the whole job: the intruder took cloud service credentials, configuration files and cryptocurrency wallets along with local passwords.
Rotation advice is easy to issue and hard to execute. The order matters, and so does knowing which secrets were stored where.
The credential types were not equal
Local passwords, cloud API keys, registry credentials, cryptocurrency private keys and SSH keys have different blast radii. A local password exposes one server. A cloud service credential may expose an entire account, including the ability to create new resources and to read stored secrets. A private key stored on a disk that was copied is compromised permanently, because the copy exists outside any system the owner can revoke.
Resetting the weakest credential first and the strongest last inverts the useful order. The high-privilege cloud credentials should move first, and any credential that cannot be revoked, such as a raw private key, should be treated as spent rather than changed.
Find where the secrets actually live
The reason rotation projects stall is that nobody has an accurate list. Secrets accumulate in environment files, deployment scripts, CI configuration, backup archives and application databases. A disk-level copy takes all of them, including copies that were never meant to be visible from the running service.
Before rotating, build the inventory from the disk itself rather than from documentation. Grep for the usual patterns, then confirm each hit against the service that uses it. An embedded key that nobody recognises is not a false positive; it is an unowned credential that the previous owner never documented.
Rotation order that limits re-entry
An attacker who held the management plane could read the configuration that the platform used to reach the rest of the environment. Revoking that platform-level access first removes the attacker's route back in. Then rotate the credentials for services that the panel could reach, then the credentials belonging to the tenants, then the human administrator accounts with their multi-factor enrolment.
Skipping the middle steps is a common failure. Rotating the tenant password while the service-to-service credential stays valid leaves the same door open under a different name.
Prove the change took effect
A rotation is not complete until the old credential fails. Test each one: attempt authentication with the retired value from a host outside the affected estate and confirm the rejection. For cloud keys, check the provider's audit log for any use of the old key after the rotation timestamp. Two things are usually discovered at this point: automation that still uses the retired credential, and a second copy nobody knew about.
This is also where a short-lived credential model earns its place. Credentials that expire in hours reduce the value of a disk copy, because what was captured is already stale by the time anyone reads it.
The perimeter step that buys time
ISPsystem asked 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 immediately. The first two instructions buy the time the third one needs. Closing the interface before the rotation starts means an attacker who already holds platform access cannot observe the new credentials as they are applied.
On 27 October 2026 the ZoomEye query title="VMmanager" matched 2,823 interfaces that answer publicly, with 1,592 of them on port 443. Each of those is an installation where the perimeter step may not have been taken, and where the rotation workload is still pending.
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 query
title="VMmanager", 27 October 2026. Counts describe matching interfaces, not confirmed vulnerable installations.