AI Found a WordPress RCE for 5 — But the Real Cost Wasn’t the Compute + Video

Listen to this Post

Featured Image

Introduction:

When Searchlight Cyber researcher Adam Kues tasked OpenAI’s GPT-5.6 Sol Ultra with auditing a local copy of the WordPress source code, the model uncovered a pre-authentication remote code execution (RCE) chain in just over 10 hours at an estimated cost of roughly $25. The vulnerability, now tracked as CVE-2026-63030 (chained with CVE-2026-60137), allows an unauthenticated attacker to execute arbitrary code on a default WordPress installation — no plugins, no special configuration, and no credentials required. But the $25 headline tells only a fraction of the story. The expensive part wasn’t discovering the flaw; it was verifying the exploit, understanding the attack chain, coordinating responsible disclosure, and ensuring a reliable fix. This case doesn’t show that AI can independently replace a security researcher — it shows that automated discovery can increase the number of credible findings faster than organizations can validate and fix them.

Learning Objectives:

  • Understand the technical mechanics of CVE-2026-63030 and CVE-2026-60137, including the REST API batch route confusion and SQL injection chain.
  • Learn how AI-assisted vulnerability discovery changes the economics of security research and why human verification remains irreplaceable.
  • Gain actionable steps to detect, patch, and remediate the wp2shell vulnerability across WordPress deployments.

You Should Know:

  1. The Attack Chain: From Batch Route Confusion to Remote Code Execution

The vulnerability chain begins with a logic bug in WordPress’s REST API batch processing endpoint, exposed at /wp-json/wp/v2/batch. This endpoint, introduced in WordPress 5.6, allows users to make multiple virtual API requests in a single HTTP request. Under a particular malformed request, the validation results and matched route handlers can move out of alignment, allowing input validated for one route to reach another route. This route confusion eventually exposes a SQL injection vulnerability in the `WP_Query` class when the `author__not_in` parameter receives a string rather than an array — the `is_array()` sanitization guard is skipped and the raw value is interpolated into a `NOT IN (…)` clause.

From that read-only SQL injection, GPT-5.6 then found a longer post-exploitation path that used WordPress caching and customization behavior to reach administrator privileges and remote code execution. The full chain works as follows:

  1. Route Confusion (CVE-2026-63030): An unauthenticated attacker sends a malformed batch request that desynchronizes validation results from route handlers.
  2. SQL Injection (CVE-2026-60137): The confusion allows attacker-controlled input to reach `WP_Query` with a string value in author__not_in, leading to arbitrary SQL execution.
  3. Privilege Escalation: The SQL injection is used to create a new administrator user or extract password hashes.
  4. Remote Code Execution: The attacker logs in as the new admin, uploads a minimal plugin that executes system commands via shell_exec(), achieving full RCE.

Step‑by‑Step: Detecting wp2shell Exposure

For authorized security testing on systems you own or administer, you can use the following approaches:

Option 1 — Using the wp2shell.com Scanner:

Searchlight Cyber launched wp2shell.com, a tool that site owners can use to check whether an installation is vulnerable. Simply visit the URL and enter your WordPress site’s domain for a non-intrusive exposure check.

Option 2 — Using Community Scanners (Linux/macOS):

 Clone a detection tool (authorized use only)
git clone https://github.com/bahartanir/wp2shell-scanner.git
cd wp2shell-scanner

Run the scanner against your target (replace TARGET_URL with your site)
python3 scanner.py -t https://your-wordpress-site.com

Option 3 — Manual Version Check (Linux/macOS/Windows via WP-CLI):

 Check WordPress version via WP-CLI
wp core version

If WP-CLI is not available, check the version.php file
curl -s https://your-wordpress-site.com/wp-includes/version.php | grep '$wp_version'

Affected versions are WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. The fixes are in 6.9.5, 6.8.6, and 7.0.2.

  1. Verifying the Exploit: The Human Effort Behind the $25 Headline

GPT-5.6 Sol Ultra produced the full exploit chain in just over 10 hours, with the final four hours dedicated to the RCE-escalation step after Kues had already verified the SQL injection. But the model’s output was not accepted on its word. Kues tested the SQL injection against a stock WordPress installation, studied the more complicated escalation chain, and reported it through the coordinated disclosure process. It then took him much longer to understand what the model had constructed, followed by another day untangling it and preparing the report. Other researchers independently reproduced the chain before public proof-of-concept code appeared.

The $25 figure was the estimated model usage — a pro-rata share of a $200 subscription — not the total cost of finding and responsibly disclosing the vulnerability. The actual cost excluded:
– Preparation of the test environment and WordPress source code
– Human review and reproduction of the exploit chain
– Communication with WordPress through the HackerOne program
– Patch development and coordinated disclosure
– Operational work required across affected sites

Step‑by‑Step: Post-Patch Verification and Log Review

After updating to a patched version, administrators should verify the update completed and review for signs of compromise:

Linux/macOS — Verify Installed Version:

 Via WP-CLI
wp core version --allow-root

Via direct file check
grep -E "^\$wp_version" /path/to/wordpress/wp-includes/version.php

Windows (PowerShell):

 Via WP-CLI (if installed)
wp core version

Via file check
Select-String -Path "C:\path\to\wordpress\wp-includes\version.php" -Pattern '$wp_version'

Review Logs for Suspicious Activity:

 Check for unexpected REST API batch requests (Linux)
sudo grep -i "/wp-json/wp/v2/batch" /var/log/nginx/access.log
sudo grep -i "/wp-json/batch/v1" /var/log/apache2/access.log

Check for unexpected administrator account creation
wp user list --role=administrator --format=table

Check for unexpected plugin installations
wp plugin list --status=active --format=table

3. The Economics of AI-Powered Vulnerability Discovery

This experiment fundamentally changes the economics of vulnerability research. A model can read a large codebase for hours, keep several incompatible hypotheses alive, and revisit a path without a researcher manually tracing every branch. Even when most of those paths fail, running them in parallel is now fairly cheap. The vulnerability class discovered — a pre-authentication WordPress RCE — is valued at approximately $500,000 on exploit broker markets. The AI compute cost to find it was $25. That’s a 20,000x disparity.

However, the model did not work in isolation. Kues prepared a copy of the latest stable WordPress source without its Git history, let the model pull in dependency source itself if needed, and told it not to use the internet to look for a patched version. The prompt allowed four agents and required several different research approaches to remain active instead of having every agent follow the first promising lead. This level of prompt engineering and research design is itself a skill — one that still requires human expertise.

Step‑by‑Step: Hardening WordPress Against Automated Exploitation

Beyond patching, consider these defense-in-depth measures:

  1. Restrict REST API Access (Linux/Windows via .htaccess or nginx):
    .htaccess - Restrict batch endpoint to authenticated users only
    <Location "/wp-json/wp/v2/batch">
    Require valid-user
    </Location>
    
 nginx - Block unauthenticated batch requests
location ~ ^/wp-json/wp/v2/batch {
allow 127.0.0.1;
deny all;
return 403;
}

2. Enable Forced Automatic Updates (wp-config.php):

// Force automatic updates for critical security releases
define('WP_AUTO_UPDATE_CORE', true);

3. Deploy a Web Application Firewall (WAF) Rule:

 Example ModSecurity rule to block suspicious batch requests
SecRule REQUEST_URI "/wp-json/wp/v2/batch" \
"id:10001,phase:1,t:none,deny,status:403,msg:'WordPress Batch API access restricted'"
  1. The SQL Injection Root Cause: A Deep Dive

The SQL injection (CVE-2026-60137) resides in the `WP_Query` class when handling the `author__not_in` parameter. Normally, this parameter expects an array of author IDs. When a string is passed instead, the `is_array()` check fails and the raw string value is interpolated directly into the SQL `NOT IN (…)` clause without proper sanitization. An attacker can leverage this to inject arbitrary SQL.

Vulnerable Code Pattern (Simplified):

// Vulnerable logic in WP_Query
if ( ! empty( $qv['author__not_in'] ) ) {
if ( is_array( $qv['author__not_in'] ) ) {
$author__not_in = array_map( 'intval', $qv['author__not_in'] );
} else {
// BUG: String is interpolated directly without sanitization
$author__not_in = $qv['author__not_in'];
}
$where .= " AND ID NOT IN ($author__not_in)";
}

Patched Code Pattern (WordPress 6.9.5 / 7.0.2):

// Patched logic
if ( ! empty( $qv['author__not_in'] ) ) {
if ( is_array( $qv['author__not_in'] ) ) {
$author__not_in = array_map( 'intval', $qv['author__not_in'] );
} else {
// FIX: Cast to array and sanitize
$author__not_in = array_map( 'intval', (array) $qv['author__not_in'] );
}
$where .= " AND ID NOT IN (" . implode( ',', $author__not_in ) . ")";
}

Step‑by‑Step: Manual SQL Injection Testing (Authorized Environments Only)

For educational purposes in a controlled lab environment, you can test the SQL injection vector:

 Example curl command to test for SQL injection (AUTHORIZED USE ONLY)
curl -X POST https://your-wordpress-site.com/wp-json/wp/v2/batch \
-H "Content-Type: application/json" \
-d '{
"requests": [
{
"path": "/wp/v2/posts",
"method": "GET",
"body": {
"author__not_in": "1) AND (SELECT 1 FROM (SELECT SLEEP(5))a)-- -"
}
}
]
}'

Note: A 5-second delay in response indicates a potential SQL injection vulnerability. Never use this against production systems without explicit authorization.

5. What WordPress Administrators Should Do Now

WordPress released version 7.0.2 on July 17 and identified the RCE issue as CVE-2026-63030. WordPress 6.9 is also affected and received the fix in version 6.9.5. The project enabled forced automatic updates because of the severity and recommends updating immediately. However, site owners should still verify the installed version rather than assume the background update completed. Managed hosts, disabled automatic updates, filesystem permissions, or a failed deployment can leave an installation behind.

Critical Action Items:

  1. Update immediately to WordPress 6.9.5, 6.8.6, or 7.0.2.
  2. Verify the update using WP-CLI or direct version file check.
  3. Review logs for unexpected REST API or administrator activity during the exposed period.
  4. Scan for compromise indicators using the wp2shell scanner or community tools.
  5. Change all administrator passwords if there is any suspicion of prior exploitation.

Step‑by‑Step: Emergency Patching via Command Line

Linux/macOS — WP-CLI Update:

 Navigate to WordPress root
cd /path/to/wordpress

Update to the latest secure version
wp core update --version=7.0.2 --allow-root

Verify the update
wp core version --allow-root

Linux/macOS — Manual Update via wget:

 Download the latest WordPress
wget https://wordpress.org/latest.tar.gz

Extract and replace (backup first!)
tar -xzf latest.tar.gz
cp -r wordpress/ /path/to/wordpress/

Windows — WP-CLI Update (PowerShell):

 Navigate to WordPress root
cd C:\path\to\wordpress

Update to the latest secure version
wp core update --version=7.0.2

Verify the update
wp core version

What Undercode Say:

  • Key Takeaway 1: AI dramatically lowers the cost of vulnerability discovery — a $25 model run uncovered a $500,000 zero-day — but human verification, reproduction, and responsible disclosure remain the expensive and irreplaceable parts of the process.

  • Key Takeaway 2: The wp2shell chain (CVE-2026-63030 + CVE-2026-60137) affects all default WordPress installations from 6.9.0–6.9.4 and 7.0.0–7.0.1, requiring no plugins, no special configuration, and no credentials to exploit. Immediate patching to 6.9.5, 6.8.6, or 7.0.2 is critical.

Analysis:

The narrative that “AI will replace security researchers” is fundamentally misguided. What we’re witnessing is a powerful augmentation — AI handles the brute-force search across millions of code paths while humans provide the context, validation, and ethical framework. The $25 figure is attention-grabbing but dangerously incomplete; it obscures the dozens of hours of human expertise required to transform a model’s output into a responsibly disclosed, actionable fix. For security teams, the real challenge ahead is triage: automated discovery can now generate more credible findings than organizations can validate and remediate. The bottleneck is shifting from discovery to verification, and that shift demands new investment in human talent, not less. WordPress administrators face an immediate, practical problem: a critical RCE that requires no authentication and is already being actively exploited. The window for patching is narrow, and the consequences of delay are severe.

Prediction:

  • -1 The democratization of AI-powered vulnerability discovery will lead to a surge in zero-day discoveries — both by ethical researchers and malicious actors. The barrier to entry for finding critical bugs has dropped from years of expertise to a $25 API call and a well-crafted prompt.

  • -1 Exploit brokers and nation-state actors will rapidly adopt multi-agent AI systems to automate vulnerability research, potentially outpacing the security community’s ability to patch and respond. The $500,000 market value for WordPress RCEs may plummet as supply increases.

  • +1 The security industry will evolve toward “AI-assisted human verification” as the new standard. Organizations that invest in both AI tooling and senior security talent will gain a significant defensive advantage over those that rely on either alone.

  • -1 WordPress, as the world’s most popular CMS, will remain a prime target. The wp2shell chain demonstrates that even mature, heavily audited codebases harbor critical vulnerabilities that can be uncovered by AI in hours. Expect more such discoveries in the coming months.

  • +1 The forced automatic update mechanism enabled by WordPress for this vulnerability sets a positive precedent. More CMS platforms will adopt aggressive auto-patching for critical-severity issues, reducing the window of exposure for the average site owner.

▶️ Related Video (78% Match):

https://www.youtube.com/watch?v=4Fj1V2tkJYg

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Shankarprasad Ks – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky