Detection Rules — CVE-2026-41940 cPanel Harvester Toolkit — 216.126.227.49

Campaign: OpenDirectory-CVE-2026-41940-cPanel-Harvester-216.126.227.49 Date: 2026-05-17 Author: The Hunters Ledger License: CC BY 4.0 Reference: https://the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/

Detection Coverage Summary

This campaign centers on CVE-2026-41940, a pre-authentication CRLF-injection auth-bypass in cPanel/WHM, weaponized by an unattributed operator running a Python/Bash credential-harvesting and phishing-distribution toolkit from AS14956 RouterHosting infrastructure. Coverage below spans the CVE exploitation mechanic at the network and log layers, the operator’s live C2 dashboard banner, and forensic identification of the toolkit itself.

Detection vs Hunting: Detection rules are high-fidelity and evasion-resilient — safe to alert on. Hunting rules are broader, for scoping and threat-hunting — expect to review the hits.

Highest-confidence anchors:

• The Suricata network signature for the raw Authorization-header control-byte injection matches the actual CVE-2026-41940 exploitation mechanic rather than a proxy for it — well-formed Basic-auth credentials cannot structurally contain a control byte, giving this rule near-zero FP by construction (Suricata Detection).
• The YARA filename-combination rule requires 2-of-7 bespoke, operator-coined component names together — a genuine content signature for forensic/IR identification of the toolkit (YARA Detection).

Atomics routed to the IOC feed: the operator’s Parklogic TDS affiliate account ID pkAId=2143526812 is a rotatable literal — a Sigma rule and a Suricata signature that keyed solely on it are cut and preserved in opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-iocs.json. A third rule targeting the /f/<12-hex> phishing payload-fetch path is also cut — its real precision came entirely from a 13-domain allowlist already BLOCK-listed individually in the feed, with no independent value once the domain scoping is removed. See Coverage Gaps for detail.

Evidence posture note: the operator’s toolkit source code was never persisted to disk, so byte-level YARA content signatures against the toolkit’s internals are not possible — the retained YARA rule is a bespoke-filename identification aid for forensic/IR use, not a content signature. Across the remaining rule types, the Suricata CRLF-injection signature is this campaign’s only Detection-tier rule for the CVE itself (it observes the actual exploitation mechanic); the Sigma log-based rules for the same CVE are Hunting-tier — the structured webserver/proxy logsource fields available to Sigma cannot see the raw Authorization header content, so each Sigma rule matches a broader proxy signal (a URI path, a query parameter, a redirect target) requiring analyst triage rather than automated alerting.

YARA Rules

Detection Rules

CVE-2026-41940 cPanel Harvester Toolkit — Bespoke Component Filenames

Tier: Detection Robustness: 2 ATT&CK Coverage: T1587.001 (Develop Capabilities: Malware), T1588.005 (Obtain Capabilities: Exploits) Confidence: HIGH Rationale: Corrected from the original: the hash-match branch declared each SHA256 value as a strings: literal and matched it as ASCII text content — checking whether the hexadecimal text of the hash appears inside the scanned file, a fundamentally different condition from matching a file whose computed hash equals that value. It could not have fired against the toolkit files it was written to detect and has been removed rather than repaired — a rule whose detection is purely a file hash belongs in the campaign IOC feed, and all eight hashes are already exact-match entries there. The surviving filename-combination branch requires 2 of 7 bespoke, operator-coined names together with a size ceiling, which an operator cannot evade without renaming multiple sibling components across the toolkit. False Positives: None known — all seven strings are bespoke names coined by this operator (e.g. pipeline-41940, whm-hunter, beast-dashboard); requiring 2-of-7 together makes an incidental single-name collision insufficient to fire. Blind Spots: A rebuild that renames every dropped/referenced component evades; the rule matches file content (script self-references, directory listings, orchestrator source) — it does not compute or match file hashes, and misses a fully memory-resident deployment that never touches disk under these names. Validation: Scan the operator’s orchestrator script pipeline-41940.sh (which references sibling toolkit filenames in its own source) or a directory-listing/log capture containing 2+ of the bespoke names — must match; an unrelated file mentioning at most one of these strings incidentally must NOT fire. Deployment: Linux forensic triage, disk-image scanning, incident-response tooling on acquired cPanel/WHM host images, and open-directory/index-page content scanning. Not suitable for real-time victim-endpoint scanning — the toolkit runs on operator-controlled infrastructure, not victim endpoints.

/*
   Yara Rule Set
   Identifier: cPanel Harvester Toolkit — CVE-2026-41940 Operator Files
   Author: The Hunters Ledger
   Source: https://the-hunters-ledger.com/
   License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/
*/

rule TOOLKIT_CpanelHarvester41940_KnownFiles {
   meta:
      description = "Detects the operator-built cPanel/WHM credential-harvester toolkit (CVE-2026-41940 exploitation cluster, 216.126.227.49) via a required combination of two or more bespoke, operator-coined component filenames referenced in the toolkit's own orchestrator source or captured in directory-listing/log content. File-hash matching for the eight highest-value toolkit files is carried in the campaign IOC feed, not this rule"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-detections/"
      date = "2026-05-17"
      hash1 = "4b054892b4a5d7811f57562552d1ea0e8ea5bfbf705ceb71e91126482b650a47"
      family = "cPanel-Harvester-Toolkit-CVE-2026-41940"
      malware_type = "Credential Harvester / Exploitation Toolkit"
      campaign = "OpenDirectory-CVE-2026-41940-cPanel-Harvester-216.126.227.49"
      id = "f0965e55-2c67-5830-bed9-0d228e6cff14"
   strings:
      $fn_pipeline    = "pipeline-41940" ascii wide
      $fn_live_dash   = "live-dashboard-v10" ascii wide
      $fn_whm_hunter  = "whm-hunter" ascii wide
      $fn_beast_dash  = "beast-dashboard" ascii wide
      $fn_beast_page  = "gen-beast-page" ascii wide
      $fn_megahunt    = "megahunt-fast" ascii wide
      $fn_toolkit_dir = "cpanel-toolkit-export" ascii wide
   condition:
      filesize < 50KB and
      2 of ($fn_pipeline, $fn_live_dash, $fn_whm_hunter, $fn_beast_dash,
            $fn_beast_page, $fn_megahunt, $fn_toolkit_dir)
}

Sigma Rules

Hunting Rules

CVE-2026-41940 Proxy-Subdomain Admin Path Access Attempt

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1190 (Exploit Public-Facing Application), T1212 (Exploitation for Credential Access) Confidence: MODERATE Rationale: Anchors on the fixed cPanel/WHM proxy-subdomain admin paths that the CVE targets — a durable, product-level surface, not an operator-rotatable literal. However, the structured webserver logsource fields available here cannot see the raw Authorization header content where the actual null-byte/CRLF injection occurs, so this rule matches any request to the path regardless of payload. Retagged from the original attack.t1556.007/attack.defense-impairment/attack.persistence tags (none of which fit this behavior) to the technique pair actually named in the rule’s own rationale, and demoted from level: high — a bare path hit is not itself confirmed exploitation. False Positives: Legitimate administrator or monitoring traffic to the WHM/cPanel proxy-subdomain admin interface on hosts where the feature is enabled and internet-reachable; authorized security assessment tools (Burp Suite, Nuclei, Metasploit) running assessments against cPanel infrastructure; security researchers probing CVE-2026-41940 in controlled environments. Deployment: Reverse proxy logs (nginx/Apache/HAProxy) in front of cPanel/WHM; WAF alert logs; any HTTP-aware log pipeline ingesting access logs from port 443/2083/2087.

title: CVE-2026-41940 cPanel WHM CRLF Auth Bypass Attempt - Null Byte in Authorization Header
id: 7f3a2c91-e8d4-4b5a-9c1f-3e6d7a2b0f84
status: experimental
description: >-
  Detects reconnaissance or exploitation attempts against the CVE-2026-41940 proxy-subdomain
  admin paths, a CVSS 9.8 pre-authentication CRLF injection vulnerability in cPanel and WHM
  (disclosed 2026-04-28). The operator toolkit file pipeline-41940.sh at 216.126.227.49
  directly encodes this CVE. Raw Authorization header content, where the actual null-byte or
  CRLF injection occurs, is not exposed as a standard webserver logsource field, so this rule
  anchors on the fixed cPanel/WHM proxy-subdomain path markers the exploit chain targets
  instead — it flags any request to these paths for analyst triage, not a confirmed injection.
references:
    - https://the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/
    - https://nvd.nist.gov/vuln/detail/CVE-2026-41940
author: The Hunters Ledger
date: 2026-05-17
tags:
    - attack.initial-access
    - attack.t1190
    - attack.credential-access
    - attack.t1212
    - detection.emerging-threats
logsource:
    category: webserver
detection:
    selection_auth_null:
        cs-uri-stem|contains:
            - '/___proxy_subdomain_whm'
            - '/___proxy_subdomain_cpanel'
    condition: selection_auth_null
falsepositives:
    - >-
      Legitimate administrator or monitoring traffic to the WHM/cPanel proxy-subdomain
      admin interface on hosts where the feature is enabled and internet-reachable
    - Authorized security assessment tools (Burp Suite, Nuclei, Metasploit) running assessments against cPanel infrastructure
    - Security researchers probing CVE-2026-41940 in controlled environments
level: medium

CVE-2026-41940 Expired-Session Token Marker in Query String

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1190 (Exploit Public-Facing Application), T1212 (Exploitation for Credential Access) Confidence: MODERATE Rationale: expired=1 is the PoC-exact token injected into the Authorization header’s credential portion, per public PoC documentation — a vulnerability-mechanic marker, not an operator choice. But the rule can only observe this marker if it surfaces in the URI query string (the raw header itself is not visible to this logsource), and expired=1 is also a generic session-timeout query parameter used by unrelated web applications, so precision is weaker than the original LOW false-positive-risk label claimed. Retagged and demoted from level: medium risk framing to an explicit Hunting posture (level unchanged at medium, which was already appropriately humble). False Positives: Unrelated web applications using expired=1 as a generic session-timeout query parameter; authorized security scanning tools probing cPanel installations. Deployment: Reverse proxy logs; WAF alert logs; cPanel access logs (ports 2083, 2087, 443).

title: CVE-2026-41940 cPanel WHM CRLF Auth Bypass - Expired Session Token in Authorization Header
id: a4c8e17b-3f92-4d6e-b08a-5c2d9e4f1a73
status: experimental
description: >-
  Detects the string 'expired=1' in a request URI query string directed at a cPanel/WHM host,
  the CVE-2026-41940 PoC-exact token normally injected into the Authorization: Basic header
  credential portion to trigger the CRLF auth bypass (matching the canonical public PoC and
  the operator toolkit at 216.126.227.49). Raw Authorization header content is not exposed as
  a standard webserver logsource field, so this rule instead matches the same marker if it
  surfaces in the URI query string, which some reverse proxies log alongside the header
  injection attempt; 'expired=1' is also a generic session-timeout query parameter used by
  unrelated web applications, so treat matches as a triage lead rather than a confirmed hit.
references:
    - https://the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/
    - https://nvd.nist.gov/vuln/detail/CVE-2026-41940
author: The Hunters Ledger
date: 2026-05-17
tags:
    - attack.initial-access
    - attack.t1190
    - attack.credential-access
    - attack.t1212
    - detection.emerging-threats
logsource:
    category: webserver
detection:
    selection_expired_token:
        cs-uri-query|contains: 'expired=1'
    condition: selection_expired_token
falsepositives:
    - Unrelated web applications using 'expired=1' as a generic session-timeout query parameter
    - Authorized security scanning tools probing cPanel installations
level: medium

CVE-2026-41940 Successful Auth-Bypass Response Confirmation

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1190 (Exploit Public-Facing Application), T1212 (Exploitation for Credential Access) Confidence: LOW Rationale: Narrows the proxy-subdomain path hit to successful (HTTP 200) responses only, which is a real refinement over the bare path-access rule above, but it still cannot isolate the actual server-side confirmation string (msg_code:[expired_session]) without response-body visibility. The original rule already self-assessed level: low for this reason — that humility is preserved, and the rule is now explicitly filed as Hunting rather than an unlabeled standalone signal. False Positives: Any successful request to the proxy-subdomain path markers — this rule cannot isolate the response-body confirmation string without response-body visibility; treat matches as candidates for manual or WAF-layer confirmation, not standalone high-confidence alerts. Deployment: Inline HTTP proxies or WAFs with response-body inspection enabled; NGFW with application-layer DPI; cPanel/WHM error log aggregation.

title: CVE-2026-41940 cPanel WHM CRLF Auth Bypass - Successful Exploitation Confirmation Response
id: 2e8b5d9f-71a3-4c8e-a25b-6f0d3c7e9b12
status: experimental
description: >-
  Detects HTTP 200 responses to the CVE-2026-41940 proxy-subdomain admin path markers, used
  as a coarse proxy for the server-side confirmation string 'msg_code:[expired_session]' that
  cPanel/WHM returns in the response body after a successful CRLF auth bypass. Standard
  webserver logsource fields do not expose raw response-body content, so the exact
  confirmation string cannot be matched here — deploy a response-body string match at the
  application or WAF layer for high-confidence exploitation confirmation, and use this rule
  only to narrow the candidate set for that manual or WAF-layer review.
references:
    - https://the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/
    - https://nvd.nist.gov/vuln/detail/CVE-2026-41940
author: The Hunters Ledger
date: 2026-05-17
tags:
    - attack.initial-access
    - attack.t1190
    - attack.credential-access
    - attack.t1212
    - detection.emerging-threats
logsource:
    category: webserver
detection:
    selection_auth_bypass_path:
        cs-uri-stem|contains:
            - '/___proxy_subdomain_whm'
            - '/___proxy_subdomain_cpanel'
    selection_success_status:
        sc-status: 200
    condition: selection_auth_bypass_path and selection_success_status
falsepositives:
    - >-
      Any successful request to the proxy-subdomain path markers — this rule cannot isolate
      the response-body confirmation string without response-body visibility; treat matches
      as candidates for manual or WAF-layer confirmation, not standalone high-confidence alerts
level: low

Operator Flask C2 Dashboard /login-2fa Redirect Path

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1071.001 (Web Protocols) Confidence: MODERATE Rationale: The operator’s C2 dashboard presents a distinctive Werkzeug/3.1.8 banner with a 302 redirect to /login-2fa, but proxy logsource fields expose the client-request path, not response headers — so this rule matches any client request containing /login-2fa, without host scoping. That is intentional: the rule is designed for peer-C2 discovery across a monitored proxy segment (finding other hosts using the same operator deployment template), not as a host-specific alert, which is why it stays Hunting rather than Detection. False Positives: Legitimate Flask developers running a login route named /login-2fa on a monitored proxy segment (uncommon; verify destination host against confirmed operator infrastructure); security researchers replicating the operator’s C2 in a lab environment. Deployment: Network proxy logs; NDR/IDS HTTP header capture; Shodan/Censys continuous monitoring export; threat hunting across web access logs for internet-reachable services.

title: Operator Flask C2 Dashboard - Werkzeug 3.1.8 Banner with /login-2fa Redirect
id: 5c7d1e4a-9b83-4f2c-8e67-1a3f5c8d2b90
status: experimental
description: >-
  Detects requests to the /login-2fa path, the redirect target of the Flask C2 dashboard
  operated by the CVE-2026-41940 cPanel harvester cluster (216.126.227.49). The server
  presents HTTP Server: Werkzeug/3.1.8 Python/3.13.12 with a 302 redirect to /login-2fa on
  the initial unauthenticated request; the Werkzeug development server on an internet-facing
  port combined with this custom path fingerprints the operator's deployment pattern.
  Standard proxy logsource fields do not expose response headers (Server banner, Location
  redirect target), so this rule matches the client-request path itself, without host
  scoping — it is intended for peer-C2 discovery across a monitored proxy segment, not as a
  host-specific alert; retain the Shodan/Censys Werkzeug-banner pivot as a complementary
  out-of-band OSINT hunting technique.
references:
    - https://the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/
author: The Hunters Ledger
date: 2026-05-17
tags:
    - attack.command-and-control
    - attack.t1071.001
    - detection.emerging-threats
logsource:
    category: proxy
detection:
    selection_login2fa_path:
        c-uri|contains: '/login-2fa'
    condition: selection_login2fa_path
falsepositives:
    - >-
      Legitimate Flask developers running a login route named /login-2fa on a monitored
      proxy segment (uncommon; verify destination host against confirmed operator infrastructure)
    - Security researchers replicating the operator's C2 in a lab environment
level: medium

Operator Parklogic TDS Landing URL Shape

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1583.008 (Acquire Infrastructure: Malvertising) Confidence: HIGH Rationale: Requires three simultaneous conditions — the exact operator account ID, presence of an &s= campaign-hash parameter, and a 64-hex-character value for that parameter — which is meaningfully more specific than a bare account-ID match. The account ID is still the sole discriminator that ties this shape to this operator rather than any other Parklogic customer (removing it leaves a generic Parklogic platform URL shape), so durability caps below Detection, but the three-part combination has real triage value. Retagged from attack.t1608.005 to attack.t1583.008, matching the malware-analyst’s own campaign-wide MITRE mapping for this Parklogic TDS layer. False Positives: Other Parklogic customers using the same platform with different a= values (filtered by the a=2143526812 requirement); security researchers reproducing the operator’s TDS chain in testing environments. Deployment: Web proxy URL logs; email gateway URL pattern scanning.

title: Operator TDS Landing URL Pattern - Parklogic Source-Referer Shape with Campaign Hash
id: 3d6c9a7e-2f41-4b8d-c53e-9a1b7f3e5d28
status: experimental
description: >-
  Detects the URL pattern used by the CVE-2026-41940 cPanel harvester operator's Parklogic
  TDS traffic distribution system. The shape is /?d=<source-domain>&a=2143526812&s=<64-hex>
  where d= is the source/referrer domain, a= is the operator's Parklogic affiliate account
  ID (constant: 2143526812), and s= is a per-source-domain campaign hash (64 hex characters).
  This shape routes victims from compromised or spoof landing pages through to phishing
  destinations. The account ID is the sole discriminator that ties this shape to this specific
  operator rather than any other Parklogic customer; without it the /?d=&s=<64-hex> shape
  alone is generic Parklogic platform traffic.
references:
    - https://the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/
author: The Hunters Ledger
date: 2026-05-17
tags:
    - attack.resource-development
    - attack.t1583.008
    - detection.emerging-threats
logsource:
    category: proxy
detection:
    selection_tds_shape:
        c-uri-query|contains|all:
            - 'a=2143526812'
            - '&s='
    selection_s_param_length:
        c-uri-query|re: '[?&]s=[a-f0-9]{64}(&|$)'
    condition: selection_tds_shape and selection_s_param_length
falsepositives:
    - Other Parklogic customers using the same platform with different a= values (filtered by the a=2143526812 requirement)
    - Security researchers reproducing the operator's TDS chain in testing environments
level: medium

Post-Exploitation SSH Authorized_Keys Modification on cPanel Host

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1098.004 (Account Manipulation: SSH Authorized Keys — dual-tactic: Persistence and Privilege Escalation) Confidence: MODERATE Rationale: SSH authorized_keys modification is a durable, well-known Linux persistence primitive — not specific to this operator, and not directly observed in the recovered toolkit source (inferred from standard post-WHM-root tradecraft, per the original rule’s own MODERATE confidence label). Demoted from level: high: legitimate administration and automation tooling (Ansible, Puppet, Chef, ssh-copy-id, CI/CD key rotation) produce the identical event, so this needs analyst correlation with a prior CVE-2026-41940 exploitation attempt on the same host rather than standing alone. False Positives: Legitimate administrator key management via ssh-copy-id or direct authorized_keys editing (use change-management correlation to exclude); automated configuration management tools (Ansible, Puppet, Chef) managing SSH keys; CI/CD pipeline deployment keys being rotated. Deployment: Linux file integrity monitoring (AIDE, Auditd, Wazuh); EDR file-event logs on cPanel/WHM hosts; Sigma-compatible SIEM with file event indexing.

title: Post-CVE-2026-41940 Exploitation - Unauthorized SSH Authorized Keys Modification on cPanel Host
id: 6a4f8e2b-1c95-4d7a-f38d-2e9b0c6a5f17
status: experimental
description: >-
  Detects modifications to SSH authorized_keys files on Linux cPanel/WHM hosts, documented
  post-exploitation persistence tradecraft following a CVE-2026-41940 CRLF auth bypass. This
  is a generic Linux persistence primitive inferred from standard post-WHM-root tradecraft,
  not directly observed in the operator's recovered toolkit source, and is most actionable
  when correlated with a prior CVE-2026-41940 exploitation attempt in web access logs for
  the same host.
references:
    - https://the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/
    - https://nvd.nist.gov/vuln/detail/CVE-2026-41940
author: The Hunters Ledger
date: 2026-05-17
tags:
    - attack.persistence
    - attack.privilege-escalation
    - attack.t1098.004
    - detection.emerging-threats
logsource:
    category: file_event
    product: linux
detection:
    selection_ssh_keys:
        TargetFilename|endswith: '/.ssh/authorized_keys'
    filter_admin_tools:
        Image|contains:
            - '/usr/sbin/sshd'
            - '/usr/bin/ssh-copy-id'
    condition: selection_ssh_keys and not filter_admin_tools
falsepositives:
    - >-
      Legitimate administrator key management via ssh-copy-id or direct authorized_keys
      editing (use change-management correlation to exclude)
    - Automated configuration management tools (Ansible, Puppet, Chef) managing SSH keys
    - CI/CD pipeline deployment keys being rotated
level: medium

Post-Exploitation New cPanel Account Creation

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1136.001 (Create Account: Local Account) Confidence: MODERATE Rationale: New-cPanel-account creation outside an admin session is a durable persistence/monetization primitive, but the toolkit link is speculative: gen-cpanel-access.py (6,070 bytes) is inferred, not confirmed, to generate these artifacts — its source was never recovered. Demoted from level: high and retagged with the sub-technique the malware-analyst’s own campaign mapping uses (T1136.001, not the parent T1136); legitimate reseller account provisioning produces the identical event, so this is a triage lead requiring correlation with signup records, not a standalone indicator. False Positives: Legitimate new customer account creation by authorized resellers (correlate against reseller activity logs and customer signup records); automated cPanel processes creating internal system accounts; routine cPanel upgrades creating new system user files. Deployment: Linux file integrity monitoring; Auditd on /var/cpanel/users/; Wazuh rules watching /var/cpanel/ directory tree.

title: Post-CVE-2026-41940 Exploitation - New cPanel Account Created Outside Admin Session
id: 1b7e3f8a-5c4d-4e9b-a17c-8f2b6e4d0c39
status: experimental
description: >-
  Detects creation of new cPanel/WHM user account files in /var/cpanel/users/, documented
  post-exploitation persistence and monetization tradecraft following a CVE-2026-41940 CRLF
  auth bypass. The operator toolkit at 216.126.227.49 includes gen-cpanel-access.py (6070
  bytes, hash unavailable) which is inferred — not directly observed — to generate cPanel
  access artifacts post-compromise; treat matches as a triage lead requiring correlation with
  reseller/customer signup records, not a standalone high-confidence indicator.
references:
    - https://the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/
    - https://nvd.nist.gov/vuln/detail/CVE-2026-41940
author: The Hunters Ledger
date: 2026-05-17
tags:
    - attack.persistence
    - attack.t1136.001
    - detection.emerging-threats
logsource:
    category: file_event
    product: linux
detection:
    selection_cpanel_user_create:
        TargetFilename|startswith: '/var/cpanel/users/'
    filter_whm_admin:
        Image|contains:
            - '/usr/local/cpanel/'
            - '/usr/local/whm/'
    condition: selection_cpanel_user_create and not filter_whm_admin
falsepositives:
    - >-
      Legitimate new customer account creation by authorized resellers (correlate against
      reseller activity logs and customer signup records)
    - Automated cPanel processes creating internal system accounts
    - Routine cPanel upgrades creating new system user files
level: medium

Suricata Signatures

Detection Rules

CVE-2026-41940 Raw CRLF/Null-Byte Injection in Authorization Header

Tier: Detection Robustness: 3 ATT&CK Coverage: T1212 (Exploitation for Credential Access), T1190 (Exploit Public-Facing Application) Confidence: HIGH Rationale: Unlike the Sigma rules for this same CVE, which can only see structured webserver logsource fields, Suricata inspects the raw Authorization header bytes at the network layer — this rule matches the actual exploitation mechanic (a null byte, CR, or LF injected after the Base64-encoded credential portion) rather than a proxy signal for it. Well-formed Basic-auth credentials are structurally restricted to the base64 alphabet, so any control byte in that position is anomalous by construction; this is the campaign’s highest-fidelity CVE-2026-41940 detection. Added a metadata: attribution field (missing from the original, which carried only legacy reference: keywords) per Suricata authoring standards. False Positives: Authorized penetration-test tooling (Burp Suite, Nuclei, Metasploit) replaying the public PoC against a cPanel/WHM host under an approved assessment. Blind Spots: Requires application-layer HTTP visibility (an inline sensor or TAP in front of the cPanel/WHM host) — does not fire when the vulnerable server sits behind a TLS-terminating CDN that reconstructs the Authorization header before forwarding (see Coverage Gaps); misses exploitation variants that encode the injected byte differently than the null/CR/LF set covered here. Validation: Replay the public CVE-2026-41940 PoC’s crafted Authorization header against a lab cPanel/WHM instance — must alert; a well-formed Basic-auth login attempt must NOT fire. Deployment: Inline IDS/IPS with HTTP application-layer parsing in front of cPanel/WHM infrastructure; network TAP on cPanel hosting provider perimeter. The rule header uses http (application-layer keyword) with any destination port — catches exploitation on standard ports 2083/2087 and non-standard port migrations without requiring a port list.

alert http any any -> any any (msg:"THL CVE-2026-41940 cPanel WHM CRLF Auth Bypass Attempt - Control Char in Authorization Basic"; flow:established,to_server; content:"Authorization|3a 20|Basic "; http_header; pcre:"/Authorization:\s*Basic\s+[A-Za-z0-9+\/=]*(?:\x00|\x0a|\x0d|%00|%0a|%0d|%0A|%0D)/Hi"; reference:cve,2026-41940; reference:url,the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/; classtype:web-application-attack; sid:9100101; rev:2; metadata:author The_Hunters_Ledger, date 2026-05-17, reference https://the-hunters-ledger.com/hunting-detections/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-detections/;)

Hunting Rules

Operator Flask C2 Dashboard Banner Hunt — Werkzeug/3.1.8 + /login-2fa

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1071.001 (Web Protocols) Confidence: HIGH for the banner match today; durability is limited (see Rationale) Rationale: The exact Werkzeug/Python version-pinned banner combined with the operator’s custom /login-2fa redirect path is highly precise today, but both halves are brittle to routine operational change rather than deliberate evasion — a Werkzeug upgrade, a restart behind gunicorn/nginx, or fronting the dashboard with a reverse proxy would each independently break this signature without the operator doing anything adversarial. Durability governs the tier call over current precision (see Coverage Gaps for the version-decay note and the Shodan/Censys hunting supplement). Added a metadata: attribution field per Suricata authoring standards. False Positives: The combination of this exact Werkzeug version, Python version suffix, and /login-2fa redirect path is unlikely in unrelated legitimate deployments, but any hit should be corroborated against the operator’s known infrastructure before treating it as a confirmed peer-C2 discovery. Deployment: Internet-facing NDR; Zeek http.log streaming to SIEM; Suricata on monitored egress/ingress points; periodic Shodan/Censys banner-match correlation for peer-infrastructure discovery.

alert http any any -> any any (msg:"THL CVE-2026-41940 Operator Flask C2 Dashboard - Werkzeug/3.1.8 Banner with /login-2fa Redirect"; flow:established,to_client; http.server; content:"Werkzeug/3.1.8 Python/3.13.12"; endswith; nocase; http.header; content:"Location|3a 20|/login-2fa"; nocase; reference:url,the-hunters-ledger.com/reports/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517/; classtype:trojan-activity; sid:9100102; rev:2; metadata:author The_Hunters_Ledger, date 2026-05-17, reference https://the-hunters-ledger.com/hunting-detections/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-detections/;)

Coverage Gaps

Atomics routed to the IOC feed. Two rules in the original file (a Sigma rule and a Suricata signature, both titled “Operator Parklogic TDS … Affiliate ID”) keyed solely on the operator’s Parklogic TDS account ID pkAId=2143526812 — removing that single hardcoded literal leaves no behavioral signal in either rule, so both are cut as standalone rules. The account ID is preserved in opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-iocs.json (behavioral_indicators.url_patterns), alongside the related a=2143526812 TDS URL-shape pattern retained as the Hunting-tier “Operator Parklogic TDS Landing URL Shape” Sigma rule above. A third rule (“Operator Phishing Kit Payload-Fetch URL — /f/[12-hex] Path Pattern”) is also cut: its real precision came entirely from a 13-domain allowlist, all of which are already individually BLOCK-listed in the feed’s network_indicators.domains, and the one specific observed URL (https://officebyt.e56sutx.eps-soltec.cloud/f/d6aba322369c) is already present verbatim in network_indicators.urls. The bare /f/<12-hex> path shape has no independent detection value once the domain scoping is removed — it also appears on unrelated CDN and file-download-handler paths generally.

YARA hash-match branch was non-functional — fixed by removal, not repair. The original YARA rule’s hash-match branch declared each SHA256 value as a strings: literal (e.g. $hash_pipeline = "4b0548...b47") and matched it as ASCII text content — that checks whether the hexadecimal text of the hash appears inside the scanned file’s content, a fundamentally different (and essentially never-true) condition from matching a file whose computed hash equals that value. The branch could not have fired against the toolkit files it was written to detect. Rather than repair it with hash.sha256(0, filesize) == "...", the branch was removed outright: per YARA authoring standards, a rule whose detection is purely a file hash belongs in the campaign IOC feed, not a YARA condition — and all eight hashes are already present there as exact-match entries. The surviving rule keeps its filename-combination branch, which is a genuine content signature and is unchanged.

Sigma log-based CVE-2026-41940 rules retiered to Hunting. All three Sigma rules for the CVE (proxy-subdomain path access, expired-session token marker, and successful-response confirmation) were originally published with a False Positive Risk label of LOW and levels ranging medium-to-high — but the structured webserver logsource fields available to Sigma cannot see the raw Authorization header content where the actual null-byte/CRLF injection occurs. Each rule instead matches a broader proxy signal (a fixed cPanel/WHM admin path, a generic-sounding query parameter, a 200-status response to that path) that legitimate administrator traffic, authorized security scanners, or unrelated web applications can also produce. The Suricata signature above, which inspects the raw header bytes directly, remains this campaign’s only Detection-tier rule for the CVE itself.

YARA String-Pattern Detection Against Toolkit Content — NOT POSSIBLE (Source Code Unrecoverable)

Gap: String-based and byte-pattern YARA rules against the operator’s 37-file Python/Bash toolkit’s actual content are impossible for this campaign. The operator’s development HTTP server was active during the open directory crawl but went offline before source code could be persisted — hashes were computed in memory only, with no source code ever written to disk. There is no byte content to pattern-match against.

What would enable rule creation: Recovery of any toolkit file from an incident-response engagement (disk image acquisition from a compromised cPanel/WHM host, network-capture of an operator file-transfer, or a second operator open-directory exposure with persistence) would enable immediate string-based YARA. The hashes exist and are carried as exact-match entries in the IOC feed; content-based rules require the source.

Workaround in this file: The retained YARA rule TOOLKIT_CpanelHarvester41940_KnownFiles matches 2-of-7 distinctive operator filename strings — a forensic supplement for identifying the toolkit via self-references or directory-listing content, not a substitute for content-level signatures against the toolkit’s actual code.

YARA for HTA Payloads on 216.126.224.181 — Not Authored (Low-MODERATE Operator Attribution)

Gap: Five commodity-malware hashes from the .181 IP (Urcbadur/Alien InfoStealer via CVE-2017-0199; ADKP HTA dropper) were recovered from VirusTotal. These have significant detection coverage (8–34 of 76 engines). YARA rules are not authored here for two reasons:

1. The .181 April 2026 activity is LOW-MODERATE operator attribution — the most parsimonious explanation is a different RouterHosting tenant after the primary operator vacated the IP.
2. The commodity families already have AV signatures with wide coverage; authoring new rules for them provides minimal incremental detection value.

What would enable rule creation: Evidence confirming the same operator controlled .181 during the April 2026 commodity-malware activity (e.g., WHOIS/infrastructure overlap with the operator’s confirmed org-ID locks, or the same machine-id 6e3644a97f844763a34565b865d35310 appearing in a .181 artifact) would justify authoring operator-attribution YARA for these samples.

cPanel/WHM Audit Log Sigma — Platform-Specific, Not Authored

Gap: Several high-value detection patterns target cPanel-native audit logs (/var/cpanel/accounting.log, /var/cpanel/users/ creation events, email-forwarding rule changes). These require a product: cpanel Sigma logsource category that is not a standard SigmaHQ-supported category. Platform-specific Sigma rules cannot be submitted to the SigmaHQ upstream repository without custom logsource backend support.

Rules that would be valuable:

• New email-forwarding rule created on a cPanel-hosted mailbox (T1114.003 — Email Forwarding Rule)
• /var/cpanel/accounting.log showing account creation outside logged administrator session (T1136.001)
• New .php or .cgi file in ~/public_html/ outside normal deploy window (T1505.003)

What would enable rule creation: Addition of a cpanel product backend to SigmaHQ (or deployment in a SIEM with a custom log-source mapping for cPanel audit logs).

Suricata for CVE-2026-41940 on Cloudflare-Fronted cPanel (TLS Inspection Gap)

Gap: The operator’s newer phishing domains (eps-soltec.cloud, tesaco.sbs) route through Cloudflare. A network-layer Suricata rule for CVE-2026-41940 exploitation attempts will not fire when the attacker targets a Cloudflare-fronted cPanel endpoint — the TLS terminates at Cloudflare, and the upstream authorization header is re-constructed by Cloudflare before forwarding to the origin cPanel server. Only rules deployed at the cPanel origin server (not the perimeter IDS) will see the raw header content.

Mitigation path: Deploy Suricata (or equivalent) as a local listener on the cPanel/WHM server itself, or use cPanel’s built-in ModSecurity WAF with the relevant OWASP/CVE rule set.

Werkzeug C2 Banner — Version-Specific Decay

Gap: The Suricata rule THL CVE-2026-41940 Operator Flask C2 Dashboard - Werkzeug/3.1.8 Banner (Hunting-tier, see above) will stop matching if the operator updates Werkzeug (e.g., to 3.1.9 or 3.2.x) or promotes the dashboard behind nginx/gunicorn (which would suppress the Werkzeug Server header entirely). The /login-2fa redirect path is more durable but could be renamed in a toolkit update. This decay risk is the reason the rule is tiered Hunting rather than Detection despite its near-zero false-positive rate today.

Hunting supplement: Run a periodic Shodan/Censys query for http.server:"Werkzeug" combined with a 302 redirect to any path containing login-2fa — this gives version-agnostic peer-C2 discovery beyond what the rule catches in live traffic.

beast-notify.py Notification Channel — Unknown

Gap: The operator’s beast-notify.py (3,960 bytes, SHA256 32b9b9a82913dae5e40842f68791cc639fe690603ccc1d85fe1ae2e99b7bf26b) dispatches per-compromise notifications to an operator-controlled channel. The channel type is unknown (Telegram, Discord webhook, email, or custom HTTPS endpoint). Without source code, no network-layer Suricata rule can be written for the notification channel.

What would enable rule creation: Source recovery of beast-notify.py from an IR engagement would reveal the notification endpoint URL, bot token prefix (if Telegram), or webhook URL format (if Discord) — enabling a targeted Suricata rule for the exfiltration/notification channel.

Operator Scanning Behavior — Linux-Side Process Detection Not Covered

Gap: The operator runs mass_v[4-8].py, masscan-boost.sh, and similar scanning tools from their own Linux box. No Sigma rules are authored for victim-side or defender-side detection of these scanning tools because:

1. The scans originate from operator-controlled infrastructure (AS14956 RouterHosting), not from compromised victim hosts.
2. Defender visibility into the operator’s own process execution requires access to the operator’s system, which is not a normal defender vantage point.

What would enable rule creation: Network-based detection of the scanning behavior is already partially covered by the Suricata C2 and TDS rules. Full coverage would require the operator’s process creation logs — available only via law enforcement or a honeypot that entices the operator to execute on a monitored system.

License

Detection rules are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).
Free to use, including commercially, with attribution to The Hunters Ledger.