La vulnerabilidad de cPanel que afectó millones de sitios — y cómo la mitigamos en Hosting del Sur

En abril de 2026 se publicó CVE-2026-41940: un bypass de autenticación en cPanel y WHM con CVSS 9.8. Afectaba casi todas las instalaciones en producción. La explotación activa empezó semanas antes del parche público. En Hosting del Sur no fuimos comprometidos: aplicamos el update en ventana controlada y verificamos que no hubiera indicadores de compromiso.

Este post es el registro de qué pasó, qué hicimos y qué sacamos en limpio. Sin marketing.

Qué es el CVE-2026-41940

cPanel y WHM son el panel con el que la mayoría de los hostings Linux gestionan cuentas, sitios, correo y DNS. El fallo estaba en la capa de sesiones: dos caminos de código escribían archivos de sesión en disco. Uno limpiaba la entrada pero el otro (Basic authentication) no.

Con una solicitud armada a medida, un atacante sin credenciales podía hacer que una sesión no autenticada se tratara como legítima. En la práctica: acceso al panel sin usuario ni contraseña válidos.

Cronología

Fecha	Qué pasó
23 feb 2026	KnownHost reportó intentos de explotación tan tempranos como esta fecha (declaración del CEO Daniel Pearson, citada por The Register).
27 abr 2026, 10:47 CDT	cPanel confirma y clasifica la vulnerabilidad; inicia respuesta a incidente.
28 abr 2026	cPanel publica parches en todos los tiers soportados (LTS, STABLE, RELEASE, CURRENT, EDGE) y el KB 40073787579671. ~28 horas entre confirmación y disponibilidad general.
29 abr 2026	NVD publica el registro CVE.
30 abr 2026	CISA lo agrega al Known Exploited Vulnerabilities (KEV) Catalog. Deadline federal de remediación: 3 may 2026.
1 may 2026	Carly Page en The Register: explotación confirmada antes del parche; ~1,5 millones de instancias cPanel expuestas según Rapid7/Shodan; reportes de ransomware.
Mayo 2026	Cobertura adicional sobre explotación masiva y campañas de ransomware asociadas.

La lección del calendario es dura: entre los primeros intentos (febrero) y el parche público (28 de abril) pasaron más de dos meses.

Quién estaba afectado

Casi todo el parque cPanel en internet.

cPanel y WHM en todas las versiones posteriores a 11.40. WP Squared hasta 11.136.1.6.

No había «versión antigua pero segura» en el rango habitual de producción: el corte inferior es 11.40, de hace más de una década.

Rapid7, vía Shodan, contó del orden de 1,5 millones de instancias cPanel expuestas a internet al momento del incidente (The Register, 1 may 2026). Detrás de cada instancia hay decenas o cientos de sitios. El impacto potencial se mide en millones de sitios web.

Cómo lo mitigamos en HDS

Estado final: nuestros servidores cPanel no fueron comprometidos. Mitigamos antes de que hubiera explotación exitosa en nuestra infraestructura.

1. Detección y monitoreo

Corrimos con LFD (ConfigServer Security & Firewall), revisión de logs de autenticación y el script de IOCs que publicó cPanel para escanear archivos de sesión. Buscamos, entre otras cosas:

• sesiones badpass con marcadores de auth que no deberían existir (successful_*_auth_with_timestamp, hasroot=1, tfa_verified=1)
• token_denied junto a cp_security_token en orígenes anómalos
• líneas pass= en sesiones de origen badpass (firma de intento fallido según el script oficial)

No encontramos artefactos CRITICAL de explotación en nuestros hosts.

2. Actualización en ventana controlada

No dejamos la actualización «para cuando corra sola». Forzamos el ciclo:

Ventana acordada, con rollback listo y sin solapar con respaldos pesados ni con picos de correo. Verificamos build pos-actualización contra la tabla de versiones parcheadas.

3. Verificación pos-parcheado

• Build de cPanel ≥ mínimo del tier correspondiente
• Reinicio limpio de cpsrvd
• Reescaneo de sesiones con el detection script de cPanel (versiones posteriores del script, sin el falso positivo de session.lock que corrigieron el 1 de mayo)
• Revisión de accesos root/WHM recientes y de cambios inesperados en cuentas

Lecciones para clientes (y para nosotros)

Un bypass de panel no se arregla solo con «tener buen antivirus en la PC». La defensa es en capas.

Activá 2FA en cPanel y en WordPress

El 2FA no hubiera bloqueado este CVE concreto (el bypass era anterior a la validación de credenciales), pero reduce el daño de phishing, reutilización de contraseñas y accesos robados. En 2020 ya hubo un bypass de 2FA por fuerza bruta (CVE-2020-27641); desde entonces el rate-limit mejoró. Igual: 2FA on, siempre.

Respaldos en otro servidor en otro datacenter

Si un atacante entra al panel, puede tocar archivos y bases. Necesitás copias fuera del servidor (offsite o al menos en otro almacenamiento), con retención y prueba de restauración. Un respaldo que nunca restauraste es una promesa, no un plan.

Plugins y temas de WordPress al día

Este CVE era del panel, no de WP. Pero en hosting compartido el sitio suele ser la superficie más grande. Plugins abandonados y usuario administrador sin 2FA o con una contraseña insegura siguen siendo la vía más común de hackeo y malware. Actualizá; borrá lo que no uses.

Aislamiento de cuentas (CloudLinux)

En HDS corremos CloudLinux con CageFS/LVE: cada cuenta ve su propio sistema de archivos virtual y tiene techos de CPU, RAM e I/O. Si una cuenta se compromete, el radio de ataque se acota. No es magia ni reemplaza el parche del panel, pero limita el salto lateral entre clientes del mismo servidor.

No compartas root por ticket a menos que sea inevitable

El incidente de soporte de cPanel en 2013 (abajo) lo deja claro: las credenciales que mandás por ticket viven en sistemas de terceros. Preferí SSH keys, accesos temporales y rotación al cerrar el caso.

Historial breve de incidentes de seguridad en cPanel

CVE-2026-41940 no es el primer susto serio del ecosistema. Contexto útil, sin drama:

Año	Incidente	Qué fue	Referencia
2008–2009	CSRF múltiple	CVE-2008-2043: acciones admin vía CSRF en interfaces cPanel. Mitigado con security tokens en 11.25.0.	Advisory cPanel
2013	Compromiso de servidor de soporte	Servidor del depto. de soporte de cPanel Inc. comprometido. Clientes que abrieron tickets (y a veces dejaron root) debieron rotar contraseñas.	Ars Technica, Sucuri
2016	Intento de breach en DB de usuarios	Base de usuarios de cPanel Store/Manage2: nombres, contactos y passwords hasheados+salteados. cPanel interrumpió el ataque; forzó resets. Tarjetas en sistema separado.	SecurityWeek, ZDNet
2020	Bypass de 2FA	CVE-2020-27641: sin rate-limit en códigos 2FA; brute force en minutos si el atacante ya tenía password.	BleepingComputer
2026	Auth bypass en login/sesiones	CVE-2026-41940 — este post. CVSS 9.8, KEV de CISA, explotación pre-parche y post-parche en hosts sin update.	NVD, The Register, cPanel KB

El patrón se repite: software central del hosting = blanco permanente. La diferencia entre un susto y un desastre es velocidad de parcheo, monitoreo y aislamiento.

Estado actual en HDS

• Servidores cPanel en builds parcheados.
• Sin IOCs de explotación exitosa del CVE-2026-41940 en nuestros hosts
• Monitoreo LFD + revisión de sesiones y auth en curso
• CloudLinux (CageFS/LVE) activo en el stack compartido
• Actualizaciones de seguridad del panel priorizados frente a nueva funcionalidad

Si querés ver cómo armamos la infraestructura y qué incluye cada plan: planes de hosting y servidores.

Fuentes

1. NIST NVD — CVE-2026-41940
2. CISA KEV — entrada CVE-2026-41940
3. cPanel Support — Security Update 04/28/2026 (KB)
4. cPanel Blog — CVE-2026-41940: Response, Actions and Next Steps (Neska Husar, may 2026)
5. The Register — Critical cPanel exploited: ‘Millions’ of sites could be hit (Carly Page, 1 may 2026)
6. Histórico: CVE-2008-2043, Ars Technica 2013, SecurityWeek 2016, BleepingComputer 2020 / CVE-2020-27641

---

¿Dudas sobre tu cuenta o tu build de cPanel? Escribinos a soporte. Si administrás tu propio servidor cPanel y todavía no corriste /scripts/upcp --force + el detection script del KB, hacelo hoy: el KEV de CISA no es decorativo.