El lunes cPanel publicó un parche de seguridad que, si gestionas hosting compartido, deberías haber leído antes de tomarte el café. Se trata del CVE-2026-58048, con una puntuación CVSS de 9.4, y el vector de ataque es tan absurdo que cuesta creerlo: renombrar una base de datos. Sí, esa operación rutinaria que haces cuando reorganizas un WordPress o limpias nombres en phpMyAdmin puede convertirse, en versiones sin parchear, en una escalada de privilegios hasta el contexto root de MySQL. Y desde ahí, según la propia documentación del proveedor, el camino hasta comprometer el sistema operativo del servidor no es teoria.
Lo que me preocupa no es solo el fallo en sí. Es lo que revela sobre cómo funciona el hosting compartido que millones de pymes pagan cada mes creyendo que están en un entorno aislado.
Un fallo en algo que nadie sospecha
Según el informe de Security Affairs, el problema está en el proceso interno de cPanel cuando renombra una base de datos: crea una copia de reemplazo, migra los datos, recrea permisos y código almacenado, y elimina la original. En algún punto de esa cadena, el modo SQL no se preserva correctamente, y los comandos acaban ejecutándose con privilegios administrativos completos en lugar de los limitados de la cuenta de hosting.
cPanel lo clasifica como escalada de privilegios. El registro CNA en CVE.org lo archiva bajo CWE-89, es decir, inyección SQL. Misma vulnerabilidad, dos etiquetas distintas, y ninguna de las dos explica con detalle qué payload concreto dispara el fallo ni qué modo SQL se rompe. Para un administrador de sistemas que tiene que decidir si parchear esta noche o esperar al fin de semana, esa ambigüedad no ayuda nada.
El requisito para explotarlo tampoco es el de un atacante de película: basta con una cuenta de cPanel autenticada con acceso a la función MySQL/MariaDB. En hosting compartido eso puede ser cualquier cliente del servidor. Piensa en ello: en una máquina donde conviven cincuenta webs de clientes distintos, cualquiera con panel activo y permisos de base de datos tiene, en teoría, una llave maestra si el servidor no está actualizado.
Lo que el comunicado no aclara
Hay un detalle que el advisory oficial no resuelve y que en entornos reales importa mucho: si las subcuentas Team User — esas credenciales limitadas que un titular de cuenta delega a un desarrollador externo — cuentan como titular autenticado a efectos de esta vulnerabilidad. Si la respuesta es sí, el radio de exposición se multiplica. Cuantos más accesos delegados tengas en un servidor compartido, más difícil es saber quién puede intentar explotar esto.
La CISA, según recogen varios medios, indica que no se han observado explotaciones activas y califica el fallo como no automatizable. Vale. Pero un CVSS de 9.4 mide el daño potencial si alguien lo usa, no cuánta gente tiene hoy mismo los permisos necesarios para probarlo. En un servidor compartido típico, esa población no es pequeña.
La medida temporal que propone cPanel — revocar la función MySQL a los usuarios del panel — es un parche de emergencia razonable, pero también es una admisión incómoda: si no puedes actualizar ya, tu opción es limitar funcionalidades básicas que tus clientes dan por hechas. Imagina explicarle a un cliente que no puede crear ni renombrar bases de datos porque el panel tiene un agujero crítico sin parchear. No suena a servicio premium, verdad?
Por qué esto no es solo problema de cPanel
En mi experiencia, la cadena de responsabilidad en hosting compartido es un juego de ping-pong. cPanel publica el advisory, el proveedor de hosting dice que está aplicando parches, y tú, como titular de la web, te enteras tres días después por un blog de seguridad o por un artículo como este. Mientras tanto, tu tienda WooCommerce sigue corriendo en un servidor donde un vecino virtual podría, en el peor escenario, leer o modificar cualquier base de datos del sistema.
Las versiones corregidas son concretas: 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. Si tu hosting no te ha dicho qué build lleva tu servidor, no asumas nada. Pregunta. Exige confirmación por escrito si gestionas datos de clientes.
Y si usas Plesk en lugar de cPanel, no te relajes: este CVE es específico de cPanel, pero la lógica es la misma. Los paneles de control concentran permisos, automatizan operaciones peligrosas y asumen que quien tiene acceso es de confianza. En hosting compartido, esa suposición falla con demasiada frecuencia.
Qué haría yo hoy
Si administras el servidor directamente, actualiza ya a una de las builds parcheadas. Si dependes de un proveedor, abre ticket hoy, no el viernes. Revisa qué subcuentas tienen acceso MySQL y elimina las que no sean estrictamente necesarias. Si puedes, separa entornos críticos de hosting compartido barato: un CVE así no distingue entre tu blog personal y la web de un cliente que procesa pagos.
Lo irónico es que renombrar bases de datos es una de esas tareas que casi nadie documenta en procedimientos de seguridad porque parece inofensiva. cPanel acaba de demostrar que las operaciones más aburridas son a veces las más peligrosas.
Si mañana descubres que tu proveedor de hosting lleva una semana sin parchear el CVE-2026-58048 y te ofrece un mes gratis a cambio de quedarte, te quedas o migras esa misma tarde?