CVE-2026-41940 Technical Deep Dive: CRLF Injection, cpsrvd & Session Poisoning 2026

Technical analysis

CVE-2026-41940: Inside the cPanel authentication bypass

CRLF injection, session poisoning & zero-day exploitation — a technical breakdown for sysadmins, security engineers, and hosting providers. CVSS 9.8 Critical. Also read the general guide.

May 1, 2026 (published alongside companion article)

Technical summary

CVE-2026-41940 is described as a CRLF injection issue in cpsrvd (cPanel Service Daemon). By injecting carriage-return and line-feed characters through a crafted Authorization: Basic value — reportedly before authentication completes — an attacker may write arbitrary key-value pairs (including user=root) into a session file on disk. When cpsrvd later reads that session file, it can treat the session as a privileged WHM session. The attack is described as pre-authentication, remote, and unauthenticated.

Background: cPanel architecture and cpsrvd

cPanel & WHM is served by cpsrvd, which handles HTTP for the cPanel (e.g. port 2083) and WHM (e.g. port 2087) interfaces: routing, sessions, authentication, and UI delivery.

Sessions are stored under /var/cpanel/sessions/raw/<session_name>; the browser receives a cookie referencing the session. On later requests, cpsrvd reads the session file and decides authorization.

A key point in public analyses of this class of issue: cpsrvd may create session state on disk even when login fails, which changes the threat model compared to “failed login means no session.”

The vulnerability (reported chain)

Step 1: Failed login still creates session artifacts

An attacker may POST to /login/?login_only=1 with invalid credentials. The server can return 401 while still issuing a session cookie, for example:

POST /login/?login_only=1 HTTP/1.1
Host: target:2087
Content-Type: application/x-www-form-urlencoded

user=root&pass=wrongpassword

HTTP/1.1 401 Access Denied
Set-Cookie: whostmgrsession=:QSJN_sFdKZtCi2o_,4d257abc371539df; HttpOnly; secure

Cookie formats described in research often include a session name and a second segment (e.g. hex) used in normal operation to protect how values are written into the session file.

Step 2: Stripping the obfuscation segment

Follow-on requests may use the cookie without the segment after the comma, e.g.:

Cookie: whostmgrsession=:QSJN_sFdKZtCi2o_

Third-party writeups claim this path skips or weakens the obfuscation/encryption layer that would otherwise constrain attacker-controlled input during session writes.

Step 3: CRLF injection via Authorization header

The attacker supplies a Base64-encoded Basic payload that decodes to content containing literal \r\n, then CRLF-delimited lines such as user=root, for example:

Authorization: Basic [base64 of: username\r\nuser=root\r\n]

Because line breaks are meaningful in the session file format, injected lines can add or override session properties.

Step 4: Session reload

Further requests that cause cpsrvd to load the poisoned session file may interpret the session as fully privileged — i.e. WHM root-level access without valid user credentials.

Attack flow (visual)

Zero-day window and disclosure pressure

Public reporting cited exploitation activity as early as February 23, 2026, ahead of the April 28, 2026 advisory — a long exposure window for internet-facing panels. Commentary in the trade press emphasized patch plus forensics: if a host was exposed during the window, do not assume “patch alone” is sufficient.

Attack surface (reported scale)

Detection: was the server already compromised?

If TCP 2083/2087 were reachable without strict IP allowlists between February and April 28, 2026, treat investigation as mandatory.

1) Session files

ls -la /var/cpanel/sessions/raw/
# Inspect suspicious files:
# cat /var/cpanel/sessions/raw/<suspicious_file>

Look for unexpected properties such as user=root in abnormal contexts.

2) WHM authentication logs

grep -i 'ok\|success\|login' /usr/local/cpanel/logs/login_log | tail -500
grep 'root' /usr/local/cpanel/logs/login_log | grep -v 'fail\|wrong'

3) Privileged and new accounts

awk -F: '$3 == 0 {print}' /etc/passwd
awk -F: '{print $1, $3}' /etc/passwd | sort -k2 -n | tail -20

4) Web shells

find /home -name '*.php' -mtime -90 -ls 2>/dev/null
grep -rl 'eval(base64_decode' /home/ 2>/dev/null
grep -rl 'system($_' /home/ 2>/dev/null
grep -rl 'passthru($_' /home/ 2>/dev/null

5) Cron and persistence

crontab -l
cat /etc/cron.d/*
cat /etc/crontab
ls -la /etc/cron.hourly/ /etc/cron.daily/

Patching (commands)

/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/usr/local/cpanel/scripts/restartsrv_cpsrvd

Minimum patched builds cited alongside the advisory include: 11.86.0.41, 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, and WP Squared 136.1.7 (verify against your track).

Hardening (beyond the emergency patch)

• Firewall WHM (2087) to trusted IPs
• CSF + LFD where appropriate
• Two-factor authentication for WHM/cPanel
• Disable unused services (e.g. webdisk, cpdavd if unused)
• Off-server backups
• ModSecurity with a maintained ruleset where applicable
• Subscribe to vendor security channels (e.g. blog.cpanel.com)
• Centralized logging and alerts on privileged access
• Strong password policy for resellers/admins
• Periodic malware scanning (e.g. ClamAV, Maldet)

Conclusion

CVE-2026-41940 is a stark example of how a session-handling mistake in ubiquitous infrastructure can translate to unauthenticated administrative access. With public technical detail, assume automated exploitation and re-scanning. Patch, investigate, then harden.

References & further reading

• watchTowr Labs analysis
• Rapid7 advisory
• The Hacker News
• TechCrunch
• Canadian Centre for Cyber Security — search advisories for AL26-008
• NVD entry