CVE-2026-41940: el bug de cPanel con CVSS 9.8 que le dio acceso root a los hackers durante meses (y tu hosting mexicano probablemente lo usó)

Imagínate que la llave de tu casa lleva dos meses debajo del tapete, y tú ni en cuenta. Eso es exactamente lo que pasó con cPanel. Mientras los dueños de millones de sitios web dormían tranquilos, los hackers ya estaban adentro de sus servidores con acceso root completo, sin necesitar ninguna contraseña.

El 28 de abril de 2026, WebPros International publicó el parche para CVE-2026-41940, una vulnerabilidad crítica con puntuación CVSS de 9.8 sobre 10. La mala noticia: la evidencia apunta a que llevan explotándola desde el 23 de febrero de 2026, más de dos meses antes de que alguien la parcheara. Classic.

Qué onda con este fallo

CVE-2026-41940 es un authentication bypass en cPanel y WHM causado por una inyección CRLF (Carriage Return Line Feed, los caracteres \r\n que separan líneas en protocolos de red). Para que quede claro sin tanto tecnicismo: el sistema que guarda las sesiones de usuario en disco no filtraba correctamente esos caracteres, y eso le permite a un atacante inyectar datos falsos en el archivo de sesión.

El exploit funciona más o menos así:

1. El atacante inicia un login fallido para generar una sesión preautenticada con un ID válido.
2. Manda una petición HTTP con autenticación básica usando una cookie whostmgrsession modificada (sin el segmento “ob” que activa el cifrado), y en el campo de contraseña mete algo como x\r\nuser=root\r\nhasroot=1\r\ntfa_verified=1.
3. cPanel escribe esa basura literalmente en el archivo de sesión sin limpiarla.
4. Una petición posterior invalida el caché JSON, lo recarga desde el archivo de disco, y de pronto la sesión tiene user=root como propiedad válida. El sistema detecta eso y salta completamente la validación de contraseña. Acceso root. Sin contraseña. Sin verificación de dos factores. Sin nada.

WatchTowr Labs publicó el análisis técnico completo y lo tituló “The Internet Is Falling Down”, que no es exactamente exagerado.

Por qué en México esto importa mucho

cPanel es el panel de control dominante en hosting compartido. Hostinger MX, GoDaddy México, Namecheap, HostGator y SiteGround, todos lo usan. Y esos son exactamente los proveedores donde corren los sitios de miles de PyMEs mexicanas, agencias digitales y tiendas de e-commerce.

Según Shodan, hay aproximadamente 1.5 millones de instancias de cPanel expuestas directamente en internet. En total, cPanel gestiona propiedades para cerca de 70 millones de dominios a nivel global.

La CISA ya añadió CVE-2026-41940 a su catálogo KEV el 30 de abril de 2026, con deadline del 21 de mayo de 2026 (aproximadamente 3 semanas) para que las agencias federales estadounidenses apliquen el parche bajo Binding Operational Directive 22-01. Si las agencias del gobierno de EE.UU. tienen deadline urgente, los servidores de tu agencia o PyME en México deberían tenerlo también.

Lo más preocupante: Help Net Security confirmó que la explotación comenzó meses antes del parche. Si tu servidor estuvo expuesto entre febrero y finales de abril, hay una probabilidad real de que ya esté comprometido aunque no notes nada raro. Y eso es lo más arrecho de este tipo de ataques, que los buenos hackers no hacen ruido.

Cómo saber si tu servidor ya fue comprometido

cPanel publicó un script de detección de indicadores de compromiso. Si tienes acceso SSH a tu servidor, lo primero que debes hacer es correrlo. Los indicadores que busca incluyen:

• Sesiones con token_denied y cp_security_token con método badpass
• Sesiones preautenticadas que tienen atributos de usuario ya autenticado
• Sesiones con tfa_verified=1 sin un origen de verificación válido

WatchTowr Labs también publicó un generador de artefactos de detección en su repositorio de GitHub.

Además, si eres administrador del servidor, revisa manualmente los logs de acceso de WHM buscando patrones de Basic Auth inusuales con cookies malformadas (sin el segmento ob), especialmente entre el 23 de febrero y el 28 de abril de 2026.

Esto no es distinto a lo que ya hemos visto con otros ataques de acceso silencioso, como el caso de DarkSword, el spyware que infectaba iPhones con solo abrir una página web: los vectores de entrada más peligrosos son siempre los que no hacen ruido.

Versiones afectadas y cómo verificar la tuya

Afecta: todas las versiones de cPanel y WHM posteriores a v11.40, y WP Squared antes de v136.1.7.

Para verificar tu versión actual, entra a WHM > Server Information. Ahí te dice exactamente qué build tienes instalado.

Las versiones ya parcheadas son:

Rama	Versión corregida
86.x	11.86.0.41
110.x	11.110.0.97
118.x	11.118.0.63
126.x	11.126.0.54
130.x	11.130.0.19
132.x	11.132.0.29
134.x	11.134.0.20
136.x	11.136.0.5

Si tu versión es anterior a cualquiera de estas, estás expuesto.

Cómo aplicar el parche

Si administras tu propio servidor (VPS o dedicado), ejecuta la actualización desde WHM en Home > cPanel > Upgrade to Latest Version, o vía línea de comandos:

/scripts/upcp --force

Si tienes hosting compartido, la responsabilidad es del proveedor. La mayoría de los grandes ya aplicaron el parche los días 28 y 29 de abril. Namecheap, por ejemplo, publicó en su página de status que el fix fue aplicado antes del 29 de abril en sus servidores Reseller y Stellar Business.

Aun así, mándale un ticket o correo a tu proveedor preguntando directamente: “¿Ya aplicaron el parche de CVE-2026-41940?” No lo des por hecho. Si no te responden con una confirmación clara, asúmelo como un problema.

Mitigación temporal si no puedes parchear ahorita

Si por alguna razón no puedes actualizar de inmediato, bloquea los puertos de cPanel y WHM en tu firewall:

• Puerto 2083: cPanel (HTTPS)
• Puerto 2087: WHM (HTTPS)
• Puerto 2095: Webmail (HTTPS)
• Puerto 2096: Webmail alternativo

Y detén los servicios vulnerables:

/scripts/restartsrv_cpsrvd --stop
/scripts/restartsrv_cpdavd --stop

O alternativamente usando whmapi1:

whmapi1 configureservice service=cpsrvd enabled=0 monitored=0
whmapi1 configureservice service=cpdavd enabled=0 monitored=0
/scripts/restartsrv_cpsrvd --stop
/scripts/restartsrv_cpdavd --stop

Esto corta el acceso al panel, lo que es incómodo pero evita que te sigan clochando mientras esperas aplicar el parche. El análisis de Rapid7 lo recomienda explícitamente como medida temporal.

Ojo: bloquear los puertos no limpia una infección que ya ocurrió. Si crees que tu servidor fue comprometido en el periodo de zero-day, el bloqueo de puertos solo detiene el daño adicional. Necesitas hacer una auditoría completa.

La neta del asunto

Esto es un recordatorio de que la seguridad de tu hosting no es solo “le pago a alguien y ya”. Como explicamos cuando revisamos la preocupante tendencia de plataformas que recopilan tus datos sin avisarte bien, la infraestructura digital que usas cotidianamente tiene capas de riesgo que la mayoría de los usuarios nunca ve.

Un fallo como CVE-2026-41940 es especialmente peligroso porque no requiere phishing, no requiere que el usuario haga clic en nada, no requiere contraseña robada. Solo requiere que el servidor esté prendido y expuesto en internet, que es exactamente el estado normal de cualquier servidor de hosting.

Si tienes un sitio en hosting compartido con cPanel, lo mínimo que puedes hacer hoy es contactar a tu proveedor para confirmar que ya parchearon, y si tienes acceso al servidor, correr el script de detección de compromiso que publicó cPanel. Si llevas meses con el servidor expuesto y no sabes qué pasó adentro, considera también revisar si hay archivos PHP raros, backdoors, o usuarios nuevos en el sistema que no reconozcas.

Ojalá tu hosting ya haya aplicado el parche. Pero si no, ya sabes qué hacer.

---

Fuentes

• WatchTowr Labs: análisis técnico completo de CVE-2026-41940
• Rapid7 ETR: CVE-2026-41940 cPanel WHM Authentication Bypass
• Help Net Security: cPanel zero-day explotado meses antes del parche
• The Hacker News: Critical cPanel Authentication Vulnerability
• Namecheap Status: aviso oficial del parche
• The Register: Critical cPanel, WHM flaw probs exploited as 0-day
• Security Affairs: All supported cPanel versions hit by critical auth bug