Back to Intelligence

WordPress Core Flaw 'wp2shell': Unauthenticated RCE Detection and Remediation

SA
Security Arsenal Team
July 17, 2026
5 min read

A critical vulnerability has been disclosed in the WordPress core that poses an immediate threat to the internet's CMS infrastructure. Tracked by the research community as "wp2shell," this flaw allows unauthenticated attackers to execute arbitrary code via a single anonymous HTTP request. Unlike typical plugin vulnerabilities, this issue resides in the core application, meaning even a bare-bones WordPress installation is susceptible to remote takeover.

Discovered by Adam Kues at Assetnote (Searchlight Cyber), the vulnerability affects versions 6.9 and 7.0. The WordPress security team responded by releasing patches 6.9.5 and 7.0.2 and enabling forced auto-updates. Given the ubiquity of WordPress and the ease of exploitation (no authentication or user interaction required), this vulnerability demands immediate defensive action.

Technical Analysis

  • Affected Products: WordPress Core
  • Affected Versions:
    • WordPress 6.9.x prior to 6.9.5
    • WordPress 7.0.x prior to 7.0.2
  • Vulnerability Type: Unauthenticated Remote Code Execution (RCE)
  • Vector: Anonymous HTTP request

The vulnerability exploits a logic flaw in the core WordPress processing logic that allows an attacker to pass and execute arbitrary code. Because the flaw is present in the core, standard security practices such as minimizing plugins do not mitigate the risk. The attack chain is trivial: a single malicious HTTP request triggers the execution of a payload, which typically results in the deployment of a webshell or the direct execution of system commands.

Exploitation Status:

  • Public Disclosure: Detailed technical analysis and proof-of-concept (PoC) availability are expected to be high following the disclosure by Assetnote.
  • Patch Availability: Patches 6.9.5 and 7.0.2 are available. WordPress has pushed forced updates, but environments with auto-updates disabled—common in enterprise managed hosting—are at significant risk.

Detection & Response

SIGMA Rules

The following Sigma rules detect suspicious web requests indicative of exploitation attempts and the subsequent process execution on Linux hosts.

YAML
---
title: Potential WordPress Core RCE Exploitation Attempt
id: 8c4d2a10-1b3e-4f9d-8a2e-3c5d6e7f8a9b
status: experimental
description: Detects potential exploitation of the WordPress wp2shell flaw by identifying common webshell keywords (eval, base64_decode) in HTTP requests targeting WordPress PHP files.
references:
  - https://thehackernews.com/2026/07/new-wp2shell-wordpress-core-flaw-lets.html
author: Security Arsenal
date: 2026/07/18
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri-stem|contains: '.php'
  selection_payload:
    cs-uri-query|contains:
      - 'eval('
      - 'base64_decode'
      - 'assert('
      - 'system('
  condition: selection_uri and selection_payload
falsepositives:
  - Legitimate development or debugging activity (rare in production)
level: high
---
title: Web Server Spawning Shell via WordPress Exploit
id: 9d5e3b21-2c4f-5g0e-9b3f-4d6e7f8a9b0c
status: experimental
description: Detects the web server process (apache/nginx/php-fpm) spawning a shell, a common behavior following successful RCE on a WordPress site.
references:
  - https://thehackernews.com/2026/07/new-wp2shell-wordpress-core-flaw-lets.html
author: Security Arsenal
date: 2026/07/18
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/apache2'
      - '/httpd'
      - '/nginx'
      - '/php-fpm'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/zsh'
      - '/netcat'
      - '/nc'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate system administration scripts executed via web interface
level: critical

KQL (Microsoft Sentinel / Defender)

Use this query to hunt for exploitation attempts in your WAF or proxy logs (ingested via CommonSecurityLog).

KQL — Microsoft Sentinel / Defender
// Hunt for wp2shell exploitation indicators in Web Logs
CommonSecurityLog
| where isnotempty(RequestURL)
| extend RequestURLParts = split(RequestURL, "?")
| extend FilePath = RequestURLParts[0]
| extend QueryParams = RequestURLParts[1]
| where FilePath contains ".php"
| where RequestBody contains "eval(" 
   or RequestBody contains "base64_decode" 
   or RequestBody contains "assert(" 
   or RequestBody contains "system(" 
   or QueryParams contains "eval(" 
   or QueryParams contains "base64_decode"
| project TimeGenerated, DeviceAction, SourceIP, DestinationIP, RequestURL, RequestBody, ApplicationProtocol
| summarize count() by bin(TimeGenerated, 1h), SourceIP, RequestURL
| order by TimeGenerated desc

Velociraptor VQL

This artifact hunts for recently modified PHP files in the WordPress directory, which may indicate a webshell has been dropped.

VQL — Velociraptor
-- Hunt for recently modified PHP files in WordPress directories
SELECT FullPath, Mtime, Atime, Size, Mode
FROM glob(globs='/var/www/html/**/*.php')
WHERE Mtime > now() - timedelta(hours=24)
  -- Exclude known core files if hash verification is available
ORDER BY Mtime DESC

Remediation Script

Run this Bash script on your Linux servers to check the WordPress version against the patched releases.

Bash / Shell
#!/bin/bash

# Define vulnerable versions and patches
VULN_69="6.9.5"
VULN_70="7.0.2"

# Check if wp-cli is installed, fallback to reading version.php if not
if command -v wp &> /dev/null; then
    WP_PATH=${1:-/var/www/html} # Accept path as first argument or default
    CURRENT_VERSION=$(wp core version --path="$WP_PATH" --allow-root)
    echo "WordPress Path: $WP_PATH"
    echo "Current Version: $CURRENT_VERSION"

    # Compare versions (simple string comparison sufficient for this specific range)
    if [[ "$CURRENT_VERSION" == "6.9."* ]] && [ "$(printf '%s
' "$VULN_69" "$CURRENT_VERSION" | sort -V | head -n1)" = "$CURRENT_VERSION" ]; then
         echo "[VULNERABLE] Version $CURRENT_VERSION is below patched 6.9.5. Please update immediately."
    elif [[ "$CURRENT_VERSION" == "7.0."* ]] && [ "$(printf '%s
' "$VULN_70" "$CURRENT_VERSION" | sort -V | head -n1)" = "$CURRENT_VERSION" ]; then
         echo "[VULNERABLE] Version $CURRENT_VERSION is below patched 7.0.2. Please update immediately."
    elif [[ "$CURRENT_VERSION" < "6.9.5" ]] || [[ "$CURRENT_VERSION" > "7.0.2" && "$CURRENT_VERSION" < "7.1" ]]; then
         # Catch all for older versions or potentially missed edge cases in 7.0.x
         echo "[CHECK] Version $CURRENT_VERSION requires manual verification against security advisory."
    else
         echo "[OK] Version $CURRENT_VERSION appears to be patched."
    fi
else
    echo "wp-cli not found. Please verify wp-includes/version.php manually."
fi

Remediation

  1. Immediate Patching: Update WordPress immediately to version 6.9.5 or 7.0.2.
  2. Verify Auto-Updates: While WordPress has pushed forced updates for this specific flaw, ensure your define( 'WP_AUTO_UPDATE_CORE', ... ); settings in wp-config.php are configured appropriately for future critical vulnerabilities (e.g., minor or true).
  3. Compromise Assessment: Merely patching does not remove a webshell if the server was already compromised. Conduct a thorough scan of your filesystem for recently modified PHP files (using the VQL above) and suspicious cron jobs.
  4. WAF Configuration: Update your Web Application Firewall (WAF) rules to block known exploit patterns for this vulnerability, although this should be a secondary measure behind patching.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

sigma-rulekql-detectionthreat-huntingdetection-engineeringsiem-detectionwordpressrcewp2shellassetnoteweb-security

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.