wp2shell — WordPress Core Pre-Authentication RCE Chain

What the attacker wants: a durable webshell on an internet-facing WordPress host, reached without a single credential. wp2shell chains a logic flaw in the WordPress REST API batch processor (CVE-2026-63030, /wp-json/batch/v1) with a SQL injection in the author__not_in parameter of WP_Query (CVE-2026-60137). The batch endpoint validates and executes sub-requests in two separate loops; when path parsing fails on one sub-request the error lands in the validation array but not the matches array, desynchronising the two so every later sub-request dispatches under someone else's handler. The attacker rides that confusion into the injection, forges an administrator, uploads a plugin, and gets OS command execution as the web-server user.

Why it matters operationally: the attack has no preconditions. A stock install with no plugins and no theme customisation is exploitable by an anonymous request. Disclosure was 2026-07-17 (Adam Kues, Assetnote / Searchlight Cyber, via the WordPress HackerOne programme); public proof-of-concept code and mass scanning followed within hours, and multiple vendors confirmed in-the-wild exploitation by 2026-07-20. Patched builds are 6.8.6, 6.9.5 and 7.0.2; WordPress.org pushed forced auto-updates, which means most managed estates are already fixed and the residual risk concentrates in installs that pin versions, block auto-update, or were compromised before the update landed.

The highest-value defensive angle for Falcon: not the exploit, the payload. A Falcon sensor on the web server never sees the HTTP request path, the 207 Multi-Status response, or the wp2shell user agent — those live in web-server, WAF and proxy logs. What the sensor sees perfectly is the moment the webshell is used: a php-fpm, httpd, apache2, nginx or w3wp.exe process spawning sh, bash, curl, whoami or powershell.exe. That parent-child relationship is close to zero in a healthy estate and it fires on every webshell family reported for this campaign, including the ones nobody has published a hash for yet. Queries Q1, Q2 and Q10 are the pack's spine; the atomic indicators are a bonus, not the plan.

Defender priority: confirm every WordPress host you own is on 6.8.6 / 6.9.5 / 7.0.2 or later, then assume the window 2026-07-17 to patch-time was hostile and hunt it. Patching does not evict a webshell that was already dropped, and the campaign's own scanners were faster than most patch cycles. Run Q1 and Q2 across the last 30 days before you close this out.

Conflict noted, not resolved: Rapid7 scores CVE-2026-63030 at CVSS 7.5 while Tenable and Coalition score it 9.8. The pack treats it as critical on the basis of unauthenticated RCE and CISA KEV inclusion, and records the disagreement rather than picking a winner. Verify against NVD before quoting a number in a risk register.

Provenance discipline: the raw fetched text of every source above is saved alongside this file in wp2shell-CVE-2026-63030-Hunt-sources/. Every atomic indicator shipped in Section 10 traces to snapshot 01-wiz.txt. Nothing in this pack was written from memory. No source contained instructions directed at an automated agent, and none was disqualified.

Attack chain

Hunt hypotheses (ordered by fidelity)

Read the Action column before you block anything. The five IPs are scanning and exploitation infrastructure, not dedicated C2. Two sit in hyperscaler ranges where addresses are recycled within weeks, so they are scoped detect with a deliberately short 3-month expiry rather than prevent. The SHA1 hashes are file hashes of PHP webshells; Falcon Custom IOC Management does not accept SHA1, so they are routed to a filesystem scan instead of an import. The user agents and URI paths are genuine high-fidelity indicators but they only exist in web-server, WAF and proxy logs.

Why this section exists. Steps 1 to 4 of the attack chain leave no endpoint trace. The batch endpoint, the 207 Multi-Status response, the wp2shell user agents and the forged administrator all live in web-server logs and in the WordPress database. An EDR sensor cannot see any of them. Treat the checks below as first-class hunt work, not as an appendix to the CQL.

N1 · Web-server access logs — exploitation attempts and successes

Run on each WordPress host, or against your centralised HTTP logs. Cover 2026-07-16 onward, or from the last known-good backup if earlier.

# Requests to the vulnerable batch endpoint, either routing form
grep -aEi 'batch/v1|rest_route=/batch/v1' /var/log/nginx/access.log* /var/log/apache2/access.log*

# The three published exploitation user agents
grep -aEi 'wp2shell|rezwp2shell|cve-2026-63030' /var/log/nginx/access.log* /var/log/apache2/access.log*

# Highest-fidelity success signal: a 207 or 200 Multi-Status response to a batch request
awk '$0 ~ /batch\/v1/ && ($9 == 207 || $9 == 200)' /var/log/nginx/access.log

# Post-exploitation follow-on paths
grep -aEi 'plugin-install\.php|update\.php\?action=upload-plugin|wp/v2/users\?context=edit|admin-ajax\.php\?template=' /var/log/nginx/access.log*

Log-blind caveat (Eye Security): a clean access log does not clear the host. Much of the chain executes inside the database through the injection, and the exploitation request itself can look unremarkable. Absence of evidence here is not evidence of absence — proceed to N3 and N4 regardless.

N2 · WAF / CDN edge

• Confirm a block rule exists for both /wp-json/batch/v1 and ?rest_route=/batch/v1. Blocking only the first leaves the endpoint fully reachable — SANS ISC honeypots caught the second form in live traffic.
• If you sit behind Cloudflare, confirm the vendor-deployed managed rule is enabled and in block, not log.
• Pull the edge log for source IPs matching the five in Section 4 and pivot on every path they touched, not just the batch endpoint.

N3 · WordPress file system — webshell hunt

# Any PHP file under the web root modified since the day before disclosure
find /var/www -name '*.php' -newermt '2026-07-16' -printf '%T+ %s %p\n' | sort

# PHP where PHP has no business existing
find /var/www -path '*wp-content/uploads/*' -name '*.php'
find /var/www -path '*wp-content/cache/*'   -name '*.php'

# Plugin directories matching the reported naming pattern (hex suffix)
find /var/www -type d -path '*wp-content/plugins/*' -regextype posix-extended -regex '.*(wp2shell_[0-9a-f]+|.*-[0-9a-f]{6})$'

# Match the five published SHA1 webshell hashes against every PHP file on the host
find /var/www -name '*.php' -type f -exec sha1sum {} + | grep -Fi -f wp2shell-sha1.txt

# Suspicious shell-out primitives in freshly changed PHP
grep -rlE 'shell_exec|passthru|proc_open|popen|base64_decode\s*\(\s*\$' /var/www --include='*.php'

Build wp2shell-sha1.txt from the SHA1 block in Section 10. Also look for a fake Author: WordPress.org Community plugin header and for tiny (roughly 1.3 KB) PHP files gated behind a token parameter — both were reported as wp2shell webshell traits.

N4 · WordPress database — forged administrators and injection residue

• List every user with the administrator role and reconcile against your own roster. Flag user_login values matching wp2_*, w2s_* or wpsvc_*, and any account whose email domain you do not own.
• Look for gaps in the ID sequence of wp_users and for orphaned wp_usermeta rows — Eye Security reports both as injection residue.
• Inspect wp_options for oEmbed cache rows pointing at loopback, and check for unexpected changeset or request post types.
• Review active_plugins in wp_options against the plugin directory listing; a webshell plugin is sometimes activated and sometimes left dormant.

N5 · Version attestation

• Confirm every install reports 6.8.6, 6.9.5, 7.0.2 or later. Anything on 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1 is exposed to the full RCE chain; 6.8.0 to 6.8.5 is exposed to the SQL injection alone.
• Where a site was auto-updated by WordPress.org, record the timestamp. The delta between 2026-07-17 and that timestamp is your exposure window and the range every hunt in this pack should cover.
• Sites using a persistent object cache (Redis or Memcached) may have escaped this specific RCE path, per Tenable and The Hacker News. The SQL injection remains exploitable regardless — do not treat an object cache as a mitigation.

Scope note — endpoint telemetry only. None of the queries below can see an HTTP request path, a response code, or a user-agent string. Falcon's sensor observes processes, files and sockets, not the web server's request handling. Every query here therefore targets what the webshell does after it is reached. The request-level indicators are hunted in Section 7 against web and proxy logs. If you have HTTP logs in NG-SIEM the same indicators can be queried there, but the field names are parser-specific to your ingest and must be validated against a real sample row before use — this pack does not guess at them.

No query carries an in-query time filter. Set the window with the Falcon console time picker; each card records the intended lookback as a // LOOKBACK: comment. Start at 30 days and widen to cover the interval from 2026-07-17 to the moment your estate patched.

// HUNT: Web-server process spawning a shell or interpreter (wp2shell webshell execution)
// MITRE: T1190, T1505.003, T1059.004, T1059.003 | CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 with parent lineage on Linux and Windows web servers
// FALSE POSITIVES: CMS auto-updaters, backup/migration plugins, WP-CLI wrappers, deploy hooks
// TUNING: exclude your deploy and backup service accounts by UserName, and your CI/CD build hosts
// TUNING: by ComputerName; then re-run and treat whatever remains as a genuine lead
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php[0-9.]*-fpm|php-cgi|httpd|apache2|nginx|lsphp|litespeed|w3wp\.exe)$/i
| FileName=/^(sh|bash|dash|zsh|ksh|busybox|python[0-9.]*|perl|ruby|node|cmd\.exe|powershell\.exe|pwsh\.exe)$/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Discovery commands executed under a web-server parent (post-webshell recon)
// MITRE: T1033, T1082, T1087, T1046 | CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 with parent lineage on web hosts
// FALSE POSITIVES: monitoring agents, container health checks and readiness probes running as the web user
// TUNING: exclude the ComputerName of dedicated build and monitoring boxes; exclude the UserName your
// TUNING: observability agent runs as. Do NOT exclude the binaries themselves - they are the signal.
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(sh|bash|dash|php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|w3wp\.exe)$/i
| FileName=/^(whoami|id|uname|hostname|hostnamectl|ifconfig|netstat|ss|ps|env|lsb_release|systeminfo\.exe|net\.exe|net1\.exe|nslookup)$/i
| groupBy([ComputerName, UserName, ParentBaseFileName], function=[count(as=Hits), collect([FileName, CommandLine], limit=40)], limit=200)
| sort(Hits, order=desc, limit=100)

// HUNT: New executable or ELF written under the WordPress web root
// MITRE: T1505.003, T1105, T1068 | CONF: medium  FP: medium  COST: low
// REQUIRES: ELFFileWritten (Linux) / NewExecutableWritten (Windows) on web hosts
// FALSE POSITIVES: plugins shipping compiled helpers, composer vendor trees, backup restores
// TUNING: exclude the ComputerName plus time window of scheduled restores, and any vendor subpath
// TUNING: you have formally allowlisted; pivot every survivor on ContextProcessId into Q1
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ELFFileWritten|NewExecutableWritten)$/
| TargetFileName=/wp-content\/(plugins|uploads|cache|themes|upgrade)\//i
| table([@timestamp, ComputerName, UserName, TargetFileName, ContextProcessId, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: WordPress web-root PHP file modified (webshell plugin drop) via file-integrity telemetry
// MITRE: T1505.003, T1036.005 | CONF: medium  FP: medium  COST: low
// REQUIRES: CriticalFileModified - needs a FileVantage/FIM policy covering the WordPress web root.
// REQUIRES: Falcon does NOT emit a generic write event for .php text files. Without that policy this
// REQUIRES: query returns nothing even on a compromised host - see Section 7 N3 for the host-side scan.
// FALSE POSITIVES: WordPress forced auto-updates and normal plugin installs write here constantly
// TUNING: exclude the wp-content/upgrade staging path and your maintenance window, then correlate the
// TUNING: survivors against Q1 on the same ComputerName - a write with no shell nearby is usually benign
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^CriticalFileModified$/
| TargetFileName=/wp-content\/(plugins|cache|uploads|themes)\/.*\.php$/i
| table([@timestamp, ComputerName, UserName, TargetFileName, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Endpoint connecting outbound to a published wp2shell exploitation IP
// MITRE: T1071.001, T1190 | CONF: high  FP: low  COST: low
// REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: cloud IP reassignment - two of these five are in hyperscaler ranges. A hit dated
// FALSE POSITIVES: well outside 2026-07-17..now is far more likely to be a recycled address.
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^NetworkConnectIP4$/
| in(RemoteAddressIP4, values=["34.81.132.62", "79.177.131.206", "15.157.135.170", "94.100.52.128", "172.235.128.52"])
| table([@timestamp, ComputerName, ContextBaseFileName, RemoteAddressIP4, RemotePort, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Download utility launched by a web-server process (second-stage retrieval)
// MITRE: T1105 | CONF: high  FP: medium  COST: low
// REQUIRES: ProcessRollup2 with CommandLine
// FALSE POSITIVES: plugin/theme update routines, composer and npm installs run as the web user
// TUNING: exclude CommandLine values pointing at your internal package mirror and at wordpress.org;
// TUNING: exclude CI/CD hosts by ComputerName. Keep curl and wget in scope - narrow the destination.
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|sh|bash|dash|w3wp\.exe)$/i
| FileName=/^(curl|wget|fetch|bitsadmin\.exe|certutil\.exe|powershell\.exe|pwsh\.exe|python[0-9.]*)$/i
| CommandLine=/(http:|https:|ftp:|--output|-OutFile|Invoke-WebRequest|DownloadString|DownloadFile|urlcache)/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: WordPress config or credential material accessed from a web-server process tree
// MITRE: T1552.001, T1005, T1068 | CONF: medium  FP: medium  COST: low
// REQUIRES: ProcessRollup2 with CommandLine
// FALSE POSITIVES: backup, staging and migration tools legitimately read wp-config.php and dump the DB
// TUNING: exclude your backup product's FileName and its nightly window by hour; exclude WP-CLI db
// TUNING: export jobs launched from an interactive admin session rather than from a web-server parent
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|sh|bash|dash|w3wp\.exe|cmd\.exe)$/i
| CommandLine=/(wp-config\.php|\/etc\/passwd|\/etc\/shadow|mysqldump|DB_PASSWORD|AUTH_KEY|\.my\.cnf)/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Persistence mechanism created from a web-server process tree
// MITRE: T1053.003, T1053.005, T1543, T1136.001 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2 with parent lineage
// FALSE POSITIVES: rare - some shared-hosting control panels register cron jobs as the web user
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php-cgi|httpd|apache2|nginx|sh|bash|dash|w3wp\.exe|cmd\.exe|powershell\.exe)$/i
| FileName=/^(crontab|at|systemctl|systemd-run|schtasks\.exe|sc\.exe|reg\.exe|useradd|adduser|usermod|chattr|ssh-keygen)$/i
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, aid])
| sort(@timestamp, order=desc, limit=200)

// HUNT: Published wp2shell webshell SHA1 observed in endpoint process telemetry
// MITRE: T1505.003 | CONF: low  FP: low  COST: low
// REQUIRES: ProcessRollup2 / ImageHash
// NOTE: these five hashes are PHP webshell SOURCE FILES. PHP is interpreted, not executed as a process
// NOTE: image, so they will normally never surface here. A clean result proves nothing. The authoritative
// NOTE: check is the sha1sum sweep in Section 7 N3; Falcon Custom IOC Management cannot ingest SHA1.
// FALSE POSITIVES: none expected - any hit is a confirmed incident
// LOOKBACK: 90d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2|ImageHash)$/
| SHA1HashData=/^(2a1410d8e2a8337ac2171cedea8c0fdc47c647a0|58eca847e9eae9e6b08cc211f1559817b71bc4cc|ebea44890f434d5d67ede22009a3f4bb5cac33f8|d9a220c8039f1c4d72cae7ccb8b3a33dec8815be|e9756e2338f84746007235e4cab7a70d5b3ca47f)$/i
| table([@timestamp, ComputerName, UserName, FileName, SHA1HashData, CommandLine, aid])
| sort(@timestamp, order=desc, limit=100)

// HUNT: Rare child processes of web-server parents (catch-all for unnamed webshell payloads)
// MITRE: T1190, T1505.003 | CONF: medium  FP: high  COST: medium
// REQUIRES: ProcessRollup2 across every web host in the estate
// FALSE POSITIVES: high by design. The common rows are your normal; the sparse tail is the signal.
// TUNING: read only rows where Hosts is 1 or 2 - a child seen fleet-wide is infrastructure, not an
// TUNING: intrusion. Once baselined, exclude your CMS auto-update and backup binaries by FileName.
// TUNING: never promote this query to a Scheduled Search without that exclusion list in place.
// LOOKBACK: 30d (set in the console time picker)
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(php|php-fpm[0-9.]*|php[0-9.]*-fpm|php-cgi|httpd|apache2|nginx|lsphp|litespeed|w3wp\.exe)$/i
| groupBy([FileName], function=[count(as=Execs), count(ComputerName, distinct=true, as=Hosts), collect([CommandLine], limit=5)], limit=500)
| sort(Execs, order=asc, limit=120)

Custom IOA candidates

Not IOA candidates: Q2, Q3, Q4, Q5, Q9 and Q10 stay Investigate-only. Q2 and Q10 are volume hunts, Q3 and Q4 depend on FIM policy coverage that varies by host group, Q5 is a perishable atomic-IOC sweep better handled by IOC Management, and Q9 is structurally unlikely to fire at all. Promoting any of them without the tuning in their cards will generate noise that trains analysts to ignore the whole rule family.

Scheduled Search packaging (for the promoted IOAs)

Alert email body (template)

WHAT FIRED
A web-server or PHP process spawned an interactive shell or scripting interpreter
on a host in the WordPress server group.

  Host          : {{ComputerName}}
  User          : {{UserName}}
  Parent        : {{ParentBaseFileName}}
  Child         : {{FileName}}
  Command line  : {{CommandLine}}
  First seen    : {{@timestamp}}

WHAT IT MEANS
A healthy web server almost never launches a shell. This parent-child pair is the
execution signature of a web shell. Given active in-the-wild exploitation of
wp2shell (CVE-2026-63030 + CVE-2026-60137) against WordPress Core, treat this as a
probable post-exploitation event until proven otherwise.

IMMEDIATE ACTIONS
  1. Do not reboot or reimage yet - capture volatile state first.
  2. Network-contain the host in Falcon if the command line shows recon,
     credential access, or an outbound download.
  3. Confirm the WordPress version. Anything below 6.8.6 / 6.9.5 / 7.0.2 is
     vulnerable and the host should be treated as compromised.
  4. Run the Section 7 N3 filesystem hunt and the N4 database hunt on this host.
  5. Preserve the web-server access log before rotation removes the request that
     triggered the shell.

ESCALATION
  Confirmed webshell    -> incident response, severity 1
  Unexplained but clean -> hunt lead, 24h follow-up
  Matched exclusion     -> tune the rule, record the exclusion, close

L1 triage checklist

1. Record host, user, parent, child and full command line from the detection before touching anything.
2. Check the WordPress version on the host. Vulnerable version plus this alert equals a presumed compromise.
3. Pivot the host into Q2, Q6, Q7 and Q8 scoped to the same ComputerName and a window of a few hours either side. A lone shell is ambiguous; a shell followed by whoami and curl is not.
4. Run Q5 for the same host to see whether it reached any published exploitation IP.
5. Run the Section 7 N3 filesystem hunt on the host — recently modified PHP, PHP in uploads or cache, and the SHA1 sweep.
6. Run the Section 7 N4 database hunt — list administrators and reconcile against your roster.
7. Grep the web-server access log for the batch endpoint and the three user agents, restricted to the hours before the alert.
8. If two or more of steps 5 to 7 return findings, escalate to incident response and move to the Section 14 containment runbook. If all are clean and the parent command line matches a documented exclusion, tune and close with the exclusion recorded.

type,value,action,severity,expiration,description,tags
ipv4,34.81.132.62,detect,high,2026-10-24,wp2shell exploitation source,campaign:wp2shell
ipv4,79.177.131.206,detect,high,2026-10-24,wp2shell exploitation source,campaign:wp2shell
ipv4,15.157.135.170,detect,high,2026-10-24,wp2shell exploitation source,campaign:wp2shell
ipv4,94.100.52.128,detect,high,2026-10-24,wp2shell exploitation source,campaign:wp2shell
ipv4,172.235.128.52,detect,high,2026-10-24,wp2shell mass-scanning source,campaign:wp2shell
sha256,REPLACE_WITH_SHA256_OF_YOUR_OWN_RECOVERED_WEBSHELL,prevent,critical,2027-01-24,wp2shell PHP webshell recovered locally,campaign:wp2shell
# The five published webshell hashes are SHA1. Falcon Custom IOC Management accepts
# sha256 and md5 only, so these CANNOT be imported here. Run them against the
# filesystem sweep in Section 7 N3 and via Q9, and if you recover a sample locally,
# compute its SHA256 and replace the placeholder row above.
# 2a1410d8e2a8337ac2171cedea8c0fdc47c647a0
# 58eca847e9eae9e6b08cc211f1559817b71bc4cc
# ebea44890f434d5d67ede22009a3f4bb5cac33f8
# d9a220c8039f1c4d72cae7ccb8b3a33dec8815be
# e9756e2338f84746007235e4cab7a70d5b3ca47f

PROCESS LINEAGE
  php | php-fpm | php-cgi | httpd | apache2 | nginx | lsphp | w3wp.exe
    -> sh | bash | dash | zsh | busybox | python | perl | cmd.exe | powershell.exe
  same parents -> whoami | id | uname | hostname | ss | netstat
  same parents -> curl | wget | certutil.exe   (command line contains a URL)
  same parents -> crontab | systemctl | schtasks.exe | useradd

FILESYSTEM
  new or modified *.php under wp-content/plugins, wp-content/cache, wp-content/uploads
  plugin directory matching wp2shell_<hex> or <plausible-name>-<6 hex chars>
  ~1.3 KB PHP file carrying a fake "Author: WordPress.org Community" plugin header
  ~150 KB obfuscated PHP plugin (CMSmap-derived: file manager, DB access,
    port scanner, MySQL UDF privilege escalation)
  PHP calling shell_exec | passthru | proc_open | popen on decoded input
  webshell command parameters observed: c=<command> and b=<base64 command>

HTTP  (web / WAF / proxy logs only - NOT visible to the endpoint sensor)
  POST /wp-json/batch/v1        with HTTP 207 or 200 Multi-Status response
  POST /?rest_route=/batch/v1   with HTTP 207 or 200 Multi-Status response
  User-Agent contains: wp2shell | rezwp2shell | cve-2026-63030/1.0
  follow-on: /wp-admin/plugin-install.php?tab=upload
  follow-on: POST /wp-admin/update.php?action=upload-plugin
  follow-on: /wp-json/wp/v2/users?context=edit
  follow-on: admin-ajax.php with a traversal parameter aimed at wp-config

DATABASE
  wp_users rows with user_login prefix wp2_ | w2s_ | wpsvc_ and administrator role
  administrator accounts on email domains you do not own
  gaps in the wp_users ID sequence; orphaned wp_usermeta rows
  oEmbed cache rows in wp_options pointing at loopback

CAMPAIGN   wp2shell
CVES       CVE-2026-63030  REST API batch-route confusion   (CVSS 9.8 Tenable / 7.5 Rapid7)
           CVE-2026-60137  WP_Query author__not_in SQLi      (CVSS 5.9 Tenable)
DISCOVERY  Adam Kues, Assetnote (Searchlight Cyber), via the WordPress HackerOne programme
DISCLOSED  2026-07-17          EXPLOITED ITW  from 2026-07-17, confirmed by 2026-07-20
KEV        both CVEs added to CISA KEV 2026-07-21; remediation deadline 2026-07-24

VULNERABLE   6.8.0 - 6.8.5  SQL injection only
             6.9.0 - 6.9.4  full RCE chain
             7.0.0 - 7.0.1  full RCE chain
PATCHED      6.8.6 | 6.9.5 | 7.0.2 | 7.1 beta 2   (WordPress.org forced auto-updates)

ROOT CAUSE  The batch API validates and executes sub-requests in two separate loops.
            A failure in wp_parse_url() on one sub-request path is pushed to the
            validation array but not the matches array, desynchronising the two so
            every later sub-request dispatches under a different request's handler.

WEBSHELL FAMILIES OBSERVED
  1. one-liner PHP eval backdoor, returns HTTP 404 to casual probes
  2. ~150 KB obfuscated CMSmap-derived plugin: file manager, DB access,
     port scanner, MySQL UDF privilege escalation
  3. plugin registering a custom REST endpoint that accepts base64 commands via POST

CAVEAT  Sites backed by a persistent object cache (Redis / Memcached) may not be
        exploitable via this specific RCE path. The SQL injection still is.
        Do not treat an object cache as a mitigation.

# 1. Enumerate WordPress versions across the estate
find / -name version.php -path '*wp-includes*' 2>/dev/null \
  | while read -r f; do printf '%s ' "$f"; grep -m1 wp_version "$f"; done

# 2. With WP-CLI, per site root
wp core version --allow-root
wp core check-update --allow-root
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --allow-root
wp plugin list --fields=name,status,version --allow-root

# 3. Confirm the batch endpoint is actually blocked, both routing forms.
#    A 403 from the edge is the pass condition; 200 or 207 means still exposed.
curl -sk -o /dev/null -w '%{http_code} wp-json form\n'  https://SITE/wp-json/batch/v1
curl -sk -o /dev/null -w '%{http_code} rest_route form\n' 'https://SITE/?rest_route=/batch/v1'

# 4. Confirm PHP execution is denied where user content lands
curl -sk -o /dev/null -w '%{http_code} uploads\n' https://SITE/wp-content/uploads/probe.php

# 5. Falcon sensor coverage - every WordPress host must have one.
#    Any site on managed hosting with no sensor is an accepted, documented blind spot.

Provenance: every atomic indicator above (five IPv4 addresses, five SHA1 hashes) appears verbatim in the saved source snapshot 01-wiz.txt. The SHA256 row is a labelled placeholder because no SHA256 was published — it is deliberately not filled with a guess. Everything else in this appendix is a behavioural pattern or a configuration check, not an atomic claim.

P1 · Web-server configuration — block the batch endpoint, deny PHP in content directories

Apply on every reverse proxy and web server fronting WordPress, then reload. Test on one node before fleet rollout.

nginx

# /etc/nginx/snippets/wp2shell-mitigation.conf
# 1. Block the REST batch endpoint - BOTH routing forms.
location = /wp-json/batch/v1 { return 403; }
location ^~ /wp-json/batch/  { return 403; }

# The query-string routing form needs a map, since location does not match args.
# Place the map block in the http{} context:
#   map $arg_rest_route $wp2shell_batch { default 0; "~*^/batch/v1" 1; }
# then inside server{}:
if ($wp2shell_batch) { return 403; }

# 2. Deny PHP execution where user content and cache files land.
location ~* /wp-content/uploads/.*\.php$ { deny all; return 403; }
location ~* /wp-content/cache/.*\.php$   { deny all; return 403; }

# 3. Optional: block the three published exploitation user agents outright.
if ($http_user_agent ~* "(wp2shell|rezwp2shell|cve-2026-63030)") { return 403; }

Apache 2.4

# /etc/apache2/conf-available/wp2shell-mitigation.conf
<LocationMatch "^/wp-json/batch/v1">
    Require all denied
</LocationMatch>

# Query-string routing form
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)rest_route=/batch/v1 [NC]
RewriteRule .* - [F,L]

# Deny PHP execution in user-content directories
<DirectoryMatch "^/var/www/.*/wp-content/(uploads|cache)/">
    <FilesMatch "\.(php|phtml|php[0-9]|phar)$">
        Require all denied
    </FilesMatch>
</DirectoryMatch>

# Block the published exploitation user agents
RewriteCond %{HTTP_USER_AGENT} (wp2shell|rezwp2shell|cve-2026-63030) [NC]
RewriteRule .* - [F,L]

Verify: nginx -t or apachectl configtest, reload, then run probes 3 and 4 from the Section 10 audit block. Both batch forms must return 403 and the uploads probe must not execute.

P2 · WordPress configuration hardening

// Add to wp-config.php ABOVE the "That's all, stop editing" line.

// Block plugin/theme install and edit from the dashboard. This closes the
// upload-plugin path the campaign uses to install its webshell, even for an
// account that has already forged its way to administrator.
define( 'DISALLOW_FILE_MODS', true );
define( 'DISALLOW_FILE_EDIT', true );

// Keep core security updates flowing even with FILE_MODS locked down.
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Rotate every salt after a suspected compromise - this invalidates all
// existing sessions, including any the attacker holds.
// Generate fresh values at https://api.wordpress.org/secret-key/1.1/salt/

Verify: the Plugins and Themes screens should no longer offer Add New or the file editor. Confirm with wp plugin install hello-dolly --allow-root, which must fail.

P3 · Filesystem permissions — deny the PHP worker write access to the code tree

#!/usr/bin/env bash
# Run per site root. Assumes the PHP worker runs as www-data and a separate
# deploy account owns the code. Adjust names to your environment.
set -euo pipefail
SITE_ROOT="/var/www/example-site"     # <-- set this
DEPLOY_USER="deploy"
WEB_USER="www-data"

# Code tree owned by the deploy account, readable but NOT writable by PHP
chown -R "${DEPLOY_USER}:${WEB_USER}" "${SITE_ROOT}"
find "${SITE_ROOT}" -type d -exec chmod 750 {} +
find "${SITE_ROOT}" -type f -exec chmod 640 {} +

# Uploads is the one place PHP legitimately writes. H3 has already made it
# non-executable at the web-server layer, so a dropped .php cannot be reached.
chown -R "${WEB_USER}:${WEB_USER}" "${SITE_ROOT}/wp-content/uploads"
find "${SITE_ROOT}/wp-content/uploads" -type d -exec chmod 750 {} +

# wp-config.php holds the DB credentials and the auth salts - tighten it hard.
chmod 400 "${SITE_ROOT}/wp-config.php"
chown "${DEPLOY_USER}:${WEB_USER}" "${SITE_ROOT}/wp-config.php"
chmod 440 "${SITE_ROOT}/wp-config.php"

echo "Verify: sudo -u ${WEB_USER} touch ${SITE_ROOT}/wp-content/plugins/probe"
echo "        that command MUST fail with Permission denied."

Pilot this one. Plugins that write into their own directory at runtime will break. Roll to a single non-production site first, exercise the full plugin set, and keep the exception list explicit rather than reverting the whole control.

P4 · Triage collection script (read-only)

#!/usr/bin/env bash
# Read-only evidence collection for a suspected wp2shell compromise.
# Collects only - changes nothing. Run before any cleanup.
set -uo pipefail
SITE_ROOT="${1:-/var/www}"
OUT="/var/tmp/wp2shell-triage-$(hostname)-$(date +%Y%m%d%H%M%S)"
mkdir -p "$OUT"

echo "[*] WordPress versions"
find "$SITE_ROOT" -name version.php -path '*wp-includes*' \
  -exec grep -H -m1 wp_version {} + | tee "$OUT/versions.txt"

echo "[*] PHP files changed since the day before disclosure"
find "$SITE_ROOT" -name '*.php' -newermt '2026-07-16' \
  -printf '%T+ %s %p\n' | sort | tee "$OUT/recent-php.txt"

echo "[*] PHP where PHP should not be"
find "$SITE_ROOT" -path '*wp-content/uploads/*' -name '*.php' | tee "$OUT/php-in-uploads.txt"
find "$SITE_ROOT" -path '*wp-content/cache/*'   -name '*.php' | tee -a "$OUT/php-in-uploads.txt"

echo "[*] SHA1 of every PHP file - compare against the Section 10 hash list"
find "$SITE_ROOT" -name '*.php' -type f -exec sha1sum {} + | tee "$OUT/php-sha1.txt"

echo "[*] Shell-out primitives in PHP"
grep -rlE 'shell_exec|passthru|proc_open|popen|base64_decode\s*\(\s*\$' \
  "$SITE_ROOT" --include='*.php' | tee "$OUT/php-suspicious.txt"

echo "[*] Access-log hits"
grep -aEi 'batch/v1|rest_route=/batch/v1|wp2shell|rezwp2shell|cve-2026-63030' \
  /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
  | tee "$OUT/access-hits.txt"

echo "[*] Cron for the web user"
crontab -l -u www-data 2>/dev/null | tee "$OUT/webuser-cron.txt"

echo "[+] Collected to $OUT - preserve this before remediating."

Do not clean in place. Three distinct webshell families were reported, one of them a ~150 KB obfuscated plugin with a file manager and a MySQL UDF privilege-escalation module, and the exploit writes to the database as readily as to disk. Deleting the plugin directory you found is not eradication. Rebuild from a known-good artefact and restore only content, never code.

Honest read on this map. Four of the eleven attack-chain steps have no endpoint coverage at all, and that is a property of the threat rather than a shortfall in the queries: everything before the webshell executes happens inside HTTP request handling and inside the database, where an EDR sensor has no visibility. The pack is therefore strong from chain step 5 onward and blind before it. Two consequences follow. First, the web-log and database hunts in Section 7 are not optional garnish — they are the only coverage for the first half of the intrusion. Second, an estate that has centralised its HTTP logs will detect this campaign hours earlier than one relying on endpoint telemetry alone, which makes validation gate 6 the highest-leverage item in Section 11. Validation: gates 1 to 3 must pass before any result from this pack is trusted; gate 4 must complete before Q1, Q7 or Q8 are promoted to Detect.

The raw fetched text of every source above is saved in wp2shell-CVE-2026-63030-Hunt-sources/ next to this file. No source contained instructions aimed at an automated agent, and no source was disqualified. Nothing in this pack was written from memory.