Hunting wp2shell: Detection Rules for the Object Cache Variant
Just saw the update on The Hacker News regarding the wp2shell flaw. The fact that a bare WordPress install is exploitable via an anonymous HTTP request is nightmare fuel, but the addition of the persistent-object-cache condition changes the detection game significantly.
We know this impacts WP 6.9 and 7.0 core. If you haven't patched yet, you're relying on obscurity. The new details suggest that if an object cache (like Redis) is in use, the payload persistence increases, making standard log review tricky.
I've thrown together a quick bash script to scan for vulnerable versions across our environments:
#!/bin/bash
# Scan for vulnerable WP versions
grep -r "wp_version\['" /var/www/html/*/wp-includes/version.php 2>/dev/null | grep -E "(6\.9|7\.0)"
And for detection, I'm looking for suspicious URL patterns in the access logs that trigger the deserialization:
# Access log scan for potential wp2shell exploitation attempts
awk '$7 ~ /wp-admin\/admin-ajax\.php/ && $11 > 10000 {print $0}' /var/log/nginx/access.log
Has anyone else seen successful exploitation attempts against the object cache variant? Standard WAFs seem to be missing this because it mimics core behavior.
We noticed a spike in 404s followed by a 200 OK on admin-ajax.php right before the PoC dropped. The persistent object cache angle is nasty because the payload executes on the next cache hit, not necessarily the initial request. We updated our ModSecurity rules to block any serialized data in the query string for admin-ajax.
From an MSP perspective, this forced update was painful but necessary. We saw several compromised sites where the attackers dropped webshells in /wp-content/uploads/. I'd recommend checking for any new .php files in upload directories created around the time of the patch release:
find /wp-content/uploads/ -name "*.php" -type f -mtime -2
The CVE assignments finally landed. The mechanism is a classic PHP deserialization issue triggered by core. If you're running Redis, ensure your WP_CACHE_KEY_SALT is unique and rotated. If the attacker can predict the cache key, they can inject the object easily. Don't just patch; rotate your salts.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access