The Virtualizor Support Ticket Incident: Why Root Passwords Should Never Be Stored

A February 2026 security incident involving a Virtualizor support system highlighted one of the hosting industry's oldest security problems: support platforms becoming accidental storage locations for customer credentials.

According to Virtualizor's own security update, unauthorized access to its support ticket system exposed approximately 1,500 historical support tickets. Virtualizor reported that some of those tickets contained sensitive information, including plaintext root credentials that customers had previously shared while requesting assistance. The company stated that the incident involved the support system and was not caused by a vulnerability in the Virtualizor software itself. 1

The important lesson is not limited to one platform or one provider.

The problem is that support systems often contain years of customer data that was never intended to become a permanent security record.

Support desks are overlooked security systems

Many hosting providers accumulate the same type of information over time.

Root passwords pasted while troubleshooting an issue. SSH keys attached during a migration. API tokens included in error messages. Database exports uploaded to reproduce a problem.

The ticket gets closed. The issue is resolved. The customer moves on.

But the data often remains stored in ticket databases, backups, attachments and internal archives.

A support system's security exposure is closely tied to every secret that customers have shared through it. For many providers, that history contains more sensitive information than they realize.

Never send permanent credentials to support

Customers should treat credentials submitted through support tickets as potentially compromised.

That includes:

• root passwords
• administrator passwords
• API keys
• private keys
• database credentials
• control panel passwords
• temporary passwords created for troubleshooting

If a credential has already been shared, rotate it.

The safer approach is temporary access:

• create a temporary support account
• provide limited permissions
• revoke access afterwards
• use console access when SSH is unavailable

A provider should be able to troubleshoot your service without needing your permanent login credentials.

What hosting providers should change

The responsibility does not only belong to customers.

Providers should assume that sensitive information may exist inside historical tickets and take steps to reduce the impact.

Good practices include:

• scanning old tickets for credential-like data
• removing unnecessary attachments after retention periods expire
• protecting support systems with strong authentication controls
• limiting employee access to customer data
• documenting credential handling policies

A support platform should be treated as a production security system. It contains customer information, operational details and potentially authentication material.

Access without credentials

At AVS ISP, we do not ask customers to send root passwords.

Our VPS and VDS services include browser-based noVNC console access through the client area. If SSH access is unavailable because of a firewall mistake, broken configuration, failed update or another system issue, customers can access the machine directly without sharing a permanent credential.

When support assistance is needed, the goal is to help customers diagnose the problem without creating another copy of their secrets.

Our VPS infrastructure uses KVM-based virtualization, providing hardware-assisted virtualization boundaries enforced by the hypervisor rather than relying only on operating-system-level isolation.

Support conversations should contain troubleshooting information, not passwords.

If you have ever sent credentials to any hosting provider, including us, the safest action is the same: rotate them.

Ransomware turns poor backup design into permanent loss

The most damaging part of ransomware incidents is often not the initial compromise.

It is the loss of recovery options.

If attackers can access production systems and the backups accessible from them, an outage can become permanent data loss.

A real backup strategy requires separation:

• separate credentials
• separate systems
• separate failure domains
• preferably separate physical locations

A backup that is stored in the same environment and protected by the same credentials as production is not an independent recovery copy.

AVS ISP operates infrastructure across multiple locations and offers additional VPS locations for customers who want geographic separation. However, the principle applies everywhere: customers should maintain backups they control, not only copies that exist inside their hosting provider's environment.

The wider lesson for hosting

The lesson from incidents like this is simple:

Security is not only about firewalls, hypervisors and network protection.

It is also about ordinary operational habits.

A password copied into a support ticket today can become a security incident years later.

Hosting providers should design systems assuming that customers will make mistakes. Customers should choose providers that make those mistakes less dangerous.

The best support ticket is one that solves the problem without ever containing a secret.

Frequently Asked Questions

Should I give a VPS provider my root password?

No. A hosting provider should not require permanent credentials. Temporary access methods, console access, or limited accounts are safer.

Are support tickets a security risk?

Yes. Support tickets often contain logs, configuration details, credentials and customer information that may remain stored for years.

What should I do if I sent my password to hosting support?

Change it immediately. Rotate any related keys, tokens or credentials that may have been included.

Sources

1. Security Update: Transparency Regarding a Recent Support Ticket Incident, Virtualizor (February 3, 2026) — primary source
2. Mass VPS Provider Ransomware Attack Linked to Stolen Credentials from Virtualizor Support Breach, Cyber Kendra (February 2026) — independent reporting