CVE-2026-41940 — Bypass de Root en Pre-Autenticación en cPanel y WHM mediante Inyección CRLF en Archivos de Sesión

Un análisis técnico profundo orientado a defensores

1. Resumen ejecutivo

cPanel y WHM son el software de panel de control dominante para el alojamiento web compartido y de reventa. cPanel es la interfaz de cuentas orientada al cliente; WHM es la interfaz administrativa de nivel root utilizada por los proveedores de hosting y los propietarios de servidores. Ambos son servidos por el mismo demonio Perl, cpsrvd, que escucha en puertos emparejados para cada superficie (cPanel: 2082/2083, WHM: 2086/2087, Webmail: 2095/2096).

CVE-2026-41940 permite a un atacante sin credenciales de ningún tipo manipular el estado de la sesión en disco antes de que se produzca la autenticación, haciendo que cpsrvd reinterprete posteriormente datos proporcionados por el atacante como atributos de sesión legítimos, completamente autenticados y con privilegios root. El resultado es el compromiso total del plano de gestión de todos los sitios web y cuentas alojados en el servidor — no es un problema de un solo inquilino, sino de todo el servidor, de todo el proveedor y, en conjunto, de toda la industria, dada la concentración de mercado de cPanel.

2. Por qué esta vulnerabilidad es importante más allá de su puntuación CVSS

Una puntuación CVSS de 9.8 es lo bastante común como para volverse anestesiante de leer. Tres factores estructurales hacen que CVE-2026-41940 sea inusualmente grave en la práctica:

1. El radio de explosión es todo el servidor, no una cuenta. El compromiso de WHM es un compromiso de root. Cada cuenta de cliente, cada base de datos, cada clave privada TLS, cada copia de seguridad y cada zona DNS de ese servidor quedan inmediatamente dentro del alcance.

2. Fue un verdadero zero-day durante aproximadamente dos meses. La telemetría de KnownHost sitúa la explotación inicial alrededor del 23 de febrero de 2026, mucho antes del parche del 28 de abril. Cualquier organización que estuviera expuesta a Internet durante esa ventana debería asumir que el compromiso es posible, no meramente teórico, y realizar una evaluación retrospectiva de compromiso en lugar de confiar en «parcheamos, así que estamos bien».

3. La mayoría de las organizaciones afectadas no pueden parchear esto por sí mismas. cPanel es implementado normalmente por los proveedores de hosting en nombre de los inquilinos. Los clientes finales no tienen control a nivel de código sobre la corrección y dependen por completo del ritmo de aplicación de parches de su proveedor — que es exactamente la razón por la que varios hosts importantes (Namecheap, KnownHost, HostPapa, InMotion) optaron por bloquear preventivamente el tráfico entrante a los puertos afectados en lugar de esperar a que cada inquilino actualizara.

Este tercer punto merece atención. cPanel controla un estimado del 94 % del mercado de paneles de control. Un único fallo lógico en el código de gestión de sesiones de un proveedor se convirtió, durante un período de semanas, en una vulnerabilidad de acceso root de facto en toda la industria. Ese riesgo de concentración es un tema recurrente que vale la pena interiorizar independientemente de este CVE concreto.

3. Contexto arquitectónico

3.1 cpsrvd y el modelo de puertos

cpsrvd es un demonio Perl de larga duración que sirve las tres superficies de producto de cPanel desde el mismo binario y, de forma crítica, desde el mismo camino de código de gestión de sesiones:

Dado que las tres superficies comparten la lógica de sesión vulnerable, la exposición de cualquiera de estos seis puertos es suficiente para la explotación: no existe entre ellas una superficie «menos expuesta» de forma significativa. En entornos bien segmentados, ninguno de estos puertos debería ser directamente accesible desde Internet en primer lugar; en la práctica, la conveniencia de gestión, los acuerdos de hosting híbrido y la deriva de los firewalls hicieron que muchos lo fueran.

3.2 La representación dual de la sesión

Las sesiones de cPanel se persisten en dos representaciones paralelas en disco, aparentemente por razones de rendimiento:

1. Archivo de sesión sin procesar (/var/cpanel/sessions/raw/<session-id>) — un formato de texto plano key=value orientado a líneas, un atributo por línea.
2. Caché JSON (/var/cpanel/sessions/cache/<session-id>, conceptualmente) — un documento JSON estructurado, leído de forma preferente por la ruta normal de peticiones porque es más barato de analizar.

En el funcionamiento ordinario, la caché JSON es la autoritativa y el archivo sin procesar es un respaldo de durabilidad. La vulnerabilidad existe precisamente porque hay circunstancias en las que el archivo sin procesar se vuelve a analizar y se utiliza para regenerar la caché JSON, y los dos formatos discrepan sobre lo que significa un carácter de nueva línea incrustado.

4. Causa raíz: cuatro fallos independientes que se encadenan

CVE-2026-41940 no es un único error. Es el producto de cuatro debilidades separadas, cada una individualmente plausible como decisión de diseño aislada, que se alinean para producir un bypass completo de autenticación. Esta estructura de «queso suizo» es instructiva para defensores y revisores de código mucho más allá de este producto específico.

4.1 Capa 1 — Saneamiento impuesto por convención, no por la propia ruta de escritura

El subsistema de sesiones de cPanel ya disponía de una rutina de saneamiento responsable de eliminar los caracteres peligrosos — retornos de carro, saltos de línea y = — de los valores de sesión antes de que se persistieran. El problema es desde dónde se invocaba esa rutina: vivía dentro de las funciones wrapper de nivel superior (la API de «crear»/«modificar» sesión), y era responsabilidad del llamador pasar por esos wrappers en lugar de escribir los datos de sesión directamente.

El manejador de autenticación HTTP Basic dentro de cpsrvd — la ruta de código que acepta credenciales directamente de la cabecera HTTP Authorization — persistía la contraseña enviada en el archivo de sesión de pre-autenticación a través de una rutina de guardado de nivel inferior que evitaba por completo el wrapper de saneamiento. Debido a que el saneamiento era opcional en lugar de obligatorio en el punto de escritura en disco, este único llamador lo omitió silenciosamente.

Este es el modo de fallo de manual de «validar en la fuente, no en el sumidero»: mientras un control de seguridad pueda ser evadido simplemente llamando a una función distinta, acabará siéndolo, ya sea por descuido, por refactorización o por una ruta de código que a nadie se le ocurrió auditar contra este control específico. El parche definitivo que cPanel distribuyó mueve la llamada de saneamiento dentro de la propia función de guardado, de modo que ya no puede ser omitida por ningún llamador, presente o futuro.

4.2 Capa 2 — Cifrado que la entrada controlada por el atacante podía desactivar

El escritor de sesiones cifra los campos sensibles (en particular el campo de contraseña) utilizando una clave simétrica por sesión. Esa clave se deriva de un componente incrustado en la cookie de sesión que presenta el cliente. En el código vulnerable, si ese componente de clave estaba ausente de la petición — algo completamente dentro del control del atacante, ya que ellos eligen qué cookie enviar — el paso de cifrado se omitía silenciosamente en lugar de rechazarse la escritura.

En otras palabras: un atacante que omita o trunque deliberadamente parte de su cookie de sesión puede lograr que sus propios datos enviados se escriban en disco sin cifrar. Un cifrado cuya activación puede ser desactivada por la parte no confiable que suministra la entrada no es una frontera de seguridad significativa; debería fallar en modo seguro (negarse a persistir, o rechazar la petición) en lugar de fallar en modo abierto (persistir sin protección).

4.3 Capa 3 — Desacuerdo de formato entre el archivo sin procesar y la caché JSON

Este es el quid de la «inyección» en la inyección CRLF. El archivo de sesión sin procesar está delimitado por líneas: una secuencia de retorno de carro / salto de línea termina un registro key=value y comienza el siguiente. El formato de la caché JSON, por el contrario, representa la misma secuencia de caracteres como una subcadena escapada dentro de un único valor de cadena JSON — semánticamente inerte, solo datos.

Mientras una sesión solo exista en la caché JSON, un CRLF incrustado en un campo como la contraseña es inofensivo — son solo bytes dentro de una cadena. El peligro aparece en la ruta de código que vuelve a analizar el archivo sin procesar y regenera la caché. Esto ocurre, según los análisis técnicos públicos, cuando una petición es rechazada por fallar una comprobación de token de seguridad vinculado a la URL; el manejador responsable de ese rechazo vuelve a cargar la sesión omitiendo la caché y releyendo el archivo sin procesar línea por línea, y luego reescribe la caché JSON a partir de ese nuevo análisis.

En ese momento, las secuencias CRLF que el atacante incrustó en su «contraseña» enviada dejan de ser bytes inertes dentro de un campo y se convierten en separadores de registros, dividiendo lo que debería haber sido un único valor en múltiples líneas key=value independientes. Cada una de esas líneas — incluidas aquellas cuyo nombre y valor el atacante controla por completo — es entonces promovida a una entrada de nivel superior en la caché JSON de sesión regenerada, indistinguible para el resto del código de un atributo de sesión establecido legítimamente.

La lección general: siempre que dos analizadores puedan ser inducidos a interpretar la secuencia de bytes idéntica de forma diferente — sin procesar vs. caché, codificación de formulario vs. JSON, una convención de escape vs. otra — ese desacuerdo es una primitiva de inyección latente. No importa qué analizador sea «más correcto»; lo que importa es que los datos no confiables puedan cruzar entre las dos representaciones sin ser revalidados contra la gramática del segundo analizador.

4.4 Capa 4 — Una marca de «ya autenticado» sin vinculación criptográfica

El eslabón final de la cadena está en la propia lógica de comprobación de contraseña. Si una sesión ya lleva un campo que registra una marca de tiempo de autenticación interna exitosa reciente, el desafío de contraseña se omite por completo: la sola presencia de ese campo se trata como prueba suficiente de que la autenticación ya tuvo éxito. Una marca complementaria de verificación en dos factores suprime de forma similar el desafío 2FA basándose puramente en su presencia.

Ambos campos existen para fines internos legítimos (transferencias de inicio de sesión único entre componentes de cPanel, herramientas internas que ya han validado a un usuario por otro medio). El defecto de diseño es que ninguno de los dos campos está vinculado criptográficamente a ningún evento de autenticación real — son atributos de sesión simples que, una vez que la Capa 3 permite a un atacante escribir atributos de sesión arbitrarios, pueden simplemente falsificarse. Una marca que significa «confía en mí, esto ya fue comprobado» solo tiene sentido si no puede ser establecida por la parte en quien se confía.

4.5 Efecto compuesto

Ninguna de estas cuatro debilidades es catastrófica de forma independiente:

• Una llamada de saneamiento ausente es un bug latente hasta que algo lee los datos contaminados de forma diferente a como fueron escritos.
• Omitir el cifrado cuando falta la clave es una preocupación de confidencialidad hasta que el propio contenido en texto plano se vuelve explotable.
• Un desajuste de formato entre dos representaciones es inerte hasta que algo vuelve a derivar una representación a partir de la otra.
• Una marca de confianza no autenticada es segura mientras nada más permita a un atacante establecerla.

Encadenadas, producen un compromiso root remoto, completo y no autenticado. Este es precisamente el tipo de vulnerabilidad que las pruebas unitarias limitadas a funciones individuales no detectarán, porque ninguna función individual es «incorrecta» de forma aislada — el fallo vive en la interacción entre subsistemas que fueron razonados cada uno de forma independiente.

5. Flujo de ataque conceptual

A continuación se describen las etapas lógicas de la explotación, al nivel de detalle ya público en los avisos del proveedor y de la industria, sin reproducir bytes de payload literales, cabeceras codificadas ni una secuencia de peticiones ejecutable.

A partir de la Etapa 5, un atacante dispone de acceso ordinario y totalmente autorizado a la API de WHM. El conjunto de funciones legítimas de WHM — hooks personalizados, gestión de paquetes/plantillas, configuración de manejadores PHP, gestión de cron y cuentas, edición de zonas DNS — es más que suficiente para escalar esto hasta ejecución interactiva de código root a través de funcionalidad administrativa completamente «soportada», sin necesidad de vulnerabilidad adicional.

Los informes públicos señalan que la cadena de extremo a extremo requiere solo un pequeño número de peticiones HTTP e implica una condición de carrera benigna en torno al orden no determinista de las claves hash de Perl durante la regeneración de la caché — lo que significa que puede ser necesario un pequeño número de reintentos para una fiabilidad completa, un detalle con valor de detección (ver §7.3).

6. Cronología

7. Ingeniería de detección

7.1 Indicadores basados en el sistema de archivos (la señal más alta)

La evidencia más sólida vive en el propio almacén de sesiones sin procesar, /var/cpanel/sessions/raw/. Una sesión originada a partir de un inicio de sesión fallido o sin privilegios nunca debería contener legítimamente ninguno de los siguientes campos de nivel superior:

• user=root
• hasroot=1
• tfa_verified=1
• successful_internal_auth_with_timestamp=<value>

...a menos que esa sesión haya completado genuinamente una autenticación root adecuada y un desafío 2FA a través del flujo de inicio de sesión normal. La presencia de estos campos en una sesión cuyos metadatos de origen muestran un intento de contraseña fallido es un fuerte indicador de explotación.

Una señal de confianza aún mayor: múltiples líneas pass= dentro de un único archivo de sesión. En el funcionamiento normal, una sesión tiene exactamente un campo de contraseña. Las ocurrencias múltiples solo las produce el comportamiento de división por CRLF subyacente a esta vulnerabilidad, y deben tratarse como un indicador de compromiso casi certero.```bash

Sessions carrying privileged top-level fields

grep -lE '^(hasroot|tfa_verified|successful_internal_auth_with_timestamp)=1'
/var/cpanel/sessions/raw/* 2>/dev/null

Sessions with an embedded carriage return inside the password field

(indicative of CRLF-split injection rather than a single legitimate value)

grep -lP 'pass=.\r' /var/cpanel/sessions/raw/ 2>/dev/null

Sessions with more than one "pass=" line — should never legitimately occur

for f in /var/cpanel/sessions/raw/*; do n=$(grep -c '^pass=' "$f" 2>/dev/null) [ "${n:-0}" -gt 1 ] && echo "SUSPECT: $f ($n pass= lines)" done

### 7.2 Correlación de registros de acceso (cuando los archivos de sesión no se reenvían de forma centralizada)

Si los archivos de sesión sin procesar no se conservan el tiempo suficiente, o no se reenvían a un sistema de registro centralizado, los registros de acceso de `cpsrvd` pueden servir como sustituto. Dos patrones de correlación son útiles:

**Patrón A — un inicio de sesión fallido seguido inmediatamente de una cabecera Basic-auth fuera de lugar.** Un cliente normal no envía una cabecera `Authorization: Basic` en una solicitud a una URL arbitraria que no sea de inicio de sesión inmediatamente después de un POST de contraseña fallido desde la misma fuente. Esta secuencia — un `401` en el endpoint de inicio de sesión seguido, dentro de una ventana corta, de una solicitud con Basic-auth en otro lugar, correlacionada por IP de origen y/o cookie de sesión — es anómala y merece una alerta.

**Patrón B — un token estilo `cpsess` que aparece en una URL antes de haber sido emitido legítimamente.** Los tokens de seguridad legítimos por sesión se generan en el servidor y aparecen por primera vez en una respuesta `Set-Cookie`/redirección *antes* de utilizarse en las URL de solicitudes posteriores. Un token que aparece en una URL de solicitud entrante sin una aparición previa emitida por el servidor es inconsistente con el comportamiento normal del cliente y merece ser señalado, particularmente si el token no coincide con el formato esperado generado por el servidor.

### 7.3 Señal de comportamiento / reintentos

Debido a que la regeneración de la caché está sujeta al ordenamiento no determinista de las claves hash de Perl, se ha observado en el campo que la explotación exitosa a veces requiere un pequeño número de reintentos antes de que los campos deseados "ganen" en la caché regenerada. Una ráfaga corta de solicitudes estructuralmente similares (misma fuente, misma sesión, mismo patrón de URL objetivo, con pocos segundos de diferencia entre ellas) seguida inmediatamente del uso exitoso de la API administrativa es una señal corroborante secundaria que vale la pena ponderar junto con §7.1 y §7.2 — por sí sola es demasiado genérica para alertar, pero refuerza la confianza cuando se combina con los indicadores de sistema de archivos o registros de acceso mencionados anteriormente.

### 7.4 Indicadores posteriores al compromiso

Debido a que el acceso a WHM es acceso root, trate la explotación confirmada como una investigación de compromiso completo del host, no como un incidente de aplicación web. Busque:

- Cuentas de usuario inesperadas a nivel de WHM/root o cuentas de revendedor creadas fuera de los procesos de gestión de cambios
- Claves públicas SSH nuevas o no reconocidas en `~/.ssh/authorized_keys` de `root` o de cualquier cuenta alojada
- Entradas cron no reconocidas, tanto a nivel de sistema como por cuenta alojada
- "Hooks" personalizados de WHM que no fueron aprovisionados por administradores conocidos
- Cambios inesperados en la configuración del manejador de PHP, definiciones de paquetes/plantillas o archivos de zona DNS
- Conexiones salientes o procesos que se ejecutan como root y que no corresponden a servicios cPanel/WHM conocidos

---

## 8. Manual de mitigación y respuesta a incidentes

### 8.1 Acciones inmediatas

1. **Realice un inventario** de cada instancia de cPanel/WHM/WP Squared bajo su control o el de su proveedor.
2. **Determine la exposición a internet** de cada instancia durante las ventanas de divulgación y pre-divulgación (trate el período del 23 de febrero al 28 de abril de 2026 como la ventana de exposición de interés).
3. **Aplique el parche a una versión corregida:**

   | Rama | Versión mínima parcheada |
   |---|---|
   | 11.110.0.x | 11.110.0.97 |
   | 11.118.0.x | 11.118.0.63 |
   | 11.126.0.x | 11.126.0.54 |
   | 11.132.0.x | 11.132.0.29 |
   | 11.134.0.x | 11.134.0.20 |
   | 11.136.0.x | 11.136.0.5 |
   | WP Squared | 11.136.1.7 |

4. **Verifique** la versión aplicada con `/usr/local/cpanel/cpanel -V`.
5. **Reinicie `cpsrvd`** después de aplicar el parche — un demonio no reiniciado puede seguir ejecutando código vulnerable en memoria (`/scripts/restartsrv_cpsrvd`).
6. Si depende de un host de terceros, **confirme el estado del parche directamente con el proveedor** en lugar de asumir que se ha aplicado.
7. Los servidores con **actualización automática deshabilitada o versión fijada** no se auto-repararán — estos requieren intervención manual explícita y deben priorizarse, ya que estadísticamente son los más propensos a seguir siendo vulnerables.

### 8.2 Corto plazo (a los pocos días de aplicar el parche)

- Ejecute las consultas de detección basadas en sistema de archivos y registros de la §7 contra la ventana de exposición completa, no solo "desde que nos dimos cuenta".
- Audite WHM en busca de cuentas, claves SSH, entradas cron y hooks personalizados inesperados.
- Verifique la integridad de `/etc/`, `/usr/local/cpanel/` y los archivos de configuración del shell de root/`authorized_keys` contra líneas base conocidas como válidas o copias de seguridad.
- Rote las contraseñas WHM de root y revendedores, tokens de API y claves SSH **independientemente de si se encontraron indicadores de compromiso** — dada la ventana de explotación de dos meses previa a la divulgación, la ausencia de evidencia no es evidencia sólida de ausencia en un host que estuvo expuesto durante todo ese período.
- Depure el estado de sesión (`/var/cpanel/sessions/raw/` y el directorio de caché JSON) después de aplicar el parche, para que ninguna sesión falsificada residual pueda reproducirse.

### 8.3 Endurecimiento a largo plazo

- Restrinja el acceso entrante a los puertos de cPanel/WHM/Webmail (2082, 2083, 2086, 2087, 2095, 2096) a rangos de IP administrativos conocidos mediante listas de permitidos en el firewall. Estos puertos del plano de gestión no deberían ser ampliamente accesibles desde internet en condiciones operativas normales.
- Reenvíe los registros de acceso de `cpsrvd` — e idealmente los eventos de escritura de sesión — a un SIEM con retención centralizada, ya que los archivos de sesión en el host son efímeros y se pierden fácilmente durante el triaje si no se conservan rápidamente.
- Establezca un inventario de referencia de las cuentas WHM, claves SSH y trabajos cron esperados, y monitorice cualquier desviación.
- Realice un seguimiento de la versión de cPanel/WHM y la cadencia de parcheo como una métrica de gestión de activos de primera clase, particularmente para cualquier instancia autogestionada (no externalizada).

### 8.4 Si se confirma un compromiso

- **No intente la remediación in situ de un host comprometido a nivel root.** Una vez obtenido el acceso root, el atacante tuvo la capacidad de modificar cualquier cosa, incluidas las herramientas que usaría para investigar. Trate la "limpieza" in situ como poco fiable.
- **Reconstruya a partir de imágenes conocidas como limpias y parcheadas** en lugar de aplicar el parche y seguir ejecutando el sistema potencialmente comprometido.
- **Rote todas las credenciales administrativas** en todo el servidor, no solo las directamente implicadas.
- **Reemplace todas las claves SSH**, incluidas las pertenecientes a cuentas de clientes alojadas, ya que un atacante a nivel root podría haber recolectado o plantado cualquiera de ellas.
- **Asuma que todos los datos de clientes alojados en el equipo fueron expuestos** y cumpla con las obligaciones aplicables de notificación de brechas de datos.
- **Investigue el movimiento lateral** hacia segmentos de red internos adyacentes, ya que la infraestructura de alojamiento comprometida es un punto de pivote común hacia entornos corporativos (por ejemplo, mediante credenciales, relaciones de confianza SSH o secretos compartidos reutilizados en otros lugares).

---

## 9. Preguntas frecuentes

**¿Es propagable como gusano / apto para explotación automatizada masiva?**
La cadena subyacente es completamente no autenticada e implica un número pequeño y fijo de solicitudes HTTP, razón por la cual CISA la elevó al estado KEV y por la cual ya han surgido públicamente herramientas de escaneo masivo que referencian este CVE. Trate cualquier instancia sin parchear y alcanzable desde internet como en riesgo activo de compromiso oportunista y automatizado, no solo de ataque dirigido.

**¿La autenticación de dos factores protege contra esto?**
No. La inyección falsifica directamente la bandera de sesión "2FA ya verificada", por lo que el desafío 2FA nunca se presenta en primer lugar. La 2FA no proporciona ninguna mitigación para esta vulnerabilidad específica.

**¿Mi WAF detectará esto?**
Solo si normaliza/inspecciona las cargas útiles `Authorization: Basic` en busca de secuencias CRLF incrustadas *y* además inspecciona por separado las cookies de sesión en busca del patrón malformado/truncado asociado con la condición de omisión del cifrado. Los conjuntos de reglas WAF genéricos generalmente no detectaron la explotación de este problema antes de su divulgación. El parcheo sigue siendo obligatorio independientemente de la postura del WAF.

**¿Esto afecta a las implementaciones cPanel DNSOnly?**
Sí, según el aviso del proveedor — las instalaciones DNSOnly están dentro del alcance.

**¿Están afectadas las versiones antiguas no compatibles (anteriores a 11.40) de cPanel?**
No — según el análisis público, la ruta de código vulnerable no estaba presente en versiones anteriores a la rama 11.40, ya que las versiones legadas no compatibles son anteriores a la implementación relevante del manejo de sesiones.

**¿Hay una solución alternativa disponible si no puedo aplicar el parche de inmediato?**
No existe ninguna solución alternativa funcional que cierre completamente la vulnerabilidad aparte de aplicar el parche. La única mitigación intermedia efectiva es bloquear el acceso entrante a los puertos afectados (2082/2083, 2086/2087, 2095/2096) en el perímetro de la red, o detener por completo los servicios `cpsrvd`/`cpdavd`, ambas opciones a costa también del acceso legítimo.

---

## 10. Lecciones más amplias para la ingeniería de software y seguridad

Independientemente de cPanel específicamente, esta vulnerabilidad es un caso de estudio útil para cualquiera que revise código de autenticación y manejo de sesiones en otros lugares:

1. **Sanitice en el punto de persistencia, no a discreción del llamador.** Cualquier control de seguridad que pueda evadirse simplemente llamando a una función diferente en el mismo subsistema terminará siendo evadido — ya sea por un atacante que encuentra la brecha, o por un ingeniero futuro que no sabe que existe.
2. **Los controles de seguridad deben fallar en modo cerrado ante entradas ausentes o malformadas, nunca fallar en modo abierto.** Si una operación criptográfica depende de material proporcionado por el cliente, la ausencia de ese material debería abortar la operación, no omitir silenciosamente la protección que debía proporcionar.
3. **Toda representación dual de los mismos datos es una primitiva potencial de contrabando.** Siempre que un sistema mantenga dos serializaciones del mismo estado (crudo vs. en caché, codificado en formulario vs. JSON, escapado vs. sin escapar) y posteriormente vuelva a derivar una de la otra, audite esa ruta de re-derivación específicamente para casos en los que datos no confiables puedan cruzar el límite sin filtrar.
4. **Las banderas de confianza deben estar criptográficamente vinculadas al evento que afirman, no meramente presentes.** Un atributo de sesión que significa "la autenticación ya fue exitosa" solo es seguro si un atacante no puede establecer ese atributo de forma independiente — mediante una firma, MAC o vinculación equivalente con el evento de autenticación real, no a través de almacenamiento no autenticado.
5. **Cualquier cosa escrita en disco como consecuencia de una solicitud no autenticada debe tratarse como controlada por el atacante**, incluidos los datos que solo son leídos por *otras* rutas de código aparentemente no relacionadas. El peligro en esta vulnerabilidad no estaba en el código que escribió los datos — estaba en una ruta de código completamente diferente y posterior que los re-interpretó bajo reglas de análisis distintas.

---

## 11. Referencias

- Aviso de seguridad de cPanel — *Vulnerabilidad crítica en la autenticación de inicio de sesión de cPanel y WHM*, 28 de abril de 2026 — `docs.cpanel.net/release-notes/release-notes`
- watchTowr Labs — análisis original de causa raíz y prueba de concepto, Sina Kheirkhah, 29 de abril de 2026 — `labs.watchtowr.com`
- Rapid7 — Emerging Threat Report sobre CVE-2026-41940 — `rapid7.com`
- Arctic Wolf — resumen de la amenaza CVE-2026-41940 — `arcticwolf.com`
- Hadrian — *CVE-2026-41940: una evasión crítica de autenticación en cPanel* — `hadrian.io`
- Picus Security — *CVE-2026-41940 explicado: la evasión de autenticación de cPanel y WHM que afectó a 1.5M de servidores* — `picussecurity.com`
- Entrada del catálogo Known Exploited Vulnerabilities (KEV) de CISA para CVE-2026-41940 — `cisa.gov`
- BleepingComputer, The Hacker News, CyberScoop — cobertura contemporánea de la divulgación y la explotación en la naturaleza
- Registro de cambios de WP Squared — `docs.wpsquared.com/changelogs`
- Aviso comunitario de KnownHost que documenta la sospecha de explotación previa a la divulgación