Quién está involucrado
- cPanel Inc.: la empresa dueña del software, que publicó el parche el 28 de abril.
- watchTowr Labs: la firma de ciberseguridad que descubrió, documentó y publicó el exploit funcional.
- KnownHost: proveedor de hosting que confirmó que la falla ya estaba siendo usada como zero-day antes de la divulgación pública.
- Namecheap, HostPapa, InMotion y otros proveedores: bloquearon temporalmente los puertos de cPanel para sus clientes mientras desplegaban los parches.
- Aproximadamente 1.500.000 servidores con cPanel expuestos a internet, según escaneos de Shodan citados por Rapid7.
Por qué importa
cPanel no es un software cualquiera. Es el panel de control más usado del mundo para administrar sitios web. Cuando alguien contrata un hosting compartido en SiteGround, GoDaddy, Bluehost, HostGator o cualquier proveedor paraguayo serio, lo más probable es que la pantalla con íconos para gestionar correos, bases de datos, archivos y certificados SSL sea cPanel. WHM es la versión administrador, la que controla el servidor entero.
Pensalo así: cPanel es la llave del departamento. WHM es la llave del edificio entero. Y con esta falla, cualquiera puede entrar al edificio sin ninguna llave, abrir todos los departamentos, leer la correspondencia de todos los inquilinos, copiar las llaves y dejar puertas traseras instaladas para volver cuando quiera.
Un servidor cPanel típico aloja entre 50 y 500 sitios distintos. Comprometer uno solo significa comprometer cientos de webs simultáneamente: bases de datos de clientes, correos corporativos, sistemas de e-commerce, contraseñas, datos personales. Todo.
Cómo funciona el ataque, en español simple
Sin entrar en detalle técnico que solo serviría a quien quiera replicarlo, el ataque sigue una lógica perversa pero elegante:
El atacante manda un intento de login deliberadamente fallido. cPanel, antes incluso de revisar si la contraseña está bien, crea un archivo de sesión temporal en el disco y le entrega al atacante un cookie ligada a ese archivo. Hasta acá, todo normal.
El problema: el atacante puede modificar esa cookie para desactivar el cifrado de contraseñas. Y cuando manda un segundo intento de login, inserta saltos de línea ocultos dentro del campo de contraseña. cPanel, en lugar de filtrar esos saltos de línea, los escribe tal cual en el archivo de sesión. Cada salto de línea se convierte en un nuevo registro falso.
El atacante inyecta líneas que dicen literalmente "este usuario es root" y "este usuario ya pasó la verificación de contraseña". Después visita cualquier página del sitio para forzar a cPanel a recargar el archivo, y en la siguiente solicitud, el sistema ve la bandera falsa, confía en ella, y deja entrar al atacante como administrador absoluto.
De principio a fin: un puñado de pedidos HTTP. Cinco minutos. Sin contraseña. Sin alertas. Sin rastros visibles para el dueño del servidor que no sepa exactamente dónde mirar.
Análisis crítico
Esto no es una falla simple. Es una falla que estuvo abierta durante meses mientras alguien la usaba en silencio. KnownHost confirmó intentos de explotación desde el 23 de febrero de 2026. Es decir: durante más de dos meses, atacantes desconocidos tuvieron acceso administrativo completo a una cantidad indeterminada de servidores antes de que el público se enterara.
Hay varios puntos que conviene marcar sin tibiezas:
Primero, cPanel demoró en publicar detalles técnicos. La advertencia inicial del 28 de abril usaba lenguaje deliberadamente vago: "un problema con la carga y guardado de sesiones". Recién al día siguiente, cuando watchTowr publicó el análisis técnico completo, el público entendió la magnitud real. Esa demora editorial es entendible —no se quiere dar el manual a los atacantes— pero también significó que muchos administradores no sintieron la urgencia hasta que ya era demasiado tarde.
Segundo, la respuesta de la industria fue desigual. Proveedores serios como Namecheap, HostPapa e InMotion bloquearon proactivamente los puertos de cPanel hasta aplicar el parche, sacrificando disponibilidad por seguridad. Otros simplemente esperaron. La diferencia entre un cliente protegido y un cliente expuesto, en este caso, dependió enteramente de qué empresa lo aloja.
Tercero, el dato más incómodo: si tu servidor estuvo en una versión vulnerable entre el 23 de febrero y el día que se aplicó el parche, debés asumir que pudo haber sido comprometido, aunque no veas señales evidentes. cPanel publicó un script de detección, pero la recomendación oficial es rotar todas las contraseñas, claves API, certificados SSL, claves SSH y contraseñas de base de datos del servidor afectado. Eso no se hace en cinco minutos.
Antecedentes
cPanel arrastra un historial de fallas críticas. En 2022 ya se había reportado una vulnerabilidad de Cross-Site Scripting (XSS) que permitía robar sesiones. En años anteriores hubo problemas con el manejo de tokens de autenticación de dos factores. Lo que distingue a CVE-2026-41940 de las anteriores es que no requiere ningún tipo de credencial previa, ni interacción del usuario, ni privilegio de ningún tipo. Es lo que en seguridad se llama un unauthenticated remote code execution path: un atacante anónimo, desde cualquier punto de internet, con un puñado de pedidos HTTP, gana control total.
El patrón también es revelador. La falla específica es una inyección de CRLF (Carriage Return Line Feed): una clase de vulnerabilidad documentada y conocida desde hace más de 20 años, donde el software no filtra correctamente los caracteres de salto de línea que el atacante mete en los datos. Que un panel de control crítico, instalado en millones de servidores, tenga una falla de esta categoría en 2026, dice algo sobre las prácticas de desarrollo seguro de la industria.
Situación actual
Las versiones parcheadas, publicadas el 29 de abril por cPanel, son las siguientes:
- cPanel/WHM 110.0.x → 11.110.0.97
- cPanel/WHM 118.0.x → 11.118.0.63
- cPanel/WHM 126.0.x → 11.126.0.54
- cPanel/WHM 132.0.x → 11.132.0.29
- cPanel/WHM 134.0.x → 11.134.0.20
- cPanel/WHM 136.0.x → 11.136.0.5
Si tu servidor tiene auto-actualizaciones activadas, lo más probable es que ya esté parcheado. Si no, hay que actualizar manualmente con urgencia. Para quienes no pueden parchear de inmediato, cPanel recomienda como medida temporal bloquear los puertos 2083, 2087, 2095 y 2096 desde el firewall, o apagar los servicios cpsrvd y cpdavd hasta tener el parche aplicado.
Imperva, una de las firmas de seguridad que monitorea ataques en tiempo real, ya detectó cerca de 4.000 intentos de explotación en sus clientes desde la divulgación, distribuidos en 17 países y 15 industrias. El ataque masivo y oportunista ya está en curso.
Qué puede pasar
Lo que esperamos que pase
Que la mayoría de los proveedores de hosting serios —los que monitorean activamente los avisos de seguridad y tienen procesos de parcheo automatizado— ya hayan aplicado las actualizaciones en las primeras 48 horas. Que los servidores con auto-update activo se cierren solos. Que las firmas de ciberseguridad como Imperva, Cloudflare y Akamai sigan bloqueando los intentos masivos en el borde de la red. Que el daño total termine concentrándose en servidores mal mantenidos, hosting baratos sin actualizaciones, y operadores que descubrieron el problema demasiado tarde.
Lo que no debe pasar
Que los administradores de servidores comprometidos antes del parche no roten credenciales. Aplicar el parche cierra la puerta hacia adelante, pero no expulsa al atacante que ya entró antes. Si alguien obtuvo acceso root entre febrero y abril, tiene tiempo de sobra para haber instalado puertas traseras, robado certificados SSL, exfiltrado bases de datos completas, y estar usando esa información ahora mismo. Sin una rotación completa de credenciales y una auditoría seria de los archivos del servidor, parchear el sistema no resuelve nada para quien ya fue víctima.
Tampoco debe pasar que esto se trate como una falla técnica más, archivada en una página de soporte. Setenta millones de sitios es la mitad de la web comercial del mundo. La conversación pública sobre seguridad de hosting compartido tiene que ser otra después de esto.
Conclusión
Hay un punto incómodo que esta noticia obliga a mirar de frente: no toda empresa de hosting es igual. Los proveedores que tomaron decisiones drásticas —bloquear puertos, sacrificar disponibilidad, comunicar proactivamente a clientes— actuaron como deben actuar empresas responsables de infraestructura crítica. Otros simplemente esperaron a que pase. La diferencia, en términos prácticos, es la diferencia entre un cliente cuyos datos siguen seguros y un cliente que probablemente ya fue comprometido y todavía no lo sabe.
Cuando uno contrata hosting, no está comprando un producto. Está delegando la custodia de sus datos, los datos de sus clientes, y la continuidad de su negocio. El precio importa, pero importa mucho menos que la respuesta a preguntas concretas: ¿quién avisa cuando hay una falla crítica? ¿Quién aplica los parches sin que tengas que pedirlo? ¿Quién monitorea los servidores fuera de horario laboral? La respuesta, casi siempre, separa a las empresas serias de las que ofrecen un panel bonito por dos dólares al mes.
CVE-2026-41940 va a desaparecer del ciclo de noticias en una semana. Lo que va a quedar son los servidores comprometidos, los datos robados, y la diferencia, ahora sí evidente, entre quienes tomaron en serio la responsabilidad y quienes no.