Blog
La CVE-2026-41940 es una vulnerabilidad crítica que afecta a cPanel & WHM y WP Squared, con impacto directo sobre entornos de hosting, servidores compartidos, administradores de infraestructura web y proveedores que dependen de este panel para operar servicios expuestos a Internet.
Según el advisory oficial de cPanel, el problema corresponde a un bypass de autenticación en el software, afectando versiones posteriores a 11.40. En términos simples: el riesgo está en que un atacante remoto pueda obtener acceso no autorizado al panel sin pasar por el flujo normal de autenticación. Para una plataforma usada como interfaz de administración de hosting, eso no es un detalle menor: es una puerta principal con el picaporte flojo y un cartel luminoso que dice “probá suerte”.【turn202506view0†L45-L53】
NVD registra la vulnerabilidad como crítica, con CVSS 3.1 de 9.8, bajo un vector que no requiere privilegios previos ni interacción del usuario. Esto ubica el caso dentro de las prioridades máximas de gestión de vulnerabilidades: explotación remota, baja complejidad, sin autenticación y con potencial impacto sobre confidencialidad, integridad y disponibilidad.【turn202506view2†L104-L140】
El punto más importante para defensa no es solo el score. Es que CISA la incluyó dentro de su catálogo de Known Exploited Vulnerabilities, lo que indica explotación conocida en el mundo real. En castellano brutal: no es un CVE “interesante para mirar después”, es un problema que ya está en zona de respuesta operativa.【turn558283search2】
cPanel publicó parches para múltiples ramas. Las versiones mínimas corregidas indicadas por el vendor incluyen:
También se publicó una actualización específica para clientes en CentOS 6 / CloudLinux 6 usando la rama 110.0.50, con versión directa 110.0.103.【turn202506view0†L50-L68】
La acción principal es actualizar inmediatamente. cPanel recomienda ejecutar el proceso de actualización forzada y luego verificar la versión instalada:
/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard
La actualización por sí sola no alcanza si el servicio no queda correctamente reiniciado y validado. Después del parche, hay que confirmar que el servidor realmente está corriendo una versión corregida. Porque sí, aparentemente en 2026 todavía hay que recordar que “instalé el parche” y “el servicio quedó protegido” no siempre son la misma cosa.【turn202506view0†L71-L87】
Los casos más sensibles son:
servidores con actualizaciones automáticas deshabilitadas, ramas fijadas manualmente, instalaciones heredadas, proveedores con muchos tenants, paneles de administración expuestos directamente a Internet, entornos WordPress administrados desde WP Squared y sistemas donde los puertos de administración están abiertos sin restricciones.
El riesgo aumenta cuando 2083, 2087, 2095 y 2096 están expuestos públicamente. Estos puertos suelen asociarse a interfaces de administración y webmail de cPanel/WHM. En un escenario de explotación activa, dejarlos abiertos sin necesidad operativa es regalar superficie de ataque con moño violeta, porque aparentemente la humanidad insiste en aprender a golpes.
Si el parche no puede aplicarse de inmediato, cPanel recomienda medidas de contención. Entre ellas:
bloquear tráfico entrante hacia 2083, 2087, 2095 y 2096, deshabilitar Service Subdomains, o detener temporalmente servicios como cpsrvd y cpdavd en escenarios donde la exposición no pueda aceptarse.【turn202506view0†L88-L92】
Estas mitigaciones no reemplazan el parche. Sirven para reducir exposición mientras se corrige. La prioridad sigue siendo actualizar a una rama segura, verificar versión y revisar logs.
Para equipos Blue Team, SOC o administradores con logging centralizado, conviene revisar:
accesos recientes al panel, actividad de cuentas privilegiadas, creación inesperada de usuarios, cambios en configuraciones de hosting, modificaciones en dominios o subdominios, accesos desde IPs no habituales, eventos sobre cpsrvd, cambios de archivos en cuentas web y cualquier actividad posterior compatible con toma de control.
También conviene revisar si hubo cambios en cuentas reseller, modificaciones de DNS, creación de correos, alteraciones de credenciales o instalación de archivos sospechosos en directorios web.
El impacto de una vulnerabilidad de este tipo puede variar mucho según el entorno. En un servidor aislado, el riesgo puede limitarse a una instancia concreta. En un proveedor de hosting o entorno compartido, el problema puede escalar a múltiples clientes, dominios, sitios WordPress, buzones, bases de datos y servicios asociados.
El peligro no es solo “entraron al panel”. El peligro real es lo que puede venir después: persistencia, modificación de sitios, robo de datos, abuso de infraestructura para phishing, creación de cuentas, manipulación de DNS, despliegue de webshells o preparación para ransomware.
Desde una perspectiva de inteligencia de amenazas, esta CVE tiene todos los ingredientes para atraer explotación oportunista: producto ampliamente usado, paneles expuestos a Internet, parche disponible, criticidad alta y ventana entre publicación, parcheo real y validación operativa.
No hace falta imaginar un APT con capa negra y monólogo dramático. Muchas veces basta con automatización, escaneo masivo y servidores mal mantenidos. La explotación oportunista suele ser aburrida, rápida y efectiva. Qué desgracia tan eficiente.
Prioridad inmediata:
Identificar todos los servidores cPanel/WHM y WP Squared.
Verificar versión instalada.
Actualizar a una versión corregida.
Reiniciar servicios afectados.
Restringir exposición de puertos administrativos.
Revisar logs de acceso y cambios recientes.
Buscar actividad sospechosa posterior al parche.
Confirmar que no existan updates bloqueadas o ramas fijadas.
Documentar servidores corregidos y pendientes.
Mantener seguimiento de advisories oficiales.
La CVE-2026-41940 no debería tratarse como una vulnerabilidad más en la lista semanal. Es crítica, afecta a un producto muy usado en hosting y ya aparece vinculada a explotación activa. La respuesta correcta no es discutir si el score está inflado, sino reducir exposición, aplicar parches y revisar señales de compromiso.
Si administrás cPanel o dependés de un proveedor que lo usa, este es el momento de preguntar por versiones, mitigaciones y evidencias de revisión. No mañana. No “cuando baje el ruido”. Hoy.
Soy DrPlaga. Menos humo, más evidencia. Nos vemos en los logs.
