wp2shell: Analyzing the Core RCE and WordPress's Forced Update Move

We saw the forced updates kick in on Friday afternoon. Honestly, it was a shock to the system for our legacy clients who usually stage updates for a week. From an MSP perspective, I appreciate the urgency given the RCE severity, but it breaks our internal change management policies. We're now debating whether to pin versions at the minor level and accept the risk in the future.

Just to add detection context, we've been catching exploit attempts in our honeypots using this Suricata rule signature. It focuses on the specific malformed HTTP headers mentioned in the Assetnote report.

alert http any any -> $HTTP_SERVERS $HTTP_PORTS (msg:"wp2shell attempt"; flow:to_server,established; content:"POST"; http_method; content:"/wp-admin/admin-ajax.php"; http_uri; pcre:"/X-WP-Nonce:[\s]+[a-f0-9]{32}/i"; sid:2026001; rev:1;)

Make sure your WAF is blocking requests with that specific header structure if you haven't patched yet.

The forced update helps, but for containerized deployments, auto-patching often fails against read-only root filesystems. Don't assume you're safe just because WP reports it's updated; you need to rebuild the image to ensure the fix persists across restarts.

To check for vulnerable images still running in your cluster:

kubectl get pods -l app=wordpress -o path="{.items[*].spec.containers[*].image}"

Validating Mei's point, auto-updates can mask underlying issues. For incident response, don't just rely on IDS; check your access logs for the specific malformed header chain used in the POCs. You're looking for unusually long header values or specific encoding bypasses.

grep -iR "X-Forwarded-Host: .*%0a" /var/log/nginx/


If you see hits matching that pattern against the XML-RPC endpoint, you likely had probing activity before the patch landed.

Great insights, everyone. Since this is core RCE, patching secures the perimeter but doesn't clean the house. If you suspect exploitation before the forced update, you should hunt for potential webshells or backdoors left behind. A quick way to identify suspicious recently modified PHP files on a Linux host is:

find /var/www/html -name "*.php" -mtime -2 -ls

Run this to catch any persistence mechanisms established in the chaos of Friday.

Building on Derek's point about cleanup, don't overlook the filesystem timestamps. Attackers often drop obfuscated payloads immediately. To catch these, run a quick find command for recently modified PHP files in your root directory. This often reveals the persistence mechanism even if the initial request wasn't flagged.

find /var/www/html -type f -name "*.php" -mtime -1 -ls

Building on Derek's advice, ensure you verify the integrity of your user database. Attackers often create new admin accounts for persistence. You can audit the wp_users table in MySQL to spot any accounts created during the vulnerability window:

SELECT user_login, user_registered FROM wp_users WHERE user_registered BETWEEN '2024-10-24' AND NOW();

Also, tune your DLP rules to flag large outbound data transfers originating from PHP processes, just in case the shell slipped past your initial scan.

Building on Derek's advice, attackers often drop payloads in the uploads directory since it's inherently writable. To hunt for persistence, run a command to find recently modified PHP files in wp-content:

find ./wp-content -type f -name "*.php" -mtime -7


If you find any, grep them for common obfuscation patterns like `eval(base64_decode`.