CVE-2026-63030 wp2shell: WordPress Core Pre-Auth RCE Exploited

This week in our InSEKurity of the Week series: wp2shell, a pre-authentication remote code execution chain in WordPress Core itself — not a plugin, not a theme, not an exotic configuration. Two separately tracked bugs combine into one attack: CVE-2026-63030, a route confusion flaw in the REST API batch endpoint (/wp-json/batch/v1), and CVE-2026-60137, a SQL injection in the author__not_in parameter of WP_Query, WordPress’s central database query builder. Alone, each is limited — the SQL injection normally only surfaces when a plugin passes untrusted input into that parameter, and the batch confusion by itself grants little. Chained, they let an anonymous attacker on the internet reach code execution on a stock WordPress installation with no plugins installed. WordPress shipped emergency fixes on July 17, 2026; Wordfence saw the first probing the same day and SQL injection attempts thirteen minutes later. By July 21 both CVEs were in CISA’s Known Exploited Vulnerabilities catalog — the first WordPress Core entries the catalog has ever carried. With WordPress running roughly 41.5% of all websites and close to 60% of everything built on a CMS, this is one of the largest addressable attack surfaces a single bug class has touched in years. If you run WordPress, the only question that matters right now is which version number your site reports.

🚨 Summary

CVE IDs: CVE-2026-63030 (REST API batch-route confusion — the unauthenticated entry point) and CVE-2026-60137 (SQL injection — the payload delivery step). Together they are publicly known as wp2shell.
CVSS 3.1 Score: CVE-2026-63030 — 9.8 Critical per WPScan (the CNA), AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H; CISA-ADP scores the same CVE 7.5 High. CVE-2026-60137 — 5.9 Medium per WPScan (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N), but 9.1 Critical per CISA-ADP. The chain is what matters: unauthenticated RCE, effectively 9.8.
CWE: CWE-436 (Interpretation Conflict) for CVE-2026-63030; CWE-89 (SQL Injection) for CVE-2026-60137
Affected Software: WordPress Core — full RCE chain on 6.9.0–6.9.4 and 7.0.0–7.0.1; SQL injection only on 6.8.0–6.8.5. Versions before 6.8 are not affected.
Attack Vector: Network — a single HTTP POST to the REST API batch endpoint, which has shipped enabled by default since WordPress 5.6
Authentication Required: None. No user interaction, no plugins, no special configuration.
Impact: Unauthenticated remote code execution — webshell deployment, rogue administrator account creation, full site and often full web-server takeover
Patch Status: ✅ Available — 7.0.2, 6.9.5, 6.8.6, and 7.1 beta2, all released July 17, 2026. WordPress.org has forced automatic background security updates for affected installations.
Published: July 17, 2026 (WordPress security release, GitHub Security Advisories GHSA-ff9f-jf42-662q and GHSA-fpp7-x2x2-2mjf)
Exploitation Status: 🔴 Actively exploited. Probing began the day of disclosure; public PoCs circulated within days; SANS ISC has published captured in-the-wild payloads.
CISA KEV: ✅ Listed — CVE-2026-63030 added July 21, 2026 (federal deadline July 24, 2026), CVE-2026-60137 added with a deadline of August 4, 2026, under BOD 26-04

🖥️ What is WordPress Core?

WordPress is the world’s most widely deployed content management system. “WordPress Core” means the base platform itself — the PHP application you download from wordpress.org — as distinct from the roughly 60,000 plugins and thousands of themes built on top of it. That distinction is the whole story here. The overwhelming majority of WordPress CVEs live in third-party plugins, which means the standard advice (“audit your plugins, remove what you do not use”) usually works. wp2shell is different: the vulnerable code is in Core, so a hardened, minimal, plugin-free installation is just as exploitable as a bloated one.

The specific component at fault is the REST API, which WordPress has shipped enabled by default since version 4.7, and its batch endpoint (/wp-json/batch/v1), added in version 5.6. The batch endpoint exists so a client can bundle several API calls into a single HTTP request — useful for the block editor, headless front-ends, and mobile apps that would otherwise make a dozen round trips. It is reachable anonymously by design, because plenty of legitimate REST routes are public.

Scale is what turns a Core bug into an internet-wide event. As of July 2026 W3Techs puts WordPress at roughly 41.5% of all websites and 59.9% of sites running a known CMS — more than every other CMS combined. Estimates of the absolute number of WordPress sites run into the hundreds of millions. A pre-authentication RCE in Core is therefore not a vendor problem confined to one industry; it is a problem for corporate marketing sites, e-commerce shops, government portals, university departments, and the long tail of small-business sites nobody has logged into in three years.

Typical Use Cases

Corporate websites and marketing presence: the public face of the organization, frequently hosted adjacent to other infrastructure.
E-commerce: WooCommerce and similar stacks handle payment flows and customer PII.
Publishing and media: high-traffic editorial sites with many contributor accounts.
Headless CMS / API back-end: the REST API serves content to mobile apps and JavaScript front-ends — exactly the use case the batch endpoint was built for.
Intranets and membership portals: internal or gated sites that assume authentication protects them.

🔍 Technical Analysis

Vulnerability Description

wp2shell is a two-bug chain, and understanding why neither bug is sufficient alone is the key to understanding the flaw.

CVE-2026-60137 is a SQL injection in WP_Query, the class nearly every WordPress query passes through. The author__not_in query variable is meant to receive an array of user IDs to exclude. The sanitization code only fires when the value actually is an array — the implementation is guarded by a check equivalent to if ( is_array( $query_vars['author__not_in'] ) ). If a scalar string reaches that parameter instead, it slips past sanitization entirely and lands in the generated SQL. Under normal conditions this is a “medium” bug: the REST API’s schema validation enforces the array type, so only a plugin or theme carelessly passing raw user input into WP_Query could trigger it. That is why WPScan scored it 5.9.

CVE-2026-63030 is what removes that guard rail. WP_REST_Server::serve_batch_request_v1() processes a batch in two separate passes: first it validates every sub-request, then it dispatches them. It tracks the sub-requests across parallel arrays — the requests themselves, their route $matches (the resolved handler and its parameters), and the $validation results — and relies on those arrays staying index-aligned. When a sub-request path fails to parse (wp_parse_url() returns a failure), the error is appended to the validation array but no corresponding placeholder is added to the matches array. From that point on the arrays are off by one, and every subsequent sub-request is dispatched under a different sub-request’s handler.

That desynchronization is the exploit primitive. An attacker deliberately includes one malformed sub-request to shift the index, and their real payload then executes against a handler whose schema validation belongs to a different route. The type constraint that would have forced author_exclude (the REST parameter that maps to author__not_in) to be an array is no longer applied to it. A scalar, attacker-controlled string reaches WP_Query uncleaned — and the “medium” SQL injection becomes an unauthenticated SQL injection on a default install.

Root Cause Analysis

Type-conditional sanitization (CWE-89): WP_Query sanitizes author__not_in only when the value is already an array. A scalar string is passed through untouched instead of being rejected or coerced. Sanitization that is optional on the input’s shape is sanitization an attacker can shape their way around.
Parallel arrays as an implicit contract (CWE-436): serve_batch_request_v1() keeps request data in several separate arrays and assumes their indices correspond. Nothing in the code structure enforces that assumption — it is maintained only by every code path remembering to push to all arrays.
Error path that skips one array: the failure branch for an unparseable sub-request path appends to $validation without adding a placeholder to $matches. A single missing push in an error handler is the entire root cause of the route confusion.
Validation decoupled from dispatch: because validation happens in one loop and dispatch in another, the “this input was validated” decision is made in a different place from where the input is used. The desync lets a request carry another request’s validation verdict.
Anonymous reachability by design: the batch endpoint accepts unauthenticated requests because many REST routes are public. That is defensible in isolation, but it means the routing layer is directly exposed to anonymous attacker input.
Default-on attack surface: the REST API (since 4.7) and the batch endpoint (since 5.6) are enabled out of the box, so the vulnerable code path is present on essentially every modern installation.

Attack Vector

The diagram below shows the shape of the chain for defenders. It is a conceptual data-flow description, not a functional exploit.

# Illustrative attack chain -- NOT a functional exploit. For defenders only.

Anonymous attacker (no credentials, no account)
      |
      | (1) POST a batch request to /wp-json/batch/v1 (or ?rest_route=/batch/v1)
      |     containing several sub-requests. One sub-request carries a
      |     deliberately malformed path so wp_parse_url() fails on it.
      v
WP_REST_Server::serve_batch_request_v1()
      |
      |     validation loop: error pushed to $validation,
      |     but NO placeholder pushed to $matches  ->  arrays now off by one
      v
Dispatch loop runs each sub-request under the WRONG handler
      |
      | (2) CVE-2026-60137: the attacker's author_exclude value is no longer
      |     schema-checked as an array. A scalar string reaches WP_Query.
      v
Unsanitized string concatenated into the SQL query  ->  SQL injection
      |
      | (3) Escalate from database read to code execution
      |     (see "From SQL Injection to Code Execution" below)
      v
Webshell on disk and/or rogue administrator account  ->  full site takeover

From SQL Injection to Code Execution

Two distinct escalation routes have been documented, and defenders should hunt for both.

Route A — the researcher’s chain (object poisoning). The original Searchlight Cyber research, as analysed publicly by Picus Security, does not rely on writing files through MySQL at all. Instead the injection is used to control the fields of a cached WP_Post object; an oEmbed write path forces the poisoned object back into the database; a Customizer changeset save briefly runs in an elevated context, and a nested REST loader save re-evaluates a previously rejected user-creation request as an administrator. The result is an attacker-controlled administrator account — after which installing a plugin is a supported feature, and code execution follows trivially. This route needs no FILE privilege on the database user.

Route B — what attackers actually fired (webshell drop). The payloads SANS ISC captured in the wild take the blunter path. Attackers POST to /?rest_route=/batch/v1 with Content-Type: application/json and — helpfully for defenders — the User-Agent string cve-2026-63030/1.0. They first send a UNION-based probe whose injected query returns the marker string ||OK|| to confirm the target is exploitable, then follow up with a payload that uses INTO OUTFILE to write a PHP webshell into the cache directory, observed at /var/www/wp-content/cache/94uh9ubh6e1x.php. The webshell authenticates via a p parameter matching its own filename token, accepts commands in b (base64-encoded) or c (raw), wraps output between [S] and [E] markers, and tries system(), passthru(), exec(), shell_exec() and popen() in turn. New administrator accounts were also written directly into the database.

One nuance worth noting for triage: Rapid7’s analysis observes the chain depends on a persistent object cache being disabled — which is the default state of a stock WordPress install. Sites fronted by Redis or Memcached object caching may not be exploitable via that path, but this is not a mitigation you should rely on and does not affect the SQL injection itself.

Exploitation in the Wild

Same-day exploitation. WordPress published the fixes on July 17, 2026. Wordfence documented probing on July 17 and the first SQL injection attempts thirteen minutes later — effectively no patch window at all.
PoCs within hours. Public proof-of-concept exploits appeared within a day of disclosure, with several commentators noting they were assembled rapidly with AI coding assistants, compressing the traditional exploit-development lag.
Opportunistic, not targeted. Observed activity is broad internet-wide scanning across all industries and regions, consistent with mass exploitation rather than a specific victim set.
A first for the KEV catalog. CISA added both CVEs on July 21, 2026 — the first time WordPress Core, rather than a WordPress plugin, has appeared in the Known Exploited Vulnerabilities catalog.
Researcher restraint did not help much. Searchlight Cyber deliberately withheld technical detail at disclosure and published a free scanner instead. Attackers reverse-engineered the patch anyway; full details were public by July 22.

Post-Exploitation Impact

Arbitrary code execution as the web-server user: a webshell running as www-data/apache can read every file that user can read — including wp-config.php and its database credentials.
Full database access: content, user tables, password hashes, and on e-commerce sites customer and order data.
Rogue administrator accounts: persistent legitimate-looking access that survives removing the webshell.
Supply-chain style visitor compromise: injected skimmers, SEO spam, or malicious redirects served to every visitor of a trusted domain.
Lateral movement on shared hosting: one compromised site frequently means access to sibling sites under the same account or server.
Credential reuse: database and SMTP credentials from wp-config.php are routinely reused elsewhere in the environment.
Persistence beyond the patch: an attacker who landed a webshell or an admin account before you updated is still there after you update.

⚠️ Impact Assessment

Immediate Impact

Unauthenticated internet-to-RCE: no credentials, no user interaction, no plugin prerequisite.
Default installations are vulnerable: the “we keep it minimal” hardening posture does not help here.
The exposed population is enormous: roughly 41.5% of all websites run WordPress, and patch adoption across that long tail is historically slow.
Exploitation preceded meaningful patching: attacks started the same day the fix shipped.
Patching does not undo a prior compromise: webshells and rogue admins persist across updates.

Affected Versions

WordPress branch	Vulnerable versions	Fixed version	Exposure
7.0.x	7.0.0 – 7.0.1	7.0.2	Full RCE chain (both CVEs)
6.9.x	6.9.0 – 6.9.4	6.9.5	Full RCE chain (both CVEs)
6.8.x	6.8.0 – 6.8.5	6.8.6	SQL injection only (CVE-2026-60137)
7.1 beta	7.1 beta1	7.1 beta2	Full RCE chain (both CVEs)
Before 6.8	—	—	Not affected by these CVEs

Versions before 6.8 are not affected by wp2shell, but they are almost certainly affected by plenty of older, already-public vulnerabilities. “Too old to be vulnerable to this” is not a security posture.

Affected Environments

Any internet-facing WordPress site on 6.9.x or 7.0.x below the fixed builds — the default configuration is the vulnerable configuration.
Sites with automatic updates disabled: agencies, managed hosts, and enterprises that pin Core versions for stability are exactly the population still exposed.
Headless and API-driven deployments: the REST API is not merely enabled but actively used, and the batch endpoint may be explicitly whitelisted at the WAF.
Neglected and forgotten sites: campaign microsites, old landing pages, and departmental blogs nobody owns — the classic shadow-IT footprint.
Shared hosting tenants: one vulnerable neighbour can become everyone’s problem.

Attacker Profiles

Mass-exploitation crews: an unauthenticated Core RCE against 40% of the web is the ideal input for automated, scaled compromise — webshells at volume, monetized later.
SEO spam and malvertising operators: hijacked authority domains are directly monetizable.
Skimmer groups: WooCommerce checkout pages are a payment-data goldmine.
Initial-access brokers: a webshell on a corporate marketing site is a saleable foothold, particularly where that site shares infrastructure or credentials with more valuable systems.
Botnet operators: web-server code execution at this scale is raw capacity for DDoS, proxying, and further scanning.

🛡️ Mitigation Strategies

Immediate Actions (Priority 1) ⚡

Confirm the version every site actually reports. Do not trust an inventory spreadsheet. Using WP-CLI on the host:

# Print the exact WordPress core version (and DB revision) for this install.
# Compare against the fixed builds: 7.0.2, 6.9.5, or 6.8.6.
wp core version --extra

For sites you can only reach over HTTP, WordPress exposes its version in the generator meta tag by default (note: many hardening plugins remove it, so absence proves nothing):

# Read the WordPress version from the public generator meta tag.
# -s silences the progress meter; grep pulls the generator line out of the HTML.
curl -s https://example.com/ | grep -i 'name="generator"'

Update to a fixed release immediately. This is the only real remediation. Per the WordPress 7.0.2 security release:
```
# Update WordPress core to the patched release for your branch.
# Use the version that matches your branch: 7.0.2, 6.9.5, or 6.8.6.
wp core update --version=7.0.2

# Alternative: stay on your current major branch and take only the
# minor (security) release -- e.g. 6.9.4 -> 6.9.5.
wp core update --minor
```
WordPress.org has enabled forced automatic background updates for affected installations, so many sites will already have been patched without operator action — but you must verify rather than assume, and sites with WP_AUTO_UPDATE_CORE disabled will not have received it.
Block the batch endpoint at the WAF — as a stopgap only. If you genuinely cannot update within the hour, Searchlight Cyber and Tenable recommend blocking both access paths to the endpoint, because either form reaches the same code:
- /wp-json/batch/v1
- /?rest_route=/batch/v1
Blocking one and not the other is the most common mistake here. This buys time; it is not a fix, and it may break the block editor or a headless front-end.
Assume compromise on any site that was exposed and unpatched after July 17. Given that exploitation began within thirteen minutes of the release, an internet-facing site that stayed on a vulnerable build for days should be treated as potentially breached until the checks below come back clean.

Detection Measures 🔍

Verify Core files have not been tampered with. This compares every Core file against WordPress.org’s official checksums and is the single highest-value check available:

# Verify all core files against WordPress.org checksums and flag any
# non-WordPress files sitting in the installation root.
wp core verify-checksums --include-root

Hunt for the in-the-wild exploitation signature in web-server logs. The captured payloads used a distinctive User-Agent, and any anonymous POST to the batch endpoint deserves scrutiny:

# 1) The observed in-the-wild User-Agent string for this exploit.
#    Adjust the log path: Debian/Ubuntu nginx shown; use
#    /var/log/apache2/access.log (Debian) or /var/log/httpd/access_log (RHEL).
grep -F 'cve-2026-63030/1.0' /var/log/nginx/access.log

# 2) Any request touching the batch endpoint, in either of its two forms.
grep -E 'batch/v1|rest_route=/batch/v1' /var/log/nginx/access.log

# 3) SQL injection markers in request lines: UNION SELECT and the
#    ||OK|| probe marker reported by SANS ISC. -i ignores case;
#    the pipe characters are bracketed so they stay literal in ERE.
grep -E -i 'union[[:space:]]+select|[|][|]OK[|][|]' /var/log/nginx/access.log

Look for dropped webshells. The observed payload wrote PHP into the cache directory, which should normally contain no executable PHP that you did not put there:

# List PHP files under wp-content modified since the disclosure date.
# -newermt takes a date string; adjust it to before your last known-good state.
find wp-content -name '*.php' -newermt '2026-07-16' -ls

# The observed drop location was the cache directory. Any PHP here is suspect.
find wp-content/cache -name '*.php' -ls

Check for rogue administrator accounts. Both escalation routes end in an attacker-controlled admin:

# List every administrator with registration date, newest last.
# Scrutinise any account you cannot account for.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Additional hunting:

Review installed plugins for anything you did not install — Route A ends with the attacker uploading a plugin as the code-execution step. wp plugin list --status=active gives you the current set.
Search for webshell response markers ([S] / [E]) and the p/b/c parameter pattern in POST bodies if your WAF or proxy logs request bodies.
Alert on POST requests to batch/v1 from unauthenticated sessions in your SIEM. In Splunk-style SPL against combined access logs:
```
index=web sourcetype=access_combined method=POST uri="*batch/v1*"
| stats count by clientip, useragent
| sort - count
```
Rotate every secret in wp-config.php on any site you suspect was reached: database credentials, the authentication salts/keys, and any SMTP or API credentials stored there.

Long-term Security Improvements

Leave automatic Core security updates enabled. WordPress’s auto-update mechanism is the single reason this event was not far worse. If you disable it for change-management reasons, you have taken on the obligation to patch faster than thirteen minutes — which you cannot.
Maintain a real inventory of WordPress instances. You cannot patch the marketing microsite you forgot exists. Discovery of internet-facing CMS instances belongs in your asset management, not in someone’s memory.
Restrict the REST API where you do not need it. If a site is not headless and does not use the block editor remotely, limiting anonymous REST access reduces a large default attack surface.
Do not treat “Core is safe, plugins are risky” as an axiom. This event is the counterexample. Core deserves the same patch SLA as everything else.
Segment and de-privilege the web server. The PHP process should not be able to write to its own code directories in production, should not hold reusable credentials for other systems, and should not sit on a flat network with anything valuable.
File integrity monitoring on web roots. wp core verify-checksums is a manual snapshot; continuous FIM catches the webshell that lands at 3am.
Ship web-server logs off-host. Detection that depends on logs stored on the compromised machine is detection an attacker can delete.

🎯 Why is this Critical?

It is in Core, not a plugin: the usual mitigation of running a lean, well-audited plugin set provides no protection whatsoever.
Unauthenticated and interaction-free: one HTTP POST from anywhere on the internet, against a default install.
The exposed population is roughly 41.5% of the web: few vulnerabilities have ever had an addressable surface this large.
Exploitation started thirteen minutes after the fix shipped: the practical patch window was zero.
A WordPress Core first for CISA KEV: the catalog has carried WordPress plugin bugs before; never Core.
The endpoint has been present since WordPress 5.6: the vulnerable route has been quietly exposed on installations for years.
Two “medium” bugs made one critical one: a 5.9 SQL injection plus a routing quirk equals unauthenticated RCE — a reminder that severity scores of individual findings routinely understate chained risk.
Patching does not evict an attacker who already succeeded: remediation and incident response are separate tasks here.

🚀 Timeline and Disclosure

Prior to July 2026 — Adam Kues of Assetnote / Searchlight Cyber discovers the REST API batch-route confusion and reports it through WordPress’s HackerOne program. Independently, TF1T, dtro, and haongo report the WP_Query SQL injection.
2026-07-17 — WordPress ships the coordinated security release: 7.0.2, 6.9.5, 6.8.6, and 7.1 beta2. GitHub Security Advisories GHSA-ff9f-jf42-662q (CVE-2026-63030) and GHSA-fpp7-x2x2-2mjf (CVE-2026-60137) are published. Searchlight Cyber publishes a high-level write-up under the name wp2shell, deliberately withholding technical detail, plus a free scanner at wp2shell.com.
2026-07-17 (same day) — Wordfence documents probing, followed by the first SQL injection attempts thirteen minutes later.
2026-07-20 — SANS ISC publishes captured in-the-wild payloads, including the cve-2026-63030/1.0 User-Agent, the ||OK|| probe marker, and the INTO OUTFILE webshell drop. Detailed third-party technical breakdowns begin appearing.
2026-07-21 — CISA adds both CVEs to the KEV catalog, with a federal remediation deadline of July 24 for CVE-2026-63030 and August 4 for CVE-2026-60137 under BOD 26-04. WordPress.org enables forced automatic security updates for affected installations.
2026-07-22 — Full technical detail is public; multiple working proof-of-concept exploits circulate; active mass exploitation is confirmed by several vendors.
CW30 (July 20-26, 2026) — Sustained coverage and exploitation across Rapid7, Tenable, Horizon3.ai, Greenbone, Picus, SANS ISC, and The Hacker News.

🔗 Resources and References

CVE: CVE-2026-63030 (batch-route confusion) · CVE-2026-60137 (SQL injection)
NVD: NVD — CVE-2026-63030 · NVD — CVE-2026-60137
Vendor advisory: WordPress 7.0.2 Security Release · GHSA-ff9f-jf42-662q
Original research: wp2shell: Pre Authentication RCE in WordPress Core — Searchlight Cyber
CWE: CWE-436: Interpretation Conflict · CWE-89: SQL Injection
CISA KEV Catalog: Known Exploited Vulnerabilities (both CVEs added 2026-07-21)
WP-CLI documentation: wp core version · wp core update · wp core verify-checksums · wp user list

💼 SEKurity Supports You

wp2shell is a lesson in where risk actually lives. Every hardening guide tells you the danger is in plugins, so teams audit plugins — and then a routing quirk and a type-check in Core turn a stock, plugin-free installation into a webshell host. It is also a lesson in chaining: a 5.9-rated SQL injection that “only matters if a plugin misuses it” became an unauthenticated RCE the moment a second, unremarkable bug removed the validation standing in front of it. Neither finding would have topped a report on its own; together they are the most widely exploitable web vulnerability of the year. That gap — between how findings score individually and what an attacker can build from them — is precisely what a real adversary simulation exposes and a checklist scan does not. We help organizations inventory the internet-facing CMS instances they have forgotten about, verify that emergency patch processes actually work under a zero-day patch window, and determine whether a compromised web server would be detected at all — let alone contained before it became a pivot into everything else.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

🌐 Website: www.sekurity.de

📧 Inquiries: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your web applications is our drive.

InSEKurity of the Week (CW30/2026): WordPress Core wp2shell Pre-Auth RCE (CVE-2026-63030 & CVE-2026-60137)