La vulnerabilidad CVE-2026-41940 afecta al flujo de login/sesiones de cPanel & WHM; cPanel indica que afecta a versiones posteriores a 11.40 y publicó builds corregidas como 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20, 11.136.0.5, además de WP Squared 136.1.7. (cPanel Support)
WHM crea una sesión incluso cuando haces un login fallido. Esa sesión se guarda en:
/var/cpanel/sessions/raw/
/var/cpanel/sessions/cache/
/var/cpanel/sessions/preauth/
El flujo vulnerable es este:
1. Login malo → WHM crea una sesión pre-auth.
2. La cookie trae algo como:
whostmgrsession=:ABC123,deadbeefdeadbeefdeadbeefdeadbeef
3. La parte después de la coma es el secreto "ob".
4. Si envías la misma cookie pero quitando ",ob", cPanel sigue encontrando el fichero de sesión,
pero no cifra correctamente el campo pass.
5. Como Basic Auth permite meter CRLF en el password, el campo pass puede escribir líneas nuevas:
pass=x
user=root
hasroot=1
tfa_verified=1
successful_internal_auth_with_timestamp=...
6. Al principio solo se corrompe el raw.
7. Luego hay que forzar que cPanel relea el raw y lo propague a cache.
8. Entonces WHM ve la sesión como autenticada.
watchTowr explica que el fallo combina dos cosas: el pass de Basic Auth puede conservar \r\n, y si se usa una cookie sin el segmento ,<ob>, el encoder no se activa y el valor acaba escrito sin sanear en el fichero raw de sesión. (watchTowr Labs)
Asumo que tu WHM está en:
<https://LAB-IP:2087>
Cambia LAB-IP por tu host. Hazlo desde la misma máquina/IP durante todo el test, porque la sesión puede estar ligada a IP.
En el servidor cPanel:
/usr/local/cpanel/cpanel -V
Si ya estás en una versión parcheada, probablemente el PoC no va a funcionar. cPanel recomienda actualizar con:
/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard
Pero para el lab necesitas una snapshot vulnerable. (cPanel Support)