Cualquier cliente de hosting compartido con cPanel podía tomar control root de la base de datos completa — ya hay parche

La premisa básica del hosting compartido es que tu cuenta y la del vecino que paga el mismo plan que tú están aisladas entre sí, aunque vivan en el mismo servidor físico. CVE-2026-58048, divulgada oficialmente el 4 de agosto con un puntaje de severidad de 9.4 sobre 10 (crítico), rompía exactamente esa premisa dentro de cPanel & WHM, el panel de administración de hosting más usado del mundo — y lo hacía sin que el atacante necesitara ningún privilegio especial: cualquier titular de una cuenta cPanel estándar, con acceso a la función de MySQL/MariaDB que trae cualquier plan básico, podía ejecutar comandos SQL con privilegios de administrador total sobre la base de datos del servidor completo, no solo la suya.

El mecanismo técnico está en el proceso que usa cPanel cuando alguien renombra una base de datos: el sistema construye una base de reemplazo, mueve los datos, recrea los permisos y el código almacenado, y finalmente elimina la original. En algún punto de ese proceso, el "modo SQL" —una configuración que determina cómo se interpretan y validan los comandos— no se preservaba correctamente, lo que permitía que comandos SQL se ejecutaran en el contexto de la cuenta root de la base de datos en vez del contexto limitado de la cuenta del cliente. En la práctica: un cliente de hosting compartido sin ningún permiso especial podía terminar con control total sobre todas las bases de datos del servidor, y según la propia advisory de cPanel, dependiendo de la configuración del sistema operativo y del motor de base de datos, ese control podía extenderse incluso a nivel de sistema operativo completo.

La falla afecta a todas las versiones soportadas de cPanel & WHM, además de WP Squared. Los parches ya están disponibles en las versiones 11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48, 11.136.0.32, y 138.1.6 para WP Squared. CISA, la agencia de ciberseguridad de Estados Unidos, reportó el mismo día de la divulgación que no había evidencia de explotación activa observada hasta ese momento, y calificó la falla como "no automatizable" en su clasificación de riesgo — pero mantuvo el impacto técnico potencial en el nivel máximo, precisamente porque no hace falta automatización masiva cuando el punto de entrada es una cuenta de cliente legítima que cualquiera puede comprar.

Vale la pena conectar esto con algo que ya escribimos aquí hace unos días: 44.000 servidores con cPanel terminaron comprometidos por el ransomware Sorry meses después de que existiera parche disponible para la falla que lo hizo posible, precisamente porque nadie actualizó a tiempo. Esta nueva falla llega apenas unos meses después de aquella, en el mismo software, y el patrón de riesgo es idéntico: el parche existe, la ventana entre "existe la corrección" y "todos los servidores la aplicaron" es exactamente el momento en que cualquier vulnerabilidad de este tipo se vuelve peligrosa de verdad, sin importar qué tan compleja sea de explotar en el papel.

Si administras un servidor con cPanel, la acción es simple y no admite postergarla: confirma tu versión actual y actualiza a una de las versiones corregidas de inmediato. Si por alguna razón no puedes aplicar el parche en este momento, cPanel recomienda como mitigación temporal revocar la función de MySQL a las cuentas de cliente que no la necesiten estrictamente, para reducir quién puede siquiera intentar la operación de renombrado que dispara el problema. Si eres cliente de un plan de hosting compartido y no administras el servidor tú mismo, no hay nada técnico que puedas hacer directamente — pero preguntarle a tu proveedor si ya aplicó este parche específico es una pregunta razonable, sobre todo sabiendo que la cuenta que podía explotar esta falla podía ser, literalmente, cualquiera con acceso al mismo servidor que tú.