cPanel CVE-2026-58048: en el hosting compartido, el riesgo lo pone el vecino

El 31 de julio se publicaron dos fallos de cPanel & WHM. El que se ha llevado los titulares es CVE-2026-58048, un 9,4 sobre 10: renombrando una base de datos, un cliente normal del servidor podía acabar ejecutando SQL en el contexto de root. Pero el número que de verdad describe el problema no es el 9,4. Está al final del vector, donde casi nadie mira: SC:H/SI:H/SA:H.

Escribimos sobre esto porque es un caso de manual de algo que se discute poco y se sufre bastante: en una máquina compartida, tu superficie de ataque incluye a gente que tú no has elegido. No es una crítica al alojamiento compartido —luego llegamos a esa pregunta, y la respuesta no es la que se espera—. Es que el modelo de amenaza es distinto, y este par de CVE lo dejan por escrito con una precisión poco habitual.

El fallo, en una frase de la propia ficha

La descripción oficial cabe en un renglón: «conservación incorrecta del modo SQL al renombrar bases de datos en cPanel permite la ejecución de SQL en el contexto de root». Está clasificado como CWE-89, inyección SQL, y el crédito es de Vincent55 Yang.

Renombrar una base de datos no es una operación atómica. Según la documentación de cPanel, recogida por The Hacker News, al renombrar el sistema «crea una base de datos de reemplazo, mueve los datos originales, recrea los permisos y el código almacenado y después elimina la antigua». Es una secuencia larga de SQL que el panel ejecuta por ti, con sus privilegios, a partir de un nombre que tú escribes.

Lo que hace falta para llegar ahí es lo interesante. El vector publicado dice PR:L: privilegios bajos, no ninguno. Hace falta una cuenta válida en el servidor y permiso para usar la función de MySQL o MariaDB. Dicho de otra manera: en un servidor de alojamiento compartido, el requisito previo del ataque es un formulario de alta. Y UI:N: no hace falta que nadie pinche en nada.

La cola del vector: donde CVSS 4.0 dice «esto sale de aquí»

El vector completo es CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Los tres primeros impactos (VC, VI, VA) hablan del sistema vulnerable. Los tres últimos (SC, SI, SA) hablan del sistema posterior: lo que hay al otro lado del componente que falla.

Esa separación es la aportación de CVSS 4.0 que menos se usa y más dice. La especificación pide lo contrario por defecto: «cuando una vulnerabilidad no tiene impacto fuera del sistema vulnerable, quien la evalúa debería dejar las métricas de sistema posterior en NINGUNO». Aquí no están en ninguno, están las tres en High. Dónde acaba un sistema y empieza el siguiente es un juicio, no un hecho —la propia especificación pone el ejemplo de una base de datos que solo usa un altavoz inteligente y que, por tanto, es parte del altavoz—, así que el vector solo, en abstracto, no cierra la discusión. Pero es que el fabricante la cierra sin métricas: sobre este fallo dice que «esto puede extenderse a un compromiso a nivel de sistema operativo».

Y en una máquina compartida, «el sistema posterior» tiene nombre y apellidos. Es el CRM de la asesoría del segundo, la tienda del fabricante de al lado y tu web. La palabra «posterior» es muy fría para lo que describe: el sistema posterior es el de otro.

El CVE de 5,6 que lo dice todavía más claro

El mismo día, el mismo investigador y la misma tanda de parches trajeron CVE-2026-58047: «HTTP smuggling en cPanel permite una posible filtración de credenciales», clasificado como CWE-444, en cpsrvd, el demonio que sirve las interfaces de cPanel y WHM. Puntúa 5,6: medio. Nadie va a abrir una ventana de emergencia por un 5,6.

Ahora su vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:H/SI:H/SA:L. Léelo entero, que es de lo que va este artículo. Sin autenticar (PR:N), pero con dos frenos que el propio vector declara: AT:P, hacen falta condiciones del despliegue que el atacante no controla, y UI:P, alguien tiene que estar usando el panel en ese momento. The Hacker News lo resume en tres palabras: under limited conditions. Y ahora los impactos: bajo en el sistema vulnerable (VC:L/VI:L), alto en el posterior (SC:H/SI:H). Traducido: hace poco daño donde entra y mucho daño a un tercero —a quien se le devuelve la respuesta contaminada, que es otro usuario del mismo servidor—.

Aquí el fabricante nos ahorró la decisión: los dos registros listan exactamente las mismas versiones y la misma tanda de builds cierra los dos fallos. Pero llegan por separado muy a menudo, y entonces un criterio de parcheo que filtra por «críticos» se lleva el 9,4 y deja el 5,6 para el mes que viene —y el 5,6 es el que no pide cuenta de cliente—. La severidad global mezcla en un solo número «cuánto cuesta llegar» y «cuánto daño hace»; en multi-tenant esas dos cosas no van juntas, y ordenar la cola de parcheo por el número grande es ordenarla por la primera cuando lo que te preocupa es la segunda.

Lo que el aviso NO dice (y conviene no inventarse)

Toca bajar el pulso. El enriquecimiento de CISA sobre ambos CVE, con fecha del 31 de julio, registra explotación: ninguna y automatizable: no. Ninguno de los dos está, a día de hoy, en el catálogo de vulnerabilidades explotadas. No hay una campaña en marcha.

Con un matiz que se malinterpreta a menudo: «automatizable: no» no significa «difícil». Significa que el atacante no puede recorrer internet lanzando el mismo payload a ciegas, porque antes necesita una cuenta en ese servidor. En un panel de alojamiento, ese paso previo tiene un precio de tarifa. Es una barrera económica, no técnica, y las barreras económicas bajan cuando el objetivo sube de valor. Sobre el impacto técnico, en cambio, el registro de CISA no matiza nada: lo clasifica como total para el 9,4.

Qué comprobar esta semana

• En qué build estás. Las versiones corregidas son 11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48 y 11.136.0.32, más 11.138.1.6 para WP Squared. Cinco ramas vivas de cPanel a la vez, y la misma tanda cierra los dos CVE: así de repartido está el parque entre los tiers LTS, STABLE, RELEASE y CURRENT.
• Que el reloj de seguridad esté corriendo. La buena noticia primero: por defecto, el sistema aplica cada hora, mediante una tarea programada, las actualizaciones de seguridad de tu versión mayor, y lo hace incluso si has desactivado las actualizaciones de versión o las has puesto en manual. La letra pequeña, en la misma frase de la documentación de WHM, es la que importa: ese cron no se ejecuta si el servidor está fijado a una versión concreta. Es decir, la máquina que alguien clavó en una build hace años para que «no se rompiera nada» es exactamente la que no se está parcheando sola. Comprobarlo cuesta un minuto.
• Si no puedes actualizar hoy, la mitigación del 9,4. Revocar la funcionalidad «MySQL» a las cuentas de cPanel. La propia nota lo acota con honestidad: «esto no deshabilita las bases de datos existentes, solo impide añadirlas o eliminarlas». Los sitios siguen funcionando y desaparece el camino del ataque.
• Y la del 5,6, que casi nadie menciona. Desactivar la reutilización de conexiones de backend con cpsrvd_keepalives_disabled=1 en /var/cpanel/cpanel.config. No es gratis: obliga a una conexión TCP y TLS nueva por petición en los puertos 2083, 2087 y 2096, con más latencia y más CPU en servidores cargados. Si el post te ha convencido de que el 5,6 es el que más te afecta como vecino, esta es la casilla que lo demuestra.
• La pregunta que casi nadie sabe responder. ¿En qué servidor está tu web y quién más está en él? No es una pregunta retórica: en muchas empresas, el alojamiento se contrató hace ocho años, lo gestiona la agencia que hizo el diseño y nadie de dentro tiene acceso al panel. Si nadie sabe contestar, ese es el hallazgo del día, y no el CVE.

Esa última pregunta ya la hemos hecho aquí desde otro ángulo, cuando hablamos de quién mantiene de verdad tu WordPress. Cambia el producto, no cambia el vacío: la web de la empresa es, en muchas organizaciones, el único sistema de producción sin dueño interno.

La parte incómoda: ¿hay que salir del compartido?

Aquí es donde tocaría el párrafo de vender. No lo vamos a escribir, porque sería falso. Para muchísimos sitios, el alojamiento compartido es la decisión correcta, y la seguiría siendo mañana: una web corporativa estática, un blog, una landing. Sacarlos de ahí es pagar más por gestionar más y dormir exactamente igual de bien.

Lo que sí cambia es qué puedes prometer. En compartido no controlas el vecindario: no eliges quién más tiene cuenta, no auditas su código y no decides cuándo se parchea la máquina. Eso no es una anomalía ni un defecto del proveedor; es literalmente lo que estás comprando cuando el precio se divide entre trescientos. El error no es contratarlo: el error es contratarlo y luego prometer a un cliente, o a un auditor, un aislamiento que ese modelo nunca ofreció.

Nuestro criterio, después de años montando infraestructura para aplicaciones de negocio, cabe en una pregunta: ¿qué hay dentro de la base de datos? Si son entradas de blog, adelante. Si son datos personales de clientes, pedidos, historial médico o el catálogo con precios de compra, el aislamiento deja de ser una cuestión de rendimiento y pasa a ser una cuestión de a quién le tienes que responder. Cuando entran obligaciones de por medio —y la lista de quién queda dentro se ha ampliado bastante—, «estaba en un compartido» no es una respuesta que se sostenga en un cuestionario de proveedor.

El patrón que se repite: la superficie que no elegiste

Hace unos días escribimos sobre un fallo de Rails que en realidad estaba en una biblioteca de imágenes que nadie había elegido conscientemente. Este es el mismo animal, un piso más abajo: el riesgo no entra por el código que encargaste, sino por lo que vino debajo. Allí era una dependencia; aquí es un vecino.

Y en los dos casos la defensa útil es la misma, y es aburrida: saber qué tienes debajo antes de que alguien publique un CVE sobre ello. No hay herramienta que lo resuelva. Hay un inventario y hay un responsable.

Si quieres que miremos dónde vive de verdad tu aplicación, qué hay en su base de datos y qué aislamiento necesita —o si no necesita ninguno, que también pasa—, eso es parte de lo que hacemos en datos y aplicaciones; y cuando la respuesta pasa por hierro propio en centro de datos, en colocation.

Fuentes (verificadas el 7 de agosto de 2026): el identificador, la descripción literal («conservación incorrecta del modo SQL al renombrar bases de datos en cPanel permite la ejecución de SQL en el contexto de root»), la clasificación CWE-89, el vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H con puntuación 9,4 CRÍTICA, la fecha de publicación (31 de julio de 2026), el crédito a Vincent55 Yang, las versiones afectadas y las corregidas (11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48, 11.136.0.32 y WP Squared 11.138.1.6) y el enriquecimiento SSVC de CISA (explotación: ninguna; automatizable: no; impacto técnico: total) proceden del registro oficial de CVE-2026-58048, asignado por HackerOne como CNA, consultado en la API de MITRE. Los mismos datos para CVE-2026-58047 («HTTP smuggling en cPanel permite una posible filtración de credenciales», CWE-444, vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:H/SI:H/SA:L, 5,6 MEDIO, impacto técnico: parcial). Que cpsrvd es el demonio que sirve las interfaces de cPanel y WHM, la descripción del proceso de renombrado atribuida a la documentación de cPanel («crea una base de datos de reemplazo, mueve los datos originales, recrea los permisos y el código almacenado y después elimina la antigua»), la frase del fabricante «esto puede extenderse a un compromiso a nivel de sistema operativo», el «under limited conditions» del segundo fallo y su mitigación (cpsrvd_keepalives_disabled=1 en /var/cpanel/cpanel.config, que fuerza conexión TCP y TLS nueva por petición en los puertos 2083, 2087 y 2096, con su coste en latencia y CPU) proceden de la cobertura de The Hacker News. La mitigación temporal de revocar la funcionalidad MySQL («no deshabilita las bases de datos existentes, solo impide añadirlas o eliminarlas») consta ahí y en Security Affairs. La distinción entre sistema vulnerable y sistema posterior, la frase «cuando una vulnerabilidad no tiene impacto fuera del sistema vulnerable, quien la evalúa debería dejar las métricas de sistema posterior en NINGUNO» y el ejemplo de la base de datos que solo usa un altavoz inteligente, del documento de especificación de CVSS v4.0 de FIRST. Que por defecto el sistema aplica cada hora, mediante una tarea programada, las actualizaciones de seguridad de la versión mayor actual, que ese cron se ejecuta aunque se desactiven las actualizaciones de versión o se pongan en manual, y que no se ejecuta si el servidor está fijado a una versión concreta, de la documentación de preferencias de actualización de WHM, de donde salen también los nombres de los tiers. No hemos reproducido ninguno de los dos fallos: este artículo es una lectura de las fichas públicas, de la documentación del fabricante y de la cobertura citada, y así se dice. Fotografía de la imagen social: fachada de edificio residencial con balcones, rawpixel, dominio público (CC0).