En un hosting compartido, una cuenta cPanel debería controlar solamente sus propios dominios, archivos y bases de datos. La CVE-2026-65643 rompe exactamente esa frontera. Según el advisory publicado por cPanel el 27 de agosto de 2026, un usuario autenticado que pueda agregar dominios estacionados o adicionales puede crear archivos arbitrarios en el servidor. Una explotación exitosa termina en ejecución de código como root, con control sobre todas las cuentas, sitios web y bases alojadas en la máquina.
El registro público de la CVE clasifica la falla como eval injection, CWE-95, y le asigna CVSS 4.0 de 8,7 con el vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. La puntuación es alta y no crítica porque se requiere una cuenta con privilegios bajos. Sin embargo, en el modelo comercial del hosting compartido, entregar esa cuenta a un cliente es una función normal del producto. El requisito reduce la población de atacantes, pero no el impacto de una ruta directa de tenant a root.
Qué está confirmado y qué todavía no
Las fuentes oficiales confirman la condición de entrada, la creación arbitraria de archivos y el resultado como root. El registro CVE agrega la clasificación de eval injection. No publican el parámetro vulnerable, la ruta del archivo creado, una secuencia de solicitudes, indicadores de compromiso ni una prueba de concepto. Sin esos datos, cualquier payload específico sería especulación. Por eso, una validación segura comienza por versión, permiso y exposición de la funcionalidad, sin intentar reconstruir un exploit en producción.
- Atacante necesario: usuario remoto autenticado en cPanel
- Permiso necesario: capacidad de agregar parked domains o addon domains
- Primitiva confirmada: creación de archivos arbitrarios en el servidor
- Impacto confirmado: ejecución de código como root y control completo del host
- Interacción de otra persona: ninguna después de que el atacante posee la cuenta y el permiso
- Detalles no publicados: payload, archivo de destino, indicadores de compromiso y estado de explotación real
Por qué una credencial de tenant no es una barrera fuerte
En una aplicación empresarial común, exigir autenticación puede restringir una falla a empleados o socios. En hosting compartido, la cuenta con privilegios bajos forma parte del servicio vendido. Puede pertenecer a un cliente legítimo malicioso, abrirse con identidad fraudulenta, filtrarse mediante phishing o ser tomada por reutilización de contraseña. La evaluación de riesgo debe usar el modelo real de adquisición de la credencial, en lugar de tratar PR:L como sinónimo de acceso interno confiable.
Después de la elevación, el aislamiento entre cuentas deja de proteger a los demás tenants. Root puede alcanzar webroots, configuraciones de bases, buzones, llaves, respaldos, tareas programadas y credenciales mantenidas por servicios locales. cPanel resume el impacto como control de cada cuenta, sitio web y base en el servidor. En un host con decenas de clientes, por lo tanto, el radio de acción queda definido por la densidad del servidor y no por el tamaño de la cuenta usada como punto de entrada.
CVSS 8,7, impacto operativo crítico
El vector CVSS 4.0 combina ataque por red, baja complejidad, ausencia de requisitos especiales y ninguna interacción del usuario con privilegios previos bajos. La confidencialidad, integridad y disponibilidad del sistema vulnerable reciben impacto alto. El vector no puntúa impacto en sistemas posteriores, pero eso no significa que los demás clientes sigan protegidos. Las cuentas alojadas forman parte del mismo sistema bajo la autoridad de root, y el proveedor declara explícitamente que todas quedan al alcance.
Este es un caso en el que el número debe leerse junto con el modelo de negocio. Un filtro que priorice solamente CVEs por encima de 9,0 puede colocar esta falla detrás de problemas sin una ruta real hacia producción. Para un proveedor con registro abierto, revendedores o muchas cuentas administradas por terceros, la combinación de una credencial accesible e impacto total justifica tratamiento de emergencia incluso con un base score de 8,7.
Versiones corregidas y cómo confirmar la actualización
cPanel afirma que todas las versiones con soporte estaban afectadas y publica un build corregido para cada línea. El resumen de la CVE menciona 11.138.0.0 y anteriores, pero no debemos convertir ese texto breve en un único corte para todas las branches. Para remediar, compara la instalación con la línea correspondiente de la tabla del proveedor y actualiza a uno de los siguientes builds o posterior.
- cPanel & WHM 11.110: build 11.110.0.141 o posterior
- cPanel & WHM 11.134: build 11.134.0.53 o posterior
- cPanel & WHM 11.136: build 11.136.0.37 o posterior
- cPanel & WHM 11.138: build 11.138.0.2 o posterior
- WP Squared, identificado como WP2 en el advisory: build 11.138.1.7 o posterior
- Versiones sin soporte: migrar primero a una línea con soporte, porque las versiones EOL no reciben correcciones de seguridad
# Check the version that is actually installed
/usr/local/cpanel/cpanel -V
# As root, apply the update recommended by cPanel
/usr/local/cpanel/scripts/upcp --force
# Confirm the version again after the update
/usr/local/cpanel/cpanel -VNo basta con confirmar que el repositorio o la política de updates apunta a una línea segura. La evidencia es la versión devuelta por el host después de la ejecución. En flotas, recopila ese resultado por servidor y trata cualquier nodo sin respuesta como pendiente, porque un solo panel olvidado conserva la ruta hacia todos los tenants de ese equipo.
Triaje sin indicadores listos
El parche cierra la condición vulnerable, pero no demuestra que el servidor nunca haya sido utilizado. Como el advisory no proporciona indicadores de compromiso, la investigación debe partir del comportamiento confirmado: sesiones de cuentas capaces de administrar dominios, adiciones inesperadas de parked domains o addon domains, archivos fuera del espacio esperado del tenant y cualquier persistencia posterior con privilegios de root. Preserva logs y un snapshot antes de eliminar artefactos.
# Inventory accounts on the host
whmapi1 --output=jsonpretty listaccts
# For each relevant account, list every known domain
uapi --output=jsonpretty --user=CPUSER DomainInfo list_domains
# Review recent sessions for the account under investigation
grep 'CPUSER' /usr/local/cpanel/logs/session_log | grep NEW | tail -n 50
# List altered cPanel-managed packages
/usr/local/cpanel/scripts/check_cpanel_pkgs --list-only- Correlacionar sesiones recientes con cambios de dominio solicitados por el cliente o el equipo operativo
- Comparar aliases, addon domains y document roots actuales con inventario, tickets y respaldos anteriores
- Revisar nuevos usuarios administrativos, llaves SSH, tareas cron, servicios, web shells y cambios en webroots
- Auditar accesos a bases, exportaciones, cambios de grants y uso de credenciales almacenadas en el host
- Rotar contraseñas, tokens y llaves accesibles desde el servidor cuando existan señales de compromiso
- Ampliar la respuesta a todos los tenants del host, sin limitar el análisis a la cuenta que inició el evento
Qué probar en paneles de hosting
Un pentest de un entorno cPanel no debería evaluar solamente el sitio de cada cliente. El panel es el plano de control y necesita un objetivo explícito de aislamiento multitenant. Con una cuenta de menor privilegio entregada para la prueba, determinamos qué funciones alteran configuración global, dónde los nombres de dominio y rutas llegan al filesystem, qué procesos privilegiados consumen esos datos y si un tenant puede producir un efecto fuera de su propio directorio. En producción, la validación debe usar marcadores inofensivos y detenerse antes de cualquier intento de obtener root.
- Separación entre cuenta cPanel, reseller, WHM y root
- Autorización para crear parked domains, addon domains, subdominios y document roots
- Canonicalización de rutas, symlinks y destinos escritos por procesos privilegiados
- Validación de datos antes de que lleguen a templates, intérpretes o llamadas dinámicas
- Aislamiento de filesystem, base de datos, correo, respaldos y secretos entre tenants
- Logs capaces de atribuir cada cambio de dominio a la sesión, cuenta y origen correctos
- Detección de creación de archivos y ejecución privilegiada originadas en flujos de autoservicio
La lección para quien contrata pentest
La CVE-2026-65643 muestra por qué el alcance debe seguir fronteras de confianza y no solamente URLs. Un portal de hosting puede parecer un sistema administrativo auxiliar, pero coordina procesos privilegiados y concentra el acceso a decenas de entornos. Si la prueba cubre únicamente las aplicaciones publicadas y deja el panel afuera, la principal ruta entre un cliente y todos los demás queda sin validar.
La acción inmediata es objetiva: identificar la línea instalada, aplicar el build corregido correspondiente y confirmar la versión en cada servidor. Después, revisa actividad de dominios y señales de persistencia según la exposición real de las cuentas. En el próximo pentest, trata cPanel y cualquier otro plano de control multitenant como un activo de impacto máximo, incluso cuando la explotación comience con una credencial de privilegio bajo.