GPT-5.6 Sol Ultra Found Critical WordPress wp2shell RCE for About $25

An OpenAI model helped uncover a critical WordPress Core vulnerability chain that attackers are now exploiting against unpatched websites. The chain, named wp2shell, allows an unauthenticated attacker to gain administrator access and execute code on affected WordPress installations without relying on a vulnerable plugin.

Searchlight Cyber researcher Adam Kues used GPT-5.6 Sol Ultra and a multi-agent prompt to audit WordPress source code. The researcher’s account of the AI-assisted discovery says the model first found a pre-authentication SQL injection and then developed a chain that escalated it to remote code execution.

Kues estimated the model cost at about $25 by prorating half of a $200 weekly usage allowance. He compared the finding with an exploit broker that advertised up to $500,000 for a WordPress pre-authentication RCE. Searchlight Cyber did not sell the vulnerability and instead disclosed it to WordPress for remediation.

WordPress has released emergency security updates

WordPress released patches on July 17, 2026, after Searchlight Cyber responsibly reported the RCE chain. The project assigned CVE-2026-63030 to the REST API batch-route confusion issue and linked it with CVE-2026-60137, a separate SQL injection vulnerability.

The official WordPress 7.0.2 security release classifies the update as addressing one critical issue and one high-severity issue. WordPress also enabled forced updates through its automatic update system because of the risk.

Administrators should verify their installed version manually. Automatic updates can fail because of file permissions, hosting restrictions, disabled background updates or a modified WordPress installation.

WordPress version	Exposure	Fixed version
Earlier than 6.8	Not affected by either reported vulnerability	No wp2shell-specific update required
6.8.0 through 6.8.5	CVE-2026-60137 SQL injection only	6.8.6
6.9.0 through 6.9.4	Full pre-authentication RCE chain	6.9.5
7.0.0 through 7.0.1	Full pre-authentication RCE chain	7.0.2
7.1 Beta 1	Affected by both vulnerabilities	7.1 Beta 2

Two WordPress Core vulnerabilities form wp2shell

Wp2shell combines two weaknesses rather than relying on a single coding error. CVE-2026-63030 causes confusion between validation results and REST API route handlers. CVE-2026-60137 allows SQL injection through the author__not_in value used internally by WP_Query.

The official WordPress security advisory lists CVE-2026-63030 as critical. It affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1, with fixes included in versions 6.9.5 and 7.0.2.

The SQL injection appeared one branch earlier, in WordPress 6.8. However, WordPress 6.8 does not contain the batch-route confusion required for the complete unauthenticated RCE chain.

Vulnerability	Component	Role in the chain
CVE-2026-63030	REST API Batch endpoint	Confuses validated requests with different route handlers
CVE-2026-60137	WP_Query author__not_in handling	Allows an unsanitized scalar value to reach an SQL query
Combined result	WordPress Core	Pre-authentication SQL injection followed by administrator access and RCE

How GPT-5.6 Sol Ultra found the vulnerability

Kues cloned the latest stable WordPress source into a local directory and removed its Git history. The prompt also prohibited using change logs or searching for differences between vulnerable and patched code.

The model could coordinate up to four agents at once and had instructions to continue for at least six hours. Agents explored different vulnerability classes, challenged promising findings and redirected effort when an approach failed.

After the model reported a pre-authentication SQL injection, Kues tested it against a stock WordPress installation. The exploit retrieved the administrator email address from the database. He then asked the model to find a path from the read-only injection to code execution, which took approximately another four hours.

The Batch API validates one request and executes another

WordPress introduced its REST API Batch endpoint in version 5.6. The endpoint lets a client place several virtual REST requests inside one HTTP request.

During batch processing, WordPress stores matched route handlers in one array and validation results in another. An error-handling branch adds an entry to the validation array but skips the corresponding handler entry.

This causes the arrays to become misaligned. A later request can pass validation under one route’s rules but execute through the handler selected for another route. The result is a general bypass of parameter sanitization for batch-enabled endpoints.

A nested batch request reaches the SQL injection

The WordPress posts endpoint accepts a public author_exclude parameter, which normally must contain an array of integer user IDs. WordPress then maps this value to the internal author__not_in query variable.

WP_Query sanitizes author__not_in when it receives an array. If it receives a scalar value instead, the vulnerable versions can insert that value into an SQL query without the expected integer conversion.

The REST API normally prevents this because author_exclude must pass schema validation. The batch-route confusion makes it possible to validate the parameter against an unrelated handler and then execute it through the posts endpoint.

A second obstacle remained because the vulnerable query uses a GET route, while the Batch API normally permits only POST, PUT, PATCH and DELETE subrequests. The model solved this by nesting one batch request inside another, using the same validation mismatch to bypass method restrictions.

The SQL injection becomes an administrator takeover

Reading the database did not immediately provide administrator access because WordPress stores passwords and reset credentials as hashes. The model instead found a chain involving WordPress’s in-memory post cache and database-backed oEmbed cache records.

The SQL injection could return fabricated post objects that WordPress stored in its request-level cache. The oEmbed system then provided a way to create real wp_posts database rows associated with attacker-selected post IDs.

By making the in-memory version of a post differ from the database version, the exploit could influence fields preserved when WordPress updated the row. This allowed the chain to convert an oEmbed cache entry into a specially constructed customize_changeset object.

A forged changeset temporarily gains administrator authority

WordPress customize changesets store configuration changes that can run under the authority of a specified user. The exploit created changeset data associated with an existing administrator ID.

A deliberately corrupted post-parent relationship triggered WordPress’s cycle-repair logic. During that update, WordPress treated the cached object as a valid changeset and temporarily applied its operations with administrator privileges.

The temporary privilege window did not last beyond the changeset operation. The exploit therefore needed another mechanism to replay an attacker-controlled request while WordPress still treated the action as authorized.

The parse_request hook replays the malicious request

WordPress hooks allow themes, plugins and Core components to execute functions at different points in the request lifecycle. The model identified parse_request as a useful target because WordPress calls it near the beginning of request processing.

A crafted post status and type combination caused WordPress to invoke the parse_request action while processing the malicious changeset. This replayed the batch request while temporary administrator privileges remained active.

During the replay, the attacker could create a new administrator account. Administrator access then allowed the installation of a malicious plugin, providing arbitrary PHP execution on the server.

The full Searchlight Cyber technical analysis credits the model with developing the chain, while Kues validated it, untangled its behavior and prepared the responsible disclosure.

Researchers reproduced the complete exploit

Searchlight Cyber initially withheld technical details to give WordPress administrators time to install the security release. During that period, independent researchers known as Calif and Hacktron reproduced the full RCE chain.

Public proof-of-concept code appeared shortly afterward. This sharply reduced the time available for defenders because attackers no longer needed to reconstruct the chain independently from the patch or advisory.

WordPress’s wp2shell advisory now provides the affected and patched versions but does not require administrators to reproduce the exploit. Checking the Core version offers the safest way to determine whether a site needs the update.

Attackers are exploiting wp2shell in the wild

Wp2shell has moved beyond a theoretical vulnerability. Wiz Research reported active exploitation against self-hosted WordPress installations in cloud environments.

Researchers observed successful access to WordPress administration pages, malicious plugin uploads, user enumeration and attempts to retrieve wp-config.php data. Attackers also deployed persistent PHP webshells, including one disguised as a WordPress plugin.

High-volume scanning has targeted vulnerable Batch API endpoints. Some traffic only checked for exposure, while other requests progressed to plugin installation and persistent server access.

• Malicious WordPress plugin uploads
• New or modified administrator accounts
• PHP webshells in plugin and upload directories
• Requests for editable user records
• Attempts to retrieve wp-config.php
• Unexpected successful sessions in wp-admin
• Repeated Batch API requests returning successful responses

Updating WordPress may not remove an existing webshell

Installing the security release prevents new exploitation through the patched chain. It does not delete malicious plugins, administrator accounts or PHP files that attackers placed on the server before the update.

Administrators running an affected version should treat unexplained changes as a possible compromise. They should compare WordPress Core files with clean copies, inspect installed plugins and themes, review user accounts and search writable directories for unfamiliar PHP files.

Credentials stored in wp-config.php may also require rotation if attackers accessed the file system. This includes database passwords, WordPress authentication salts, hosting credentials and any API keys stored in the site configuration.

How to detect wp2shell exploitation

The exploit targets the WordPress REST API Batch endpoint through either the standard wp-json route or the rest_route query-string form. Security teams should review web server, reverse proxy and WAF logs for unusual POST requests to both variations.

The Wiz investigation identified HTTP 200 and 207 responses to suspicious Batch API requests as useful indicators of possible success. Researchers also observed purpose-built tools using wp2shell and rezwp2shell in their user-agent strings.

Defenders should correlate Batch API traffic with subsequent administrator sessions, plugin uploads, REST user enumeration and new PHP files. A single log entry may not prove exploitation, but the sequence can reveal a successful compromise.

What WordPress administrators should do now

1. Check the exact WordPress Core version installed on every site.
2. Update WordPress 6.8 sites to at least 6.8.6.
3. Update WordPress 6.9 sites to at least 6.9.5.
4. Update WordPress 7.0 sites to at least 7.0.2.
5. Inspect administrator accounts and remove any unauthorized users.
6. Review plugins, themes and writable directories for unfamiliar PHP files.
7. Search web logs for suspicious Batch API requests and successful 200 or 207 responses.
8. Rotate database credentials, authentication salts and hosting credentials if compromise is suspected.
9. Restore from a verified clean backup or rebuild the site if investigators confirm server-level access.

The official WordPress security announcement recommends updating immediately. Site owners should confirm the installed version instead of assuming the forced automatic update completed.

If an immediate update is impossible, administrators can temporarily block anonymous requests to both Batch API route formats at the WAF. This measure may disrupt legitimate integrations and should only serve as an emergency measure until the site receives the patch.

Searchlight Cyber provides a wp2shell checker

Searchlight Cyber has published a hosted wp2shell checker that tests whether a WordPress site appears vulnerable. Administrators should only scan websites they own or have permission to test.

A non-vulnerable result does not prove that attackers never exploited the site. The checker evaluates current exposure, while incident-response work must determine whether malicious accounts, plugins or files already exist.

Site owners can use the Searchlight Cyber vulnerability checker alongside manual version verification and log review. Applying the vendor update remains the primary fix.

FAQ