Security Notice: VDS Management Platform Incident

On October 17, 2026, we detected suspicious activity on one node of our VDS management system. We immediately blocked the network resources involved in the attack, notified the platform vendor, and began investigating the incident.

The vendor confirmed that its product contained a vulnerability and prepared a series of security fixes, which we applied as soon as they became available. The vendor also notified relevant cybersecurity organizations about the zero-day vulnerability in one of its products. Some service functions have been restricted as a precaution while the investigation and additional checks continue.

Detailed technical information about the vulnerability will be published by the vendor later. Until that disclosure is available, we want to be clear about what may have been accessed, what was not affected, and what VDS customers should do now.

What may have been accessed

Based on our current assessment, the attacker may have obtained read-only access to metadata belonging to some virtual machines and to their disk images.

A virtual disk image contains the filesystem of a VDS. Depending on how a server is configured, that filesystem may include operating system files, application data, password hashes, configuration files, private SSH keys, API credentials, database passwords, certificates, and other secrets. We have not confirmed that every such item was accessed, but customers should treat credentials stored inside an affected virtual machine as potentially exposed.

The suspected access was read-only. This description reflects the information currently available and may be refined after the vendor publishes its technical analysis.

What was not affected

Our investigation indicates that the incident did not affect:

• backup servers;
• personal information held in the customer portal;
• billing details;
• services other than the affected virtualization management platform.

The separation of these systems is important here. Access to part of the virtualization management environment did not provide access to billing, customer account data, or backup infrastructure.

Measures already taken by ITLDC

After detecting the activity, we blocked the network resources used in the attack and worked with the vendor of the virtualization management system. We applied all vendor-provided fixes immediately.

As additional precautions, we restricted some non-essential service functions and reset customer passwords used for direct access to the virtualization management system.

This reset applies to direct platform access. It does not change the password inside your virtual server because only the server administrator can safely manage guest operating system credentials.

Automatic access from the ITLDC customer portal continues to work as before. Customers can open their VDS management interface through the portal without entering the former direct-access password.

What VDS customers should do now

Because disk images may have been readable, we strongly recommend taking the following steps even if your server appears to be operating normally.

1. Change the operating system password

Change the passwords of administrative and other important accounts inside the virtual server. Use new, unique passwords that are not shared with another server or service.

If the same password was used elsewhere, change it there as well. Replacing one copy does not make the other copies less exposed.

2. Rotate SSH keys stored on the VDS

If the virtual server stores private SSH keys used to connect to other systems, rotate them:

1. Generate a new key pair on a trusted system.
2. Install the new public key on every destination where access is required.
3. Verify that the new key works.
4. Remove the old public key from each destination and revoke the old key wherever applicable.
5. Securely remove the old private key from active systems and automation.

Do not revoke the old key before testing its replacement unless you already have another reliable access method. A careful rotation improves security; revoking the only working key merely produces a very secure lockout.

Also review deployment systems, scripts, CI/CD jobs, and agent configurations that may contain copies of the old key.

3. Rotate application and external-service credentials

Replace sensitive authentication data stored on the virtual server. This may include:

• API keys and access tokens;
• cloud and object-storage credentials;
• database passwords;
• credentials for external control panels and services;
• private keys used by applications;
• webhook secrets and signing keys.

Generate replacements first, update the applications that use them, verify normal operation, and then revoke the old credentials. Where a provider offers access logs or token activity history, review them for unexpected use.

The safest rule is simple: if a secret was stored unencrypted in the VDS filesystem, rotate it.

4. Check your backups

Confirm that you have current backups of all necessary data, that you can access them, and that they are stored in an independent location. A backup in the same failure domain as the production system is not sufficient for serious recovery scenarios.

Backups should always be encrypted, particularly when they contain complete filesystems, databases, configuration files, or customer data. Protect the encryption keys separately from the backup itself.

Finally, test a restore. A backup job reporting success confirms that files were written somewhere; a successful restore confirms that they can help you.

Security work continues

The immediate network blocks and vendor fixes are in place. We are continuing our review of the affected environment and will evaluate the vendor’s detailed technical report when it becomes available.

We understand that rotating credentials takes time, especially on servers connected to several external systems. It is nevertheless the appropriate precaution when read access to a disk image may have been possible. Start with operating system access and credentials that can reach other infrastructure, then continue with application secrets and lower-privilege accounts.

If you have difficulty accessing the VDS management interface or need clarification about your service, please contact ITLDC support through the customer portal.