[Resolved] Potential false positive with script ioc_checksessions_files.sh of CVE-2026-41940 post

Edit:
New detecton script released on 05/01/26 11:52AM CST confirms we had 100% falsepositive on our network. We suggest everyone to rerun the new script at there earliest convience. https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026


Original post for historic keeping:
We request a urgent review because we suspect a lot of false positives that will surface and users that might think the servers are conpromised without any real evidence.

We would normally send in a ticket; however, due to the potential nature of this case, we feel an open conversation is more suited. If cPanel would rather have this sent as a ticket, then let us know, and we will do so.

IMPORTANT FOR OTHER VIEWERS
Do not assume what is said by us as customer  is true.
Do not assume that what is said by us as a customer applies to your situation.
Please listen to cPanels officials for any real advice as this might be a edge case or wrong diagnose.
Until otherwise by cPanel officials stated asume the output of the test script to be valid

-

We just finished a intensive audit due to the alert of CVE-2026-41940
https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026

We suspect a high chance of false positives due to the way the script interacts with sessions created. We had all servers shown with alert of line CRITICAL: Multi-line pass value detected: /var/cpanel/sessions/raw/root: **  and some with 
Found possible injected session file: /var/cpanel/sessions/raw/:***
  - No sign of usage

This even happened on server with only 1 client active and clean logs no other sessions than us all network traffic audited and coming from known locations with all sessions processes killed a full restart and manual reading of the raw files

Please note the report below was formatted with AI; the audit was, however, done by hand.

-

• Software Verification: Confirmed the installation of WP Toolkit 6.10.1-10341, which contains the official security patch. Confirmed the installation of WHM 134.0.20 which contains the official security patch.
  
  
• Session Remediation: Performed a full purge of /var/cpanel/sessions/raw/* and force-restarted the cPanel service (cpsrvd).
• Volatile Memory Clearing: Executed a full system reboot to ensure no malicious processes remained active in the RAM.
• Binary Session Inspection: Manually inspected the flagged session files at a binary level. The presence of \npass= followed by a 64-character hexadecimal string was confirmed.
• IP Attribution & Login Audit: Verified the metadata within the flagged session. The ip_address and origin_as_string parameters were traced back to authorized administrative sources only.
• Persistence & Backdoor Audit:
  • Audited /root/.ssh/authorized_keys for unauthorized entries (Clean).
  • Checked for shared library hijacking via /etc/ld.so.preload (Clean).
  • Monitored active network connections for suspicious external communication (Clean).
  • Verified cPanel package integrity via check_cpanel_pkgs.
• Environment Cross-Testing: Reproduced the "Multi-line pass" indicator on a clean, baseline server setup with only Imunify360 enabled, suggesting a potential conflict between security suites and the IoC detection logic.

• Security Suite Metadata: The pass= variable may be utilized by cPanel or Imunify360 for legitimate internal security tokens or "Hulk" (Brute Force Protection) hashes.
• Formatting Collision: The session handler may use specific line-break formatting (\n) for internal variables that unintentionally mimics the exploit signature.
• Scanner Sensitivity: The IoC detection logic may lack the granularity to distinguish between authorized dynamic security tokens and malicious payloads.

• Lab Reproduction: Verify if authorized logins on a patched system with Imunify360 generate \npass= structures in session files.
• Token Confirmation: Confirm whether the observed 64-character hexadecimal strings are known, legitimate internal security hashes.
• Logic Guidance: Advise on necessary adjustments to IoC detection parameters for environments running advanced security components.

Thank you for your attention.

Best regards,
M.A Draadjer
IT Operational Manager HKBO