El incidente de los tickets de Virtualizor: por qué las contraseñas de root no deben guardarse nunca
Un incidente de seguridad de febrero de 2026 que afectó a un sistema de soporte de Virtualizor puso el foco en uno de los problemas de seguridad más antiguos del sector del hosting: las plataformas de soporte acaban convertidas, sin querer, en almacenes de credenciales de clientes.
Según el propio aviso de seguridad de Virtualizor, un acceso no autorizado a su sistema de tickets expuso alrededor de 1500 tickets antiguos. La empresa informó de que algunos contenían información sensible, incluidas credenciales de root en texto plano que los propios clientes habían pegado al pedir ayuda. Virtualizor señaló que el incidente afectaba al sistema de soporte y que no se debía a una vulnerabilidad del software Virtualizor. 1
La lección importante no se queda en una plataforma ni en un proveedor.
El problema es que los sistemas de soporte suelen acumular años de datos de clientes que nunca se pensaron como un archivo de seguridad permanente.
El soporte es un sistema de seguridad al que nadie mira
Muchos proveedores de hosting acumulan con el tiempo el mismo tipo de información.
Contraseñas de root pegadas mientras se diagnosticaba una avería. Claves SSH adjuntadas durante una migración. Tokens de API dentro de mensajes de error. Volcados de bases de datos subidos para reproducir un fallo.
El ticket se cierra. El problema queda resuelto. El cliente sigue con lo suyo.
Pero los datos a menudo se quedan ahí: en la base de datos de tickets, en copias de seguridad, en adjuntos y en archivos internos.
La exposición de un sistema de soporte está directamente ligada a cada secreto que los clientes han pasado por él. En muchos proveedores, ese historial guarda más cosas sensibles de lo que creen.
No envíes nunca credenciales permanentes al soporte
Da por comprometida cualquier credencial que hayas enviado en un ticket.
Eso incluye:
- contraseñas de root
- contraseñas de administrador
- claves de API
- claves privadas
- credenciales de bases de datos
- contraseñas del panel de control
- contraseñas temporales creadas para diagnosticar
Si ya has compartido una credencial, cámbiala.
Lo seguro es dar acceso temporal:
- crea una cuenta temporal para el soporte
- dale permisos limitados
- revoca el acceso al terminar
- usa la consola cuando SSH no esté disponible
Un proveedor debería poder diagnosticar tu servicio sin necesitar tus credenciales permanentes.
Qué deberían cambiar los proveedores de hosting
La responsabilidad no es solo del cliente.
Los proveedores deberían asumir que en los tickets antiguos hay información sensible y actuar para reducir el daño.
Buenas prácticas:
- revisar tickets antiguos en busca de datos que parezcan credenciales
- borrar adjuntos innecesarios cuando venza el plazo de conservación
- proteger el sistema de soporte con autenticación robusta
- limitar el acceso del personal a los datos de clientes
- documentar las políticas de manejo de credenciales
Una plataforma de soporte hay que tratarla como un sistema de seguridad en producción. Contiene datos de clientes, detalles operativos y, posiblemente, material de autenticación.
Acceso sin credenciales
En AVS ISP no pedimos a nadie que nos envíe su contraseña de root.
Nuestros servicios VPS y VDS incluyen consola noVNC desde el navegador, dentro del área de cliente. Si SSH no está disponible por un error en el cortafuegos, una configuración rota, una actualización fallida u otro problema del sistema, entras directamente a la máquina sin compartir ninguna credencial permanente.
Cuando hace falta ayuda del soporte, el objetivo es ayudarte a diagnosticar sin crear otra copia de tus secretos.
Nuestra infraestructura VPS usa virtualización KVM: las fronteras de aislamiento las impone la virtualización asistida por hardware a nivel de hipervisor, no solo el aislamiento del sistema operativo.
En una conversación con soporte debe haber diagnóstico, no contraseñas.
Si alguna vez has enviado credenciales a cualquier proveedor de hosting, incluidos nosotros, lo más seguro es lo mismo: cámbialas.
El ransomware convierte un mal diseño de copias en pérdida definitiva
Lo más destructivo de un ataque de ransomware no suele ser la intrusión inicial.
Es perder las opciones de recuperación.
Si el atacante llega a los sistemas de producción y a las copias accesibles desde ellos, una caída se convierte en pérdida definitiva de datos.
Una estrategia de copias de verdad exige separación:
- credenciales separadas
- sistemas separados
- dominios de fallo separados
- a poder ser, ubicaciones físicas separadas
Una copia que vive en el mismo entorno y está protegida por las mismas credenciales que producción no es una copia de recuperación independiente.
AVS ISP opera infraestructura en varias ubicaciones y ofrece más ubicaciones de VPS a quien necesite separación geográfica. Pero el principio vale en todas partes: conviene tener copias que controles tú, no solo copias dentro del entorno de tu proveedor de hosting.
La lección de fondo para el hosting
La conclusión de incidentes así es simple:
La seguridad no va solo de cortafuegos, hipervisores y protección de red.
También va de costumbres de trabajo corrientes.
Una contraseña copiada hoy en un ticket se convierte años después en un incidente de seguridad.
Los proveedores deberían diseñar sus sistemas asumiendo que los clientes se equivocarán. Y los clientes, elegir proveedores donde esos errores sean menos peligrosos.
El mejor ticket de soporte es el que resuelve el problema sin haber contenido jamás un secreto.
Preguntas frecuentes
¿Debo dar mi contraseña de root al proveedor del VPS?
No. Un proveedor de hosting no debería exigir credenciales permanentes. El acceso temporal, la consola o las cuentas limitadas son más seguros.
¿Los tickets de soporte son un riesgo de seguridad?
Sí. En los tickets acaban registros, detalles de configuración, credenciales y datos del cliente, y ahí se quedan durante años.
¿Qué hago si envié mi contraseña al soporte del hosting?
Cámbiala de inmediato. Y cambia también las claves, tokens y credenciales relacionadas que pudieran haber ido en el mismo mensaje.
Fuentes
- Security Update: Transparency Regarding a Recent Support Ticket Incident, Virtualizor (3 de febrero de 2026) — fuente primaria
- Mass VPS Provider Ransomware Attack Linked to Stolen Credentials from Virtualizor Support Breach, Cyber Kendra (febrero de 2026) — información independiente