La falla de root en cPanel es una llamada de atención para el alojamiento compartido

La cuenta que puede ser dueña de tu servidor

Una cuenta de cPanel —el tipo que una pequeña empresa compra por $5 al mes para alojar un sitio WordPress— ahora puede usarse para ejecutar código como root en el servidor donde reside.

Eso es lo que permite la vulnerabilidad, registrada como CVE-2026-87899. El fallo se encuentra en el servicio CalDAV y CardDAV de cPanel, que gestiona calendarios y datos de contactos. No se requieren privilegios especiales. Tampoco se necesitan exploits entre cuentas distintas. Si tienes un inicio de sesión de cPanel y el software no está parcheado, puedes tomar el control total del servidor.

La corrección se publicó el 22 de septiembre en las versiones 11.134.0.57, 11.136.0.41, 11.138.0.8 y WP Squared 11.138.1.11. Pero que exista el parche es solo la mitad de la historia. La otra mitad es que esto se ha explotado en la naturaleza: y no para viciar sitios web, sino para desplegar el malware Mirai.

Por qué esto duele más de lo que debería

La mayoría de las discusiones sobre fallos en cPanel se detienen en los detalles técnicos: las versiones afectadas, el CVE, la corrección. Pero esta vulnerabilidad golpea el supuesto central del alojamiento compartido.

El alojamiento compartido funciona porque cientos o miles de clientes aceptan que su servidor es compartido, a cambio de un precio que les sería imposible pagar por separado. El sistema operativo garantiza el aislamiento. El panel de control, cPanel en este caso, media entre el proveedor y cada cliente. El modelo de seguridad asume que cPanel aísla correctamente a un cliente de otro.

CVE-2026-87899 destruye ese supuesto. Un titular de cuenta con sesión iniciada puede escapar completamente del sandbox. En un entorno compartido, cada otro cliente en ese servidor se convierte en problema de alguien más —o en superficie de ataque de alguien más.

Esta no es una preocupación hipotética. El ecosistema de alojamiento sostiene una porción asombrosa de internet. Pequeñas empresas, blogueros, organizaciones sin fines de lucro y desarrolladores individuales confían en proveedores de alojamiento compartido. Muchos de esos proveedores operan con márgenes extraordinariamente ajustados. Es posible que no actualicen de inmediato. Es posible que no tengan el personal necesario para auditar si sus servidores ya estaban comprometidos antes de aplicar el parche.

Un segundo fallo que añade insulso a la herida

Un segundo fallo de seguridad, CVE-2026-87900, reside en WP Toolkit, un plugin que cPanel empaca para ayudar a los usuarios a instalar y administrar sitios WordPress. Permite que un titular de cuenta con sesión iniciada modifique bases de datos pertenecientes a otras cuentas.

cPanel no ha aclarado exactamente qué modificaciones son posibles. No confirmó si los datos pueden leerse, solo cambiarse. Tampoco ha dicho si el atacante necesita acceso directo a WP Toolkit mismo para desencadenar el fallo. La ambigüedad importa. Si la modificación de bases de datos incluye lecturas, entonces los datos de calendario robados por la tercera vulnerabilidad se convierten en una preocupación menor comparada con cualquier otra cosa que se encuentre en esas bases de datos.

WP Toolkit también está disponible para Plesk, otro panel de control de alojamiento de la misma empresa matriz, WebPros. cPanel no ha indicado si la versión para Plesk también está afectada.

Un tercer fallo, un problema menor

CVE-2026-68490 afecta al mismo servicio CalDAV y CardDAV. Permite que un usuario local en el servidor lea los eventos de calendario y los contactos de otras cuentas. No permite modificación ni escalada a root. Es menos alarmante que los otros dos, pero refuerza el mismo patrón. Un solo servicio maneja datos sensibles entre cuentas, y un fallo ahí genera un conjunto de problemas en cascada.

Juntos, los tres fallos crean un escenario del peor de los casos para cualquier proveedor de alojamiento compartido: un atacante puede robar contactos y datos de calendario, secuestrar bases de datos entre cuentas y luego escalar a root para hacer lo que quiera con todo el servidor.

¿Quiénes están realmente en riesgo?

El perfil de riesgo depende de cómo gestione las actualizaciones el proveedor. Los proveedores empresariales con tuberías automatizadas de parcheo habrán aplicado las correcciones en cuestión de horas. Los proveedores pequeños —los que operan con personal mínimo e infraestructura heredada— podrían tardar días o semanas.

cPanel no ofrece ningún workaround temporal para servidores que aún no puedan actualizarse. Ese silencio vale la pena señalarlo. Para una vulnerabilidad que otorga acceso root y que se está explotando activamente, la ausencia de una mitigación es un fracaso en la comunicación de crisis.

Incluso los servidores parcheados pueden estar acechados. Ninguna de las tres advertencias menciona detalles de explotación, y ninguna proporciona una forma de verificar si un servidor fue comprometido antes de aplicar la actualización. Si Mirai fue desplegado a través de este fallo, cada servidor sin parchear entre agosto de 2026 y el 22 de septiembre podría ser una lápida: funcional, aparentemente seguro, pero portando un malware que pasó desapercibido.

El investigador detrás del telón

Los tres fallos fueron creditados a Ali Mustafa, quien opera bajo el nombre rz1027. No es una voz nueva en la seguridad de cPanel. Desde el 27 de agosto, ha divulgado al menos siete vulnerabilidades de cPanel y Plesk, tres de ellas conjuntamente con un investigador conocido como abed1526.

Esos hallazgos anteriores incluyen un fallo del 8 de septiembre en la función EmailTrack de cPanel que también permitía ejecución de root desde una cuenta habilitada para correo. El patrón es claro: el mismo investigador, la misma categoría de fallo, y el mismo impacto devastador. Cada descubrimiento agrega otra grieta al modelo de alojamiento compartido.

Plesk, mientras tanto, corrigió dos vulnerabilidades el 10 de septiembre: una en la restauración de archivos del Administrador de Copias de Seguridad, otra en el manejo de encabezados de copia de seguridad. Ambas podrían haber permitido que un cliente tomara el control de todo el servidor. La analogía es incómoda. Dos paneles de control competidores, la misma clase de vulnerabilidad, las mismas consecuencias.

Qué sigue

El paso inmediato es actualizar. Los administradores de cPanel & WHM deben ejecutar la actualización a través de WHM (Inicio / cPanel / Actualizar a la última versión) o ejecutar /usr/local/cpanel/scripts/upcp --force como root. La actualización de WP Toolkit requiere un comando separado y una invocación manual; las actualizaciones automáticas podrían no cubrirla.

Pero el verdadero enfrentamiento a largo plazo es más difícil. Esta vulnerabilidad expone una debilidad estructural que ningún parche individual puede resolver. Se le pide a los proveedores de alojamiento compartido que mantengan un límite de aislamiento que su propia pila de software no puede garantizar de manera confiable. Cuando el panel de control —la cosa que existe para mediar entre clientes y el servidor— no puede ser de confianza, todo el modelo tambalea.

Para las pequeñas empresas que dependen de esta infraestructura, la lección es clara. Si tu proveedor de alojamiento no se ha actualizado, estás ejecutando tu sitio web en una máquina donde cualquier vecino puede convertirse en root. No hay advertencia. No hay entrada de registro en tu panel de cuenta. El compromiso ocurre en silencio, y para cuando notas que algo anda mal, el daño puede que ya esté hecho.

Las vulnerabilidades de cPanel son un recordatorio de que el entramado de internet se sostiene con software construido por humanos, revisado por humanos y actualizado a la velocidad de la atención humana. Esta vez, el fallo fue encontrado, divulgado y corregido en una ventana razonable. La pregunta es si lo será con el próximo.