Cuando hablamos de seguridad web, muchas empresas piensan automáticamente en WordPress, Prestashop, WooCommerce, plugins, plantillas o contraseñas débiles. Sin embargo, una web no depende solo del CMS con el que está creada. También depende del servidor, del panel de control y de todos los servicios que hacen posible que esa página esté online cada día.
Por eso, la vulnerabilidad CVE-2026-41940 en cPanel y WHM ha generado tanta preocupación dentro del sector técnico. Es una vulnerabilidad crítica que afecta directamente a uno de los paneles de hosting más utilizados para administrar servidores, webs, correos electrónicos, dominios y bases de datos.
Según el aviso oficial de cPanel, se trata de un problema de omisión de autenticación que afecta a versiones posteriores a la 11.40 de cPanel, incluyendo también DNSOnly.
cPanel publicó parches para diferentes ramas de cPanel & WHM y recomendó actualizar de forma inmediata los servidores afectados.
Qué es cPanel y por qué es tan importante
cPanel es un panel de control utilizado por muchos proveedores de hosting para facilitar la gestión de una web.
Desde este entorno se pueden administrar archivos, bases de datos, cuentas de correo, certificados SSL, dominios, subdominios, copias de seguridad y otros servicios vinculados al alojamiento.
WHM, por su parte, es la parte más orientada a la administración del servidor. Permite gestionar cuentas de hosting, configuraciones globales, recursos, servicios y permisos. Dicho de forma sencilla: si cPanel permite administrar una web concreta, WHM permite administrar el entorno en el que pueden estar alojadas muchas webs.
Por eso una vulnerabilidad en cPanel/WHM no debe interpretarse como un problema aislado. Si el panel de control se ve comprometido, el riesgo puede extenderse a webs corporativas, tiendas online, cuentas de correo, bases de datos y otros elementos críticos para una empresa.
Qué es CVE-2026-41940
CVE-2026-41940 es una vulnerabilidad crítica de omisión de autenticación en el flujo de inicio de sesión de cPanel y WHM. La base de datos NVD describe el fallo como una vulnerabilidad que permite a atacantes remotos no autenticados obtener acceso no autorizado al panel de control.
Esto significa que el riesgo principal no está en que alguien adivine una contraseña, sino en que pueda saltarse el proceso normal de autenticación si el servidor está afectado y no ha sido actualizado correctamente.
La gravedad de este tipo de fallo es alta porque el panel de hosting concentra muchos permisos sensibles. Un acceso indebido podría permitir revisar archivos, modificar configuraciones, acceder a información alojada, crear cuentas no autorizadas o alterar el funcionamiento normal de los servicios.
INCIBE también catalogó la vulnerabilidad como crítica e indicó que podría permitir a un atacante omitir la autenticación en el software, señalando además que la vulnerabilidad podría estar siendo explotada.
Qué versiones están afectadas
El aviso oficial señala que el problema afecta a versiones posteriores a la 11.40. cPanel publicó versiones corregidas para diferentes ramas de cPanel & WHM y también para WP Squared. Además, indicó que los servidores con actualizaciones desactivadas o configuraciones fijadas en una versión concreta deben revisarse manualmente, ya que podrían no actualizarse de forma automática.
Este punto es importante. No basta con pensar que “el servidor se actualiza solo”. En muchos entornos de hosting, por estabilidad, compatibilidad o configuración previa, las actualizaciones pueden estar limitadas. Por eso, la confirmación debe venir del proveedor o del administrador del servidor.
Qué debes revisar si tu web usa cPanel
Lo primero es confirmar si el hosting utiliza cPanel o WHM. Muchas empresas no lo saben porque acceden pocas veces al panel o porque todo lo gestiona una agencia, un proveedor técnico o el propio hosting.
Una vez confirmado, lo recomendable es preguntar al proveedor si la versión instalada está parcheada frente a CVE-2026-41940. También conviene solicitar confirmación de que se han revisado posibles indicadores de compromiso y que no se han detectado accesos sospechosos.
Además, es aconsejable revisar si existen usuarios desconocidos en el panel, cuentas FTP que no deberían estar activas, buzones de correo creados sin autorización, modificaciones recientes en archivos críticos o cambios extraños en la configuración de dominios y subdominios.
En webs WordPress o Prestashop, también conviene comprobar si se han creado usuarios administradores no reconocidos, si existen archivos PHP sospechosos, si hay redirecciones extrañas o si, incluso, Search Console muestra alertas de seguridad.
Qué debe hacer el proveedor de hosting o administrador del servidor
La prioridad es actualizar cPanel/WHM a una versión corregida. cPanel recomienda ejecutar la actualización correspondiente, verificar la versión instalada y reiniciar servicios concretos tras completar el proceso.
También incluye medidas temporales para aquellos casos en los que no sea posible actualizar de inmediato, como bloquear determinados puertos asociados al acceso a cPanel, WHM y webmail.
Además de aplicar el parche, es recomendable revisar registros de acceso, sesiones activas, cuentas administrativas, cambios recientes en el sistema de archivos y cualquier actividad que pueda indicar un acceso no autorizado.
Soluciones para corregir CVE-2026-41940
La solución principal, recomendada por cPanel, es actualizar el servidor de forma inmediata a una de las versiones corregidas. Según el aviso oficial, cPanel ha publicado parches para distintas ramas de cPanel & WHM, incluyendo versiones como:
- 11.86.0.41 o superiores,
- 11.94.0.28 o superiores,
- 11.102.0.39 o superiores,
- 11.110.0.97 o superiores,
- 11.118.0.63 o superiores,
- 11.124.0.35 o superiores,
- 11.126.0.54 o superiores,
- 11.130.0.19 o superiores,
- 11.132.0.29 o superiores,
- 11.134.0.20 o superiores y
- 11.136.0.5 o superiores.
En el caso de WP Squared, la versión corregida indicada es 136.1.7 o superior.
Para aplicar la actualización, cPanel recomienda ejecutar el script de actualización del propio sistema:
/scripts/upcp --force
Una vez completada la actualización, es necesario verificar la versión instalada de cPanel y reiniciar el servicio de cPanel, conocido como cpsrvd, para asegurarse de que la corrección queda correctamente aplicada. Los comandos indicados por cPanel son los siguientes:
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard
Este paso es especialmente importante en servidores donde las actualizaciones automáticas estén desactivadas o donde la configuración de cPanel esté fijada a una versión concreta.
En esos casos, el servidor puede no actualizarse automáticamente, por lo que cPanel recomienda identificar estos entornos y actualizarlos manualmente como prioridad.
Para servidores con CentOS 7 o CloudLinux 7, el aviso oficial indica que debe configurarse la versión 11.110.
whmapi1 set_tier tier=11.110
En el caso concreto de clientes que todavía utilicen CentOS 6 o CloudLinux 6 con la versión v110.0.50, cPanel indica que ha publicado la versión v110.0.103 como actualización directa.
Para acceder a esa actualización, primero se debe ajustar el canal de actualización correspondiente y después seguir los pasos de actualización indicados en el propio aviso.
sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.conf
Si por cualquier motivo no es posible aplicar la actualización de forma inmediata, cPanel propone medidas de mitigación temporal.
La primera consiste en bloquear el tráfico entrante a los puertos 2083, 2087, 2095 y 2096 desde el firewall, además de desactivar los subdominios de servicio. Estos puertos están asociados habitualmente al acceso a cPanel, WHM y webmail, por lo que bloquearlos puede reducir la exposición mientras se prepara la actualización definitiva.
whmapi1 set_tweaksetting key=proxysubdomains value=0 && /scripts/proxydomains remove && /scripts/rebuildhttpdconf && /scripts/restartsrv_httpd
Otra medida de mitigación planteada por cPanel es detener los servicios cpsrvd y cpdavd. Esta opción puede afectar al acceso normal a cPanel, WHM, webmail o servicios relacionados, por lo que debe valorarse con cuidado y aplicarse únicamente como medida temporal en entornos donde no sea posible actualizar de inmediato.
whmapi1 configureservice service=cpsrvd enabled=0 monitored=0 && whmapi1 configureservice service=cpdavd enabled=0 monitored=0 && /scripts/restartsrv_cpsrvd --stop && /scripts/restartsrv_cpdavd --stop
Además de actualizar o mitigar, cPanel también proporciona un script de detección para buscar posibles indicadores de compromiso en archivos de sesión del sistema. Este punto es relevante porque no basta con parchear el servidor: si la vulnerabilidad ha podido ser explotada antes de la actualización, también conviene revisar si existen sesiones sospechosas o evidencias de acceso no autorizado.
Script de detección de indicadores de compromiso para cPanel
El script se llama ioc_checksessions_files.sh y está pensado para analizar archivos de sesión de cPanel/WHM en el sistema.
El script revisa por defecto las sesiones ubicadas en:
/var/cpanel/sessions
y consulta también el registro de acceso de cPanel en:
/usr/local/cpanel/logs/access_log
Para ejecutarlo, debe guardarse el contenido del script oficial con el nombre:
ioc_checksessions_files.sh
y lanzarlo con el siguiente comando:
/bin/bash ./ioc_checksessions_files.sh
El script puede devolver diferentes niveles de resultado, como CRITICAL, WARNING, ATTEMPT o INFO.
Según el propio aviso, si aparecen resultados críticos o advertencias, se deben tomar medidas inmediatas, como purgar las sesiones afectadas, forzar el cambio de contraseña del usuario root y de todos los usuarios WHM, revisar /var/log/wtmp y los logs de acceso de WHM, y comprobar posibles mecanismos de persistencia como tareas cron, claves SSH o backdoors.
También es importante tener en cuenta que el script puede devolver distintos códigos de salida:
- 2 si detecta indicadores de compromiso críticos o advertencias,
- 1 si encuentra intentos o señales informativas sin compromiso confirmado, y
- 0 si el escaneo no detecta indicios.
En caso de que el servidor se confirme como comprometido a nivel root, cPanel recomienda migrar las cuentas a un servidor limpio o, como alternativa, reinstalar el sistema operativo y restaurar las cuentas desde copias de seguridad.
Por seguridad, este script debería ser ejecutado únicamente por el proveedor de hosting, el administrador del servidor o personal técnico con permisos suficientes. P
Mantenimiento y seguridad web
Desde digitalDot se ha actuado de forma inmediata tras la publicación de esta vulnerabilidad crítica, aplicando medidas de contención y mitigación en todos los entornos gestionados. Si tienes dudas o necesitas ayuda para el mantenimiento web o ciberseguridad, contacta con nosotros.
Preguntas frecuentes sobre CVE-2026-41940
¿Es recomendable cambiar de proveedor de hosting tras una vulnerabilidad crítica?
No necesariamente. La clave no es que un proveedor se vea afectado por una vulnerabilidad, sino cómo responde ante ella. Un buen proveedor debe aplicar parches rápido, informar con claridad, revisar posibles accesos sospechosos y ofrecer medidas preventivas. Si no hay transparencia ni respuesta técnica, sí conviene valorar alternativas.
¿Una copia de seguridad del hosting es suficiente para recuperar una web?
Depende. Una copia de seguridad es esencial, pero debe estar limpia, ser reciente y estar almacenada de forma segura. Si la copia ya contiene archivos infectados o configuraciones alteradas, restaurarla puede devolver la web al mismo problema.
¿Qué diferencia hay entre actualizar cPanel y actualizar WordPress?
Actualizar WordPress protege la capa del CMS. Actualizar cPanel protege la capa del hosting y del servidor. Ambas son necesarias, pero actúan en niveles distintos. Una web puede tener WordPress actualizado y seguir estando en riesgo si el entorno de hosting es vulnerable.
¿Conviene limitar el acceso a cPanel solo a determinadas IPs?
En muchos casos, sí. Restringir el acceso al panel de control por IP, VPN o reglas de firewall reduce la superficie de exposición. No sustituye a las actualizaciones, pero añade una capa adicional de protección.
¿Cada cuánto debería revisarse la seguridad del hosting?
Lo ideal es realizar revisiones periódicas y no solo cuando aparece una alerta crítica. En proyectos profesionales, conviene revisar accesos, versiones, copias, logs y configuraciones al menos de forma mensual, además de actuar inmediatamente ante avisos de seguridad relevantes.