Elementor Pro Unauthenticated File Upload RCE: Detection, Hunting, and Remediation Guide for WordPress Defenders

A critical vulnerability in Elementor Pro — one of the most widely deployed premium WordPress plugins, active on millions of sites — allows unauthenticated attackers to upload arbitrary executable files to the server, leading directly to remote code execution (RCE). This is the worst-case scenario for a CMS plugin flaw: no credentials required, no user interaction required, and full server-side code execution under the web server's context once the malicious file is requested.

If you run WordPress with Elementor Pro installed, treat this as an emergency patch event. Arbitrary file upload flaws in WordPress plugins are among the most reliably mass-exploited vulnerability classes we see in incident response — within days of public disclosure, scanners and automated exploit frameworks begin sweeping the internet for vulnerable instances, and the first payload dropped is almost always a web shell. From a web shell, attackers escalate to defacement, SEO spam injection, credential harvesting, malware distribution, and full infrastructure compromise.

This post breaks down how the vulnerability works from a defender's perspective, gives you concrete detection content for your SIEM and EDR stack, and walks through remediation and hardening steps you can execute today.

Technical Analysis

Affected Component

The vulnerability resides in Elementor Pro's file upload handling logic — specifically in the functionality that processes file uploads submitted through Elementor-powered forms (the Forms widget's file upload field) and related upload endpoints routed through WordPress's admin-ajax.php handler.

Elementor Pro is a commercial plugin layered on top of the free Elementor page builder. Any WordPress site with Elementor Pro active — regardless of theme, hosting provider, or whether forms are visibly in use — should be considered at risk until the plugin version is verified and updated.

How the Attack Works (Defender's View)

The attack chain is straightforward, which is exactly why it's dangerous:

1. Unauthenticated request to the upload handler. The attacker sends a crafted POST request to /wp-admin/admin-ajax.php invoking Elementor Pro's upload action (e.g., action=elementor_pro_forms_upload_handler). No valid WordPress session, nonce, or credentials are required — the affected code path fails to properly gate the upload behind authentication and capability checks.

2. Insufficient file-type validation. The upload routine does not adequately restrict the extension, MIME type, or content of the uploaded file. Where a legitimate deployment should accept only images or documents (jpg, png, pdf, docx), the vulnerable code accepts .php, .phtml, .phar, and other server-executable types.

3. File lands in a web-accessible directory. Uploaded files are written under the WordPress uploads tree (typically /wp-content/uploads/elementor/... or a forms-specific subdirectory). Because the uploads directory is served directly by the web server, the attacker simply browses to the uploaded file's URL.

4. Code execution. When the attacker requests https://victim-site.com/wp-content/uploads/elementor/.../shell.php, the PHP interpreter executes the payload in the context of the web server user (www-data, apache, nginx, or the IIS application pool identity). From here the attacker has arbitrary command execution on the host.

Why This Matters Beyond the Web Server

A common mistake is treating web shells as a "website problem." In our IR engagements, a PHP web shell on a WordPress host routinely becomes:

• A credential theft point — wp-config.php contains database credentials; .htaccess, environment files, and adjacent application configs often contain API keys and service passwords.
• A lateral movement beachhead — web servers frequently sit in network segments with database access and, in poorly segmented environments, reach internal assets.
• A persistence anchor — attackers drop multiple shells across the uploads tree, inject backdoors into legitimate theme/plugin files, and create rogue admin users in WordPress, making cleanup a forensic exercise rather than a single-file deletion.

Exploitation Status

Arbitrary file upload vulnerabilities in high-install-base WordPress plugins follow a predictable pattern: public disclosure → PoC circulation → automated mass scanning within days → web shell deployment at scale. Defenders should operate on the assumption that vulnerable, internet-facing instances are being actively probed and exploited, and that any unpatched site with public exposure has likely already been scanned. Even after patching, you must hunt for shells dropped before the patch was applied — patching closes the door but does not evict attackers already inside.

Detection & Response

The detection strategy for this threat targets three observable layers: (1) the exploitation request itself against the Elementor upload endpoint, (2) requests to executable files inside the uploads directory, and (3) post-exploitation behavior where the web server process spawns child processes (web shell activity).

Sigma Rules

---
title: Elementor Pro Unauthenticated File Upload Exploitation Attempt
id: 3f8a2c71-9b4e-4d12-a6f7-1e5c8d2b9043
status: experimental
description: Detects HTTP requests targeting Elementor Pro's forms upload handler via admin-ajax.php, a known unauthenticated arbitrary file upload vector leading to RCE.
references:
  - https://www.bleepingcomputer.com/news/security/critical-elementor-pro-bug-exposes-wordpress-sites-to-rce-attacks/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - 'elementor_pro_forms_upload_handler'
      - 'elementor_pro_upload'
    cs-method:
      - 'POST'
  condition: selection
falsepositives:
  - Legitimate Elementor form submissions with file upload fields in use
level: high
---
title: Executable File Requested from WordPress Uploads Directory
id: 8c1d4e62-7a3b-4f90-b2e5-6d9a1c3f7852
status: experimental
description: Detects HTTP GET requests for PHP or other server-executable files under the WordPress uploads tree, a strong indicator of a dropped web shell following arbitrary file upload exploitation.
references:
  - https://www.bleepingcomputer.com/news/security/critical-elementor-pro-bug-exposes-wordpress-sites-to-rce-attacks/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: webserver
detection:
  selection_path:
    cs-uri-stem|contains:
      - '/wp-content/uploads/'
  selection_ext:
    cs-uri-stem|endswith:
      - '.php'
      - '.phtml'
      - '.phar'
      - '.php3'
      - '.php4'
      - '.php5'
      - '.php7'
      - '.pht'
  condition: selection_path and selection_ext
falsepositives:
  - Rare legitimate plugins that serve PHP from uploads (highly unusual and itself a finding worth reviewing)
level: critical
---
title: Web Server Process Spawning Shell or System Commands
id: 5e2b9f14-3c7d-4a81-9e60-4f2a7b8d1356
status: experimental
description: Detects web server or PHP interpreter processes spawning command shells or common post-exploitation binaries, consistent with web shell execution after a file upload compromise.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/php-fpm'
      - '/php'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/perl'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate WordPress plugins invoking system commands (e.g., image processing, backups) — baseline your environment and tune by CommandLine
level: high

KQL — Microsoft Sentinel / Defender

The first query hunts web access logs (ingested via IIS logs, Apache/Nginx logs through Syslog/CEF, or WAF logs) for exploitation of the upload endpoint and requests to executables in the uploads tree. The second hunts endpoint process telemetry for web shell behavior on Windows-hosted WordPress.

// Hunt 1: Elementor Pro upload handler abuse + executable access in uploads dir
let Timerange = 14d;
union isfuzzy=true
    (W3CIISLog
    | where TimeGenerated > Timerange
    | project TimeGenerated, sIP, cIP, csMethod, csUriStem, csUriQuery, scStatus, csUserAgent),
    (CommonSecurityLog
    | where TimeGenerated > Timerange
    | where isnotempty(RequestURL)
    | extend csUriStem = tostring(split(RequestURL, "?")[0]), csUriQuery = tostring(split(RequestURL, "?")[1])
    | project TimeGenerated, SourceIP, RequestMethod, csUriStem, csUriQuery, RequestURL, DeviceAction, RequestClientApplication)
| where csUriQuery has "elementor_pro_forms_upload_handler"
   or csUriQuery has "elementor_pro_upload"
   or (csUriStem has "/wp-content/uploads/" and csUriStem has_any (".php", ".phtml", ".phar", ".pht"))
| summarize Requests = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by csUriStem, csUriQuery, cIP, csUserAgent
| order by LastSeen desc;

// Hunt 2: Web server process spawning shells (Windows-hosted WordPress / IIS)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName has_any ("w3wp.exe", "php-cgi.exe", "php.exe", "httpd.exe")
| where FileName has_any ("cmd.exe", "powershell.exe", "pwsh.exe", "net.exe", "whoami.exe", "certutil.exe", "curl.exe")
   or ProcessCommandLine has_any ("whoami", "ipconfig", "net user", "Invoke-", "certutil -urlcache", "base64")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;

Velociraptor VQL

This artifact hunts the web root for recently created executable files in the uploads directory — the direct forensic artifact of this vulnerability class — plus anomalous child processes of the web server. Run it across your WordPress hosts via a Velociraptor hunt.

-- Hunt for web shells dropped in WordPress uploads directories
LET uploads = glob(glob='/**/wp-content/uploads/**/*.php*',
                   root='/var/www')

SELECT FullPath, Size, Mtime, Btime,
       Mtime.String AS ModifiedTime,
       Btime.String AS CreatedTime
FROM uploads
WHERE Mtime > (timestamp(epoch=now() - 30*24*60*60))
ORDER BY Mtime DESC

-- Correlate with web server processes spawning shells
LET shell_procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Exe =~ '(sh|bash|dash|curl|wget|nc|ncat|python|perl)$'

SELECT s.Pid, s.Name AS ShellName, s.Exe AS ShellExe, s.CommandLine,
       s.Username, s.CreateTime, p.Name AS ParentName, p.Exe AS ParentExe
FROM shell_procs s
JOIN (SELECT Pid, Name, Exe FROM pslist()) p ON s.Ppid = p.Pid
WHERE p.Exe =~ '(php-fpm|php$|apache2|httpd|nginx)'

Remediation & Verification Script

The following Bash script is designed for Linux-hosted WordPress. It inventories Elementor Pro, checks for unauthorized PHP files in the uploads tree (a primary post-exploitation artifact), lists recently modified PHP files across the web root, and applies an Apache .htaccess hardening control that blocks PHP execution in uploads — a durable defense-in-depth measure against this entire vulnerability class.

#!/bin/bash
# Elementor Pro file-upload RCE: verify, hunt, harden
# Run as root or with sudo on the WordPress host.

WEBROOT="/var/www/html"   # Adjust to your document root
UPLOADS="$WEBROOT/wp-content/uploads"
REPORT="/tmp/wp_upload_audit_$(date +%Y%m%d_%H%M%S).txt"

echo "=== Elementor Pro File Upload RCE — Audit & Harden ===" | tee "$REPORT"

# 1. Report installed Elementor Pro version (requires wp-cli)
if command -v wp >/dev/null 2>&1; then
  echo "[+] Installed plugin versions:" | tee -a "$REPORT"
  sudo -u www-data wp plugin list --path="$WEBROOT" 2>/dev/null | grep -i elementor | tee -a "$REPORT"
else
  echo "[!] wp-cli not found; checking plugin header directly:" | tee -a "$REPORT"
  grep -i "Version:" "$WEBROOT/wp-content/plugins/elementor-pro/elementor-pro.php" 2>/dev/null | tee -a "$REPORT"
fi

# 2. Hunt for PHP/executable files inside uploads (web shell artifacts)
echo "[+] Executable files found under uploads (investigate every hit):" | tee -a "$REPORT"
find "$UPLOADS" -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" -o -name "*.pht" \) \
  -printf "%T+ %p\n" 2>/dev/null | sort -r | tee -a "$REPORT"

# 3. Recently modified PHP files across the web root (backdoor injection check)
echo "[+] PHP files modified in the last 30 days:" | tee -a "$REPORT"
find "$WEBROOT" -type f -name "*.php" -mtime -30 -printf "%T+ %p\n" 2>/dev/null | sort -r | head -50 | tee -a "$REPORT"

# 4. Check for rogue WordPress admin users
if command -v wp >/dev/null 2>&1; then
  echo "[+] WordPress administrator accounts (verify all are legitimate):" | tee -a "$REPORT"
  sudo -u www-data wp user list --role=administrator --path="$WEBROOT" 2>/dev/null | tee -a "$REPORT"
fi

# 5. Harden: block PHP execution in uploads (Apache)
HTACCESS="$UPLOADS/.htaccess"
if [ ! -f "$HTACCESS" ]; then
  cat > "$HTACCESS" <<'EOF'
# Block execution of server-side code in uploads directory
<FilesMatch "\.(php|phtml|phar|php3|php4|php5|php7|pht)$">
  Require all denied
</FilesMatch>
EOF
  chown www-data:www-data "$HTACCESS"
  echo "[+] Deployed $HTACCESS blocking PHP execution in uploads" | tee -a "$REPORT"
else
  echo "[!] $HTACCESS already exists — verify it contains a PHP execution block" | tee -a "$REPORT"
fi

echo "=== Done. Full report: $REPORT ==="

For Nginx-hosted sites, add an equivalent location block denying PHP execution under /wp-content/uploads/ and reload the configuration. Note that .htaccess controls only apply to Apache with AllowOverride enabled — verify your server stack before relying on step 5.

Remediation

1. Update Elementor Pro immediately. Update to the latest available Elementor Pro release via the WordPress dashboard (Plugins → Installed Plugins → Update) or wp-cli (wp plugin update elementor-pro). Do not defer this to a maintenance window — this is an unauthenticated RCE in a plugin with a massive install base, and automated exploitation follows disclosure quickly. Confirm the update actually applied; commercial plugins tied to lapsed licenses sometimes fail silently in the updater. Verify the running version post-update and consult the official Elementor changelog and security notes at https://elementor.com/ and the vendor's advisory for the exact patched version applicable to your release branch.

2. Assume compromise and hunt retroactively. Patching prevents new exploitation — it does nothing about shells dropped while the site was vulnerable. Before you close the ticket:

• Search /wp-content/uploads/ (all subdirectories) for .php, .phtml, .phar, and .pht files. In a healthy WordPress deployment, there should be zero executable files under uploads. Any hit is a suspected web shell — quarantine it, preserve it for forensic review, and check its creation/modification timestamps against your web access logs to identify the exploiting source IP.
• Review web access logs for POST requests to admin-ajax.php with Elementor upload actions and for GET requests to executables in uploads (see KQL above).
• Audit WordPress administrator accounts for unauthorized additions, and review recently modified theme and plugin PHP files for injected backdoors.

3. Block PHP execution in the uploads directory. This is the single highest-value hardening control against this vulnerability class. Even if a future file-upload bug bypasses extension validation, the uploaded payload cannot execute. Apply the Apache .htaccess or Nginx location-block controls described in the script above to every WordPress site you operate.

4. Reduce exposure at the edge. Deploy or tune a WAF (ModSecurity with the OWASP Core Rule Set, Cloudflare managed rules, or your hosting provider's equivalent) to block executable file uploads and requests for PHP files under /wp-content/uploads/. Where Elementor Pro's forms upload feature is not in use, disable the file upload field type in form configurations.

5. Least privilege and segmentation. Ensure the web server runs as a dedicated low-privilege account, that wp-config.php and uploads directories have restrictive filesystem permissions, and that the web host is network-segmented from internal assets and database management interfaces. Limit outbound egress from the web server — most post-exploitation tooling requires outbound connectivity for C2 and payload staging.

6. Ongoing monitoring. Ship web server access logs and host telemetry to your SIEM. The Sigma and KQL content above should be deployed and baselined this week, not after the next disclosure.

The Bigger Lesson

WordPress plugin vulnerabilities — particularly unauthenticated file upload and injection flaws — remain one of the most exploited initial access vectors we see across IR engagements, year after year. The pattern is consistent: massive install base, trivially scriptable exploitation, and defenders who patch the CMS core religiously but treat plugins as an afterthought. If your vulnerability management program doesn't inventory WordPress plugins with the same rigor as operating systems and network appliances, this story is your remediation justification. Patch fast, hunt for shells retroactively, and harden the uploads directory so the next plugin bug lands on a dead end.

Related Resources

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