GitHub Actions Abuse Powers Distributed cPanel & WHM Exploitation

A threat actor gained push access to a legitimate PHP/DevOps maintainer's GitHub repositories and committed hundreds of malicious GitHub Actions workflow files into .github/workflows/. Between 2026-07-12 and 2026-07-13 Packagist auto-synchronised the poisoned development versions across all ten of that maintainer's packages: 583 malicious workflow files in total, 55 to 62 per package version. The PHP library code itself was never malicious. The execution layer is GitHub Actions.

Each workflow runs on push to any branch or on manual dispatch, spins up an ephemeral GitHub-hosted Ubuntu runner with a 350-minute timeout, detects the runner CPU architecture, downloads a matching Linux ELF payload from the actor-controlled host 43.228.157.68, writes it to /tmp/.svc, chmods it to 755 and launches it as an internet scanner. The scanner sweeps ports 80, 443, 8080, 8443 and the cPanel/WHM control-plane ports 2082, 2083, 2086 and 2087, attempts exploitation of CVE-2026-41940 (unauthenticated authentication bypass in the cPanel & WHM login flow, CVSS 3.1 base 9.8, CISA KEV since 2026-04-30, flagged for known ransomware use), and then harvests server-side secrets: AWS keys, GitHub and GitLab tokens, OpenAI and Google API credentials, Stripe keys, SendGrid and Mailgun credentials, database logins, SSH material, git remotes, environment files and configuration files.

Results leave in chunked HTTP POSTs to /api/github-results with a heartbeat to /api/github-heartbeat every 30 seconds. Fourteen recovered workflows also fired an nslookup at a unique DNSHook callback hostname, and a GitHub code search for that identifier returned roughly 6,100 matching workflow files across unrelated repositories, with broader searches on the C2 address, scanner arguments and exfiltration endpoints returning about 15,000 to 16,000 files. Those are file counts, not confirmed victims, but the reuse confirms the campaign is far larger than one maintainer.

The defensive problem splits cleanly in two. Victim side: any internet-facing cPanel or WHM server running an unpatched build is being sprayed by an unknown number of GitHub-hosted runners with clean, reputable source IPs that no threat-intel feed will block. Attacker-infrastructure side: any repository your organisation owns, and any self-hosted runner or developer workstation that executes a poisoned workflow, becomes part of the scanning fleet and leaks whatever secrets that pipeline can reach.

Defender priority: patch cPanel/WHM to the fixed build for your release tier first (the KEV due date was 2026-05-03 and is long past), then run Q9 and Q10 against every hosting server for post-exploitation evidence, and in parallel search your own GitHub org for workflow files referencing the C2 address, the DNSHook hostname, or the ipscan --exploit argument set. Source-IP blocking is not a control here: the scanning traffic originates from GitHub's own runner ranges.

Web-hunter decisions

• Every source in this pack was fetched, read and saved verbatim to GitHubActions-cPanel-CVE-2026-41940-Hunt-sources/ (7 snapshots). Every atomic indicator below traces back to at least one of them.
• No injected instructions were found. All seven snapshots were scanned for text attempting to direct the research agent (fetch-this-instead, ignore-prior, claimed authorisation). Nothing matched. One source carries unrelated promotional interstitials, which is marketing noise, not an instruction, and is not disqualifying.
• The compromised maintainer is a victim, not the actor. Socket states this explicitly. The maintainer handle and the ten package names are therefore listed as exposure-audit strings for dependency review, never as detect-or-block indicators, and the account has been suspended.
• Package counts are not victim counts. The ~6,100 and ~15,000–16,000 figures are matching files in GitHub code search. Some hits are duplicate copies in one repo and some may be actor-controlled staging. This pack does not treat them as a victim population.
• Exploit mechanics are summarised, not reproduced. The watchTowr writeup contains a working exploitation walkthrough and links to a public PoC. Only the defensive residue (session-file artefacts, service names, log locations) is carried into this pack; the PoC is not linked.

Attack chain

Hunt hypotheses (ordered by fidelity)

Perishability: the C2 host and the DNSHook hostname are the only truly atomic indicators, and both are rotatable in minutes. The durable coverage in this pack is behavioural: Q4 (dot-prefixed /tmp ELF), Q5 (scanner argv), Q8 (panel-port fan-out) and Q9 (cpsrvd child process) all keep working after the actor moves infrastructure. Deploy those as the standing detections and treat the IP, URL and hash rows as a 90-day sweep.

The most important part of this campaign happened on GitHub-hosted compute where no EDR sensor can exist. These checks are not optional extras: for step 3 of the attack chain they are the only coverage.

N1 · GitHub Actions run-history review (org-wide)

• List every workflow run in the last 90 days with an unusually long duration. The campaign's workflows set timeout-minutes: 350, so a scanning job looks like a job that never finishes.
• Flag any workflow triggered on push to branches: ['**'] combined with workflow_dispatch, particularly in repositories with no history of CI.
• Flag repositories with an anomalous count of workflow files. Legitimate projects rarely carry 55 to 62 of them.

# GitHub CLI - inventory workflow files and long-running runs across the org
gh repo list YOUR_ORG --limit 1000 --json nameWithOwner --jq '.[].nameWithOwner' | while read -r R; do
  N=$(gh api "repos/$R/actions/workflows" --jq '.total_count' 2>/dev/null)
  [ -n "$N" ] && [ "$N" -gt 10 ] && echo "REVIEW  $R  workflows=$N"
done

# Runs that ran longer than an hour in the last 90 days
gh api "repos/YOUR_ORG/YOUR_REPO/actions/runs?per_page=100" \
  --jq '.workflow_runs[] | select(.conclusion != null)
        | {name, created_at, updated_at, event, actor:.actor.login, url:.html_url}'

N2 · GitHub code search across your own org

Search your organisation's repositories for the campaign's own markers. This is the same pivot the researchers used, pointed inward.

# Search YOUR org only. Each of these is a campaign marker, not a generic string.
gh search code --owner YOUR_ORG "43.228.157.68"
gh search code --owner YOUR_ORG "dnshook.site"
gh search code --owner YOUR_ORG "api/github-heartbeat"
gh search code --owner YOUR_ORG "api/github-results"
gh search code --owner YOUR_ORG "ipscan --exploit"
gh search code --owner YOUR_ORG "GOMEMLIMIT" --filename "*.yml"

# Local equivalent across every cloned repo on a build host
grep -rIl --include='*.yml' --include='*.yaml' \
  -e '43.228.157.68' -e 'dnshook' -e 'github-heartbeat' -e 'github-results' -e 'ipscan' \
  /path/to/repos/*/.github/workflows/ 2>/dev/null

N3 · cPanel / WHM login log review (victim side)

• Review /usr/local/cpanel/logs/login_log for bursts of failed logins immediately followed by an apparently successful session from the same source. The bypass mints a pre-auth session by failing a login first, so a failure that is promptly followed by authenticated API activity from the same IP is the shape to look for.
• Review /usr/local/cpanel/logs/access_log for requests carrying a cpsess token that has no matching successful authentication event.
• Correlate against WHM's own Manage External Authentications and active-session list for sessions you cannot account for.

N4 · cPanel session-file artefact sweep (victim side)

The vulnerability writes attacker-controlled records into the on-disk session store. Two directories hold the evidence: /var/cpanel/sessions/raw/ (line-oriented key=value) and /var/cpanel/sessions/cache/ (JSON). A raw session file whose pass= record is followed by additional top-level records such as hasroot, tfa_verified or successful_internal_auth_with_timestamp is a forged session.

# Read-only triage. Run as root on a suspect cPanel/WHM host.
# Session files containing privilege records injected after the pass= line.
for F in /var/cpanel/sessions/raw/*; do
  awk '/^pass=/{seen=1;next} seen && /^(hasroot|tfa_verified|successful_internal_auth_with_timestamp)=/{print FILENAME": "$0}' "$F"
done

# Preserve before you clean. Hash and copy, do not edit in place.
tar -czf /root/cpanel-session-evidence-$(date +%F).tar.gz \
    /var/cpanel/sessions/raw /var/cpanel/sessions/cache \
    /usr/local/cpanel/logs/login_log /usr/local/cpanel/logs/access_log

# Confirm the installed build against the fixed versions in section 12.
/usr/local/cpanel/cpanel -V

cPanel also publishes an IOC detection script for servers that were exposed while unpatched. Run the vendor's current script from the official support article before declaring a host clean.

N5 · Composer / Packagist dependency exposure audit

Installing an affected package does not execute the workflows: Composer places them in vendor/ where GitHub ignores nested workflow files. But a contaminated artefact in your lockfile is still an artefact you need to replace, and it means your dependency review missed a compromised maintainer.

# Any of the ten affected packages present in a lockfile
grep -rIl --include='composer.lock' -e 'dinushchathurya/' /path/to/projects/ 2>/dev/null

# Any dependency pinned to a branch-based dev version rather than a stable release
grep -rIn --include='composer.json' -e '"dev-' -e '@dev' /path/to/projects/ 2>/dev/null

# Nested workflow files inside vendor/ - contamination marker, not execution
find /path/to/projects -path '*/vendor/*/.github/workflows/*' -name '*.yml' 2>/dev/null

No query below carries an in-query time filter. Set the lookback with the console's time picker; each card records the intended window as a // LOOKBACK: comment. Start at 90 days for the atomic sweeps (Q1–Q3) and 7 days for the behavioural detections.

// HUNT: Outbound connection to GitHub-Actions-abuse campaign C2
// MITRE: T1105 | CONF: high  FP: low  COST: low
// REQUIRES: NetworkConnectIP4 (Linux, Windows, macOS)
// LOOKBACK: 90d (set in the console time picker)
// FALSE POSITIVES: none credible - dedicated actor-controlled host
#event_simpleName=NetworkConnectIP4
| RemoteAddressIP4="43.228.157.68"
| table([@timestamp, aid, ComputerName, UserName, ContextBaseFileName, LocalAddressIP4, RemoteAddressIP4, RemotePort])
| sort(@timestamp, order=desc)

// HUNT: DNSHook callback resolution (campaign execution confirmation)
// MITRE: T1071.004 | CONF: high  FP: low  COST: low
// REQUIRES: DnsRequest
// LOOKBACK: 90d (set in the console time picker)
// FALSE POSITIVES: security researchers detonating the sample; a passive-DNS
//   appliance replaying queries. Both are identifiable by the requesting host.
#event_simpleName=/^(DnsRequest|SuspiciousDnsRequest)$/
| DomainName=/dnshook\.site$/i
| table([@timestamp, aid, ComputerName, UserName, DomainName, ContextBaseFileName, ContextProcessId_decimal])
| sort(@timestamp, order=desc)

// HUNT: Campaign scanner payload by SHA-256 (amd64 build)
// MITRE: T1105 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2 / ELFFileWritten
// LOOKBACK: 90d (set in the console time picker)
// FALSE POSITIVES: none - exact hash match
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2|ELFFileWritten)$/
| SHA256HashData="22f721fd3a81d2e27cbf90a122bb977f630c50b79daa98350f0e57b04dfa81f1"
| table([@timestamp, aid, ComputerName, UserName, #event_simpleName, FileName, ImageFileName, TargetFileName, CommandLine, SHA256HashData])
| sort(@timestamp, order=desc)

// HUNT: Hidden dot-prefixed ELF executed from a world-writable temp dir
// MITRE: T1105, T1059.004 | CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2 (Linux)
// LOOKBACK: 7d (set in the console time picker)
// FALSE POSITIVES: build/packaging tooling staging hidden helper binaries in /tmp
// TUNING: exclude your build-agent host group by ComputerName, and exclude any
//   approved helper basenames by adding e.g. | FileName!=/^\.(build|cache)-/i
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| event_platform=Lin
| ImageFileName=*/tmp/.*
| FileName=/^\.[A-Za-z0-9_-]{1,12}$/
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, ImageFileName, CommandLine, SHA256HashData])
| sort(@timestamp, order=desc)

// HUNT: Distributed scanner invoked with the campaign's argument set
// MITRE: T1595.002, T1190, T1119 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2
// LOOKBACK: 30d (set in the console time picker)
// FALSE POSITIVES: a sanctioned internal scanner using a coincidentally similar
//   flag set. Verify the binary path and hash before closing as benign.
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| CommandLine=/\bipscan\b/i
| CommandLine=/--exploit|--envdump|--git-workers|--no-reverse|--source[ =]random/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, ImageFileName, CommandLine, SHA256HashData])
| sort(@timestamp, order=desc)

// HUNT: Campaign C2 API paths referenced on a command line
// MITRE: T1105, T1020, T1041 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2
// LOOKBACK: 30d (set in the console time picker)
// FALSE POSITIVES: none observed - these paths are campaign-specific
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| CommandLine=/\x2fapi\x2f(github-heartbeat|github-results|dl\x2f(386|amd64|arm64|arm))/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc)

// HUNT: Download tool fetching from a raw IPv4 over plaintext HTTP into temp
// MITRE: T1105 | CONF: medium  FP: medium  COST: medium
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2
// LOOKBACK: 7d (set in the console time picker)
// FALSE POSITIVES: internal package mirrors and artifact stores addressed by IP;
//   provisioning scripts that pull from a bootstrap host
// TUNING: exclude your own mirrors by adding a negative match on their octets,
//   e.g. | CommandLine!=/http:\x2f\x2f10\.20\.30\./, and exclude sanctioned
//   provisioning parents by ParentBaseFileName (cloud-init, ansible, chef-client)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(curl|wget)$/i
| CommandLine=/http:\x2f\x2f\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
| CommandLine=/-o[ =]\x2ftmp\x2f|-O[ =]\x2ftmp\x2f|\x2ftmp\x2f\./
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])
| sort(@timestamp, order=desc)

// HUNT: Panel-port fan-out consistent with mass cPanel/WHM scanning
// MITRE: T1595.002, T1496.002 | CONF: high  FP: medium  COST: medium
// REQUIRES: NetworkConnectIP4
// LOOKBACK: 24h (set in the console time picker)
// FALSE POSITIVES: hosting-provider monitoring, server-migration tooling,
//   backup agents, and multi-tenant admin jumpboxes
// TUNING: exclude sanctioned management hosts by ComputerName before promoting,
//   and raise the threshold until your own admin jumpboxes fall below it
#event_simpleName=NetworkConnectIP4
| in(field=RemotePort, values=["2082", "2083", "2086", "2087"])
| groupBy([aid, ComputerName], function=[count(field=RemoteAddressIP4, distinct=true, as=distinct_targets), count(as=total_conns)])
| distinct_targets > 25
| sort(distinct_targets, order=desc)

// HUNT: cPanel/WHM daemon spawning a shell, interpreter or download tool
// MITRE: T1190, T1059.004 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2 (Linux, cPanel hosts)
// LOOKBACK: 30d (set in the console time picker)
// FALSE POSITIVES: cPanel hooks and custom WHM plugins legitimately shell out;
//   confirm the child command line before escalating
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| event_platform=Lin
| ParentBaseFileName=/^(cpsrvd|cpsrvd-ssl|whostmgrd|cpanellogd|queueprocd|cpdavd|dovecot)$/i
| FileName=/^(sh|bash|dash|zsh|ksh|perl|python|python3|php|curl|wget|nc|ncat|socat|chmod|chattr|base64|xxd)$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, ImageFileName, CommandLine, SHA256HashData])
| sort(@timestamp, order=desc)

// HUNT: Bulk read/enumeration of cloud, git and SSH credential material
// MITRE: T1552.001, T1005, T1119 | CONF: medium  FP: high  COST: medium
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2 (Linux)
// LOOKBACK: 7d (set in the console time picker)
// FALSE POSITIVES: backup agents, ansible/chef/puppet runs, CI deploy steps,
//   and administrators legitimately reading their own dotfiles
// TUNING: exclude backup and config-management parents first --
//   | ParentBaseFileName!=/^(ansible|ansible-playbook|chef-client|puppet|restic|borg|rsync|duplicity)$/i
//   then require 2 or more distinct credential paths per host per hour before triage
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| event_platform=Lin
| FileName=/^(cat|grep|egrep|find|tar|zip|awk|sed|head|xargs|strings)$/i
| CommandLine=/\.aws\x2fcredentials|\.git-credentials|\.ssh\x2fid_(rsa|ed25519|ecdsa)|\.env\b|\.npmrc|\.pypirc|\.docker\x2fconfig\.json|\.netrc/i
| groupBy([aid, ComputerName, UserName, ParentBaseFileName], function=[count(as=hits), collect([CommandLine])])
| sort(hits, order=desc)

// HUNT: Self-hosted Actions runner spawning download tooling or a /tmp binary
// MITRE: T1195.001, T1584.006, T1059.004 | CONF: medium  FP: medium  COST: medium
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2 on self-hosted runners
// LOOKBACK: 7d (set in the console time picker)
// FALSE POSITIVES: normal CI dependency fetches and toolchain installers
// TUNING: baseline your pipelines first, then exclude approved build steps by
//   ParentBaseFileName, and keep only rows where ImageFileName sits under /tmp
//   or the command line targets a raw IPv4 host
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(Runner\.Worker|Runner\.Listener|run-helper\.sh|runsvc\.sh|actions-runner)$/i
| FileName=/^(curl|wget|nc|ncat|socat|chmod|nslookup|dig|host)$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, ImageFileName, CommandLine])
| sort(@timestamp, order=desc)

// HUNT: Bulk workflow-file manipulation from a shell or scripting interpreter
// MITRE: T1195.001 | CONF: medium  FP: high  COST: medium
// REQUIRES: ProcessRollup2 / SyntheticProcessRollup2
// LOOKBACK: 30d (set in the console time picker)
// FALSE POSITIVES: developers editing CI, cookiecutter/yeoman-style scaffolding,
//   IaC generators, and repo-templating scripts
// TUNING: exclude interactive developer sessions -- drop rows whose
//   ParentBaseFileName is an IDE or terminal, and only review hosts where the
//   grouped count exceeds 20 workflow-file operations in one hour
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| CommandLine=/\.github\x2fworkflows/i
| FileName=/^(sh|bash|dash|zsh|perl|python|python3|curl|wget|cp|mv|tee|git)$/i
| groupBy([aid, ComputerName, UserName, ParentBaseFileName], function=[count(as=ops), collect([CommandLine])])
| sort(ops, order=desc)

CQL quality-review notes

• All twelve queries use documented Falcon data-model fields. event_platform is a standard sensor field but is tenant-visible only where Linux sensors are deployed: ⚠ validate in tenant that Linux telemetry is actually flowing before trusting an empty result from Q4, Q9, Q10 or Q12.
• No query carries an in-query time filter. An expression on the right of a comparison does not parse in CQL, so the window is set in the console and recorded as a // LOOKBACK: comment on each card.
• Forward slashes inside every regex literal are written as \x2f so no regex closes early. Basenames are matched through FileName, never through a path regex.
• Every card rated FP medium or higher carries a // TUNING: line inside the query block, so the exclusion travels with the query when an analyst copies it.
• Q3 covers only the amd64 build. The 386, arm and arm64 payloads were distributed but no hashes were published for them, so they are covered behaviourally by Q4–Q7 rather than by a fabricated hash.

Three queries are clean enough to promote to blocking or high-severity Custom IOAs. The rest stay Investigate-only.

Custom IOC entries (Falcon IOC Management, not IOA)

• 43.228.157.68: Block, Critical. Single-purpose actor host; there is no legitimate reason for any managed asset to reach it.
• f5b0b742-240a-4811-8a5b-b0ba6060685d.dnshook.site: Block, Critical. Detonation-only hostname.
• 22f721fd3a81d2e27cbf90a122bb977f630c50b79daa98350f0e57b04dfa81f1: Prevent, Critical.

Investigate-only (no alert email)

Q7, Q8, Q10, Q11 and Q12 are hunt queries. They earn their keep as scheduled searches feeding a weekly review queue and as correlation inputs behind IOA-1 through IOA-3, not as pageable alerts. Q1, Q2, Q3 and Q6 are covered by the IOC entries above and need no separate IOA.

Alert package: IOA-1 (the one that should page)

• Scheduled Search name: DETECT: Distributed cPanel Scanner Execution (GitHub Actions Abuse)
• Description: Fires when a process executes with the internet-scanner argument set used by the GitHub Actions abuse campaign to mass-exploit CVE-2026-41940 in cPanel and WHM. The host is either a compromised CI runner or an asset the actor is staging from.
• Email subject: [CRITICAL] Detection: distributed cPanel/WHM scanner executing on HOST-01
• Body: what fired (scanner argv match), what it means (this host is running mass-exploitation tooling against the public internet and harvesting credentials from anything it lands on), immediate actions (network-contain the host, capture the binary and its hash, pull the parent process tree, identify the triggering workflow or job), escalation (CI/platform owner plus incident commander, this is an outbound-attack event with third-party liability, not only an infection).

Triage checklist (L1, in order)

1. Confirm the process is not a sanctioned internal scanner: check full image path and SHA-256 against your approved-tooling list.
2. Network-contain the host in Falcon before further analysis. The harm is ongoing and outbound.
3. Run Q1 scoped to that aid for C2 contact; run Q2 for the DNSHook callback. Either confirms campaign attribution.
4. Pull the parent process tree. If the parent is a CI runner, identify the repository, workflow file and triggering commit.
5. Run Q10 scoped to that host to determine what credential material was reachable.
6. Treat every secret that host could read as compromised and start rotation, do not wait for confirmation of exfiltration.
7. If the host is a cPanel/WHM server, run Q9 and native hunts N3/N4, and verify the installed build against section 12.
8. Search your GitHub org for the campaign markers (native hunt N2) to find the source of the poisoned workflow.

Pivot queries

• Host-scoped: take Q1 and append | aid="THE_AID"; run over 90 days to establish first contact.
• Environment-wide: run Q6 with no other filter to find every host that has ever referenced the campaign's API paths, including ones where the binary was cleaned up.
• Blast radius: run Q8 to find any other host in the estate exhibiting the same panel-port fan-out.

Gate 1: Telemetry ready

• Confirm Falcon Linux sensors are installed and reporting on every cPanel/WHM host and every self-hosted Actions runner. Run #event_simpleName=ProcessRollup2 | event_platform=Lin | groupBy([ComputerName]) and reconcile the result against your asset inventory. A silent host is not a clean host.
• Confirm DnsRequest events are present for Linux servers. Many fleets have DNS telemetry only from workstations, which would make Q2 silently useless where it matters most.
• Confirm NetworkConnectIP4 is not being sampled or dropped on high-volume hosting servers.

Gate 2: Benign baseline

• Run Q4, Q7, Q8, Q10, Q11 and Q12 over 30 days with no exclusions and record the volume per host group. Any query returning more than ~50 rows per day per host group needs its TUNING line applied before promotion.
• Explicitly enumerate: your build-agent host group (Q4, Q11), your internal package mirrors by IP (Q7), your sanctioned hosting-management jumpboxes (Q8), and your backup/config-management parents (Q10).

Gate 3: Positive tests (safe, defensive only)

• Q1: from an isolated test host, initiate a TCP connection to the C2 address on tcp/80 and confirm the event lands. Do not send data.
• Q2: resolve a benign sub-hostname under the callback domain from a test host and confirm DnsRequest fires.
• Q4: copy /bin/true to /tmp/.tst, chmod 755, execute it once, confirm the row appears, then delete it.
• Q5: create a harmless script named ipscan that only echoes its arguments, invoke it with --envdump --no-reverse, and confirm the match. No scanning, no exploitation.
• Q9: on a lab cPanel host only, confirm the parent/child mapping fires by having a test cPanel hook invoke /bin/sh -c true.

Gate 4: Promotion criteria

• Promote Q5 to IOA-1 (block) immediately: the FP surface is effectively nil.
• Promote Q9 to IOA-2 at Detect severity; move to Block only after two consecutive clean weeks with your cPanel hooks baselined.
• Promote Q4 to IOA-3 at Detect after the build-agent exclusion is in place.
• Q7, Q8, Q10, Q11, Q12 stay as scheduled searches feeding a review queue. Do not page on them.

What hardening cannot fix here: the scanning traffic originates from GitHub-hosted runner address space. Blocking source IPs would mean blocking GitHub, and the actor loses nothing when a runner is torn down. Patch state and control-plane exposure are the only variables you actually control on the victim side.

P1 · Patch and verify cPanel / WHM (Linux, root)

Prerequisites: root on the cPanel/WHM host; a current full backup or a VM snapshot; a maintenance window (upcp restarts panel services and briefly interrupts panel access); knowledge of your current release tier. Reboot required: no: upcp restarts cpsrvd and related services, but no host reboot is needed unless the update also pulls a kernel. Rollback: cPanel does not support downgrading across a release tier. Roll back by restoring the pre-update VM snapshot or backup taken in step 1: that snapshot is the rollback plan, so do not skip it.

# 1. Snapshot / back up FIRST. This is the only rollback path.
/usr/local/cpanel/scripts/pkgacct --skipbwdata USERNAME   # per-account, or take a VM snapshot

# 2. Record the current build so you can prove what changed.
/usr/local/cpanel/cpanel -V | tee /root/cpanel-version-before.txt

# 3. Confirm the update tier. RELEASE or STABLE both receive the fix; a frozen
#    or manually pinned tier will NOT.
grep -E '^(CPANEL|UPDATES)=' /etc/cpupdate.conf

# 4. Update.
/usr/local/cpanel/scripts/upcp --force

# 5. Verify against the fixed build for your tier (see section 10 audit block).
/usr/local/cpanel/cpanel -V | tee /root/cpanel-version-after.txt

# 6. Confirm the panel services came back.
systemctl status cpanel;  ss -ltnp | grep -E ':(2083|2087)\b'

P2 · Restrict the cPanel / WHM control plane to trusted networks (firewalld)

Prerequisites: root; firewalld active; the exact CIDR ranges your administrators connect from, confirmed in advance. Reboot required: no. Rollback: every command below has an explicit undo in the rollback block, run it to restore the previous state. Test from a second, already-open session before you close the first: locking yourself out of a remote host is the realistic failure mode here.

# Replace 198.51.100.0/24 with YOUR administrative range before running anything.
ADMIN_NET="198.51.100.0/24"

# 1. Create a trusted source zone and put the panel ports in it.
firewall-cmd --permanent --new-zone=cpanel-admin
firewall-cmd --permanent --zone=cpanel-admin --add-source="$ADMIN_NET"
for P in 2082 2083 2086 2087 2095 2096; do
  firewall-cmd --permanent --zone=cpanel-admin --add-port=${P}/tcp
done

# 2. Remove those ports from the public zone.
for P in 2082 2083 2086 2087 2095 2096; do
  firewall-cmd --permanent --zone=public --remove-port=${P}/tcp
done

# 3. Apply, then VERIFY FROM A SECOND SESSION before closing this one.
firewall-cmd --reload
firewall-cmd --zone=cpanel-admin --list-all
firewall-cmd --zone=public --list-ports

# --- ROLLBACK ---------------------------------------------------------------
# for P in 2082 2083 2086 2087 2095 2096; do
#   firewall-cmd --permanent --zone=public --add-port=${P}/tcp
# done
# firewall-cmd --permanent --delete-zone=cpanel-admin
# firewall-cmd --reload

P3 · Harden /tmp against payload execution (Linux servers and CI runners)

Prerequisites: root; /tmp already on its own filesystem, or willingness to move it to a tmpfs mount; a pilot ring: some package managers and installers execute from /tmp and will break. Reboot required: no if you remount live; yes to prove the fstab change survives a boot, which you should do in the pilot ring. Rollback: restore the saved /etc/fstab copy and remount with exec, shown in the rollback block.

# 1. Back up fstab. This is the rollback artefact.
cp -a /etc/fstab /root/fstab.bak-$(date +%F)

# 2. Check whether /tmp is already a separate filesystem.
findmnt /tmp

# 3a. If /tmp IS a separate mount, add the options.
sed -i.huntpack -E 's|^(\S+\s+/tmp\s+\S+\s+)([^ ]+)|\1\2,noexec,nosuid,nodev|' /etc/fstab

# 3b. If /tmp is NOT separate, mount it as tmpfs instead.
# echo 'tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev,size=2G 0 0' >> /etc/fstab

# 4. Apply live and verify.
mount -o remount /tmp
findmnt -no OPTIONS /tmp     # expect noexec,nosuid,nodev present

# 5. Prove the control works: this must now FAIL.
cp /bin/true /tmp/.hp-test && chmod 755 /tmp/.hp-test && /tmp/.hp-test; echo "exit=$?"
rm -f /tmp/.hp-test

# --- ROLLBACK ---------------------------------------------------------------
# cp -a /root/fstab.bak-YYYY-MM-DD /etc/fstab
# mount -o remount,exec /tmp
# findmnt -no OPTIONS /tmp

P4 · Lock down GitHub Actions at the organisation level

Prerequisites: org owner rights; gh authenticated with admin:org scope; agreement from engineering leads, because read-only default token permissions will break pipelines that silently relied on write access. Reboot required: none: these are API-side settings, effective on the next workflow run. Rollback: each setting has an inverse API call in the rollback block; capture the current values in step 0 first so you can restore exactly what was there.

ORG="YOUR_ORG"

# 0. CAPTURE CURRENT STATE FIRST - this is your rollback record.
gh api "orgs/$ORG/actions/permissions"                  | tee /tmp/gh-actions-before.json
gh api "orgs/$ORG/actions/permissions/workflow"         | tee -a /tmp/gh-actions-before.json

# 1. Default GITHUB_TOKEN permissions to read-only; workflows must opt in.
gh api -X PUT "orgs/$ORG/actions/permissions/workflow" \
  -f default_workflow_permissions=read \
  -F can_approve_pull_request_reviews=false

# 2. Allow only local + verified-creator actions.
gh api -X PUT "orgs/$ORG/actions/permissions" \
  -f enabled_repositories=all -f allowed_actions=selected
gh api -X PUT "orgs/$ORG/actions/permissions/selected-actions" \
  -F github_owned_allowed=true -F verified_allowed=true -f 'patterns_allowed[]='

# 3. Require review on the workflows path in each repo (CODEOWNERS).
#    Commit this to .github/CODEOWNERS on the default branch:
#    /.github/workflows/  @YOUR_ORG/ci-reviewers

# 4. Verify.
gh api "orgs/$ORG/actions/permissions/workflow"

# --- ROLLBACK ---------------------------------------------------------------
# Replay the values captured in /tmp/gh-actions-before.json:
# gh api -X PUT "orgs/$ORG/actions/permissions/workflow" \
#   -f default_workflow_permissions=write -F can_approve_pull_request_reviews=true
# gh api -X PUT "orgs/$ORG/actions/permissions" -f allowed_actions=all

P5 · Falcon-side blocking (IOC Management + Custom IOA)

Prerequisites: Falcon role with IOC Management write and Custom IOA authoring; a chosen host group for the IOA rule group; agreement that prevention (not just detection) is wanted. Reboot required: none. Rollback: disable the IOA rule group (do not delete it: you lose the tuning history) and set the IOC actions back to no_action; both undos are shown below.

# 1. Import the atomic indicators (section 10 CSV) via
#    Endpoint security > IOC management > Add indicators > Upload CSV.
#    Set: ipv4 + domain + sha256 -> Prevent/Block, severity Critical.
#    Set: url rows -> Detect (URL matching depends on module licensing).

# 2. Create the IOA rule group.
#    Endpoint security > Custom IOA rule groups > Create rule group
#      Platform: Linux    Name: GHActions-cPanel-Campaign
#
#    IOA-1  Process Creation  ACTION: Block Execution   SEVERITY: Critical
#      Command Line.*\bipscan\b.*
#      Command Line.*(--exploit|--envdump|--git-workers|--no-reverse).*
#
#    IOA-2  Process Creation  ACTION: Detect            SEVERITY: High
#      Parent Image Filename.*\x2f(cpsrvd|cpsrvd-ssl|whostmgrd|cpdavd)$
#      Image Filename.*\x2f(sh|bash|dash|perl|python3?|curl|wget|nc|socat)$
#
#    IOA-3  Process Creation  ACTION: Detect            SEVERITY: High
#      Image Filename.*\x2ftmp\x2f\.[A-Za-z0-9_-]{1,12}$

# 3. Assign the rule group to a PILOT host group first. Promote to the full
#    Linux group only after Gate 2 baselining in section 11 is clean.

# --- ROLLBACK ---------------------------------------------------------------
# Custom IOA rule group -> toggle Enabled = off (keep the group; deleting it
#   discards every exclusion you tuned).
# IOC management -> select the campaign tag -> set action to "No action".

Do not skip evidence capture to move faster. Deleting a poisoned workflow file and its Actions run log is the single most common way an organisation loses the ability to answer "what secrets did it read". Capture first, then eradicate.

Known gaps and what to do about them

• GitHub-hosted runners are unreachable. Three chain steps (3, 4 and part of 8) execute on third-party ephemeral compute. Nothing in Falcon will ever see them. Native hunts N1 and N2 plus the org-level controls in playbook P4 are the entire coverage, and they are preventative and retrospective rather than detective.
• The authentication bypass leaves no EDR signal. CVE-2026-41940 is exploited inside the cpsrvd process; nothing spawns until the attacker acts. Q9 catches what they do next, and native hunts N3/N4 catch the on-disk residue. If the attacker only reads data through the panel API, neither will fire, which is why patching (H-I2) is not optional and cannot be substituted with detection.
• Only one payload hash is public. Three of four architecture builds have no published hash. Do not fill that gap with an invented hash; Q4 through Q7 cover them behaviourally.
• Data staging on the runner is unobservable. Accepted gap. Exfiltration is still caught at the network layer by Q1 and Q6.

Validation gates for all of the above are in section 11: confirm Linux telemetry is actually flowing (Gate 1) before reading any empty result as a clean result, baseline the six noisy queries for 30 days (Gate 2), run the safe positive tests (Gate 3), then promote Q5, Q9 and Q4 in that order (Gate 4).

Provenance: the fetched plain text of every cited source above is saved verbatim in GitHubActions-cPanel-CVE-2026-41940-Hunt-sources/ (7 files). Every atomic indicator in section 10 traces back to at least one of those snapshots. Nothing in this pack is an indicator that no source published.