Unrestricted Upload of File with Dangerous Type vulnerability in Elementor Elementor Pro

CVE-2026-32475 is an unrestricted file upload (CWE-434) in the Elementor Pro Form widget and Dynamic Tags system, affecting all versions from n/a through 4.2.1. An unauthenticated attacker can bypass file-type enforcement on forms that include a file upload field, uploading a PHP webshell to a predictable path (/wp-content/uploads/elementor/forms/). Successful exploitation yields remote code execution as the web server user (typically www-data). Elementor Pro is a premium WordPress page-builder plugin powering an estimated 2–3 million live websites. The fix shipped in 4.2.2 on August 19, 2026 — the same day as public disclosure.

The vendor scored this CVSS 9.0 CRITICAL with AC:H, acknowledging that some preconditions exist — most likely the requirement that the target form actually contains a file upload field. That's a fair call for the base score, but noisgate downgrades slightly to HIGH 8.5 because the attack surface is gated by a non-default form configuration and there is no confirmed exploitation or public PoC yet. That said, WordPress file upload vulns have a documented patch-to-mass-exploitation window of 48 hours or less (see wp2shell, Ninja Forms CVE-2026-0740), so this grace period is razor-thin.

Why this verdict

• Unauthenticated + internet-facing: PR:N and AV:N mean no credential theft, phishing, or internal network position is needed. The form endpoint is public by design — this is the most dangerous access class for web vulns.
• Non-default form configuration (downward pressure): The file upload field is not present in Elementor Pro forms by default. A site builder must explicitly add it. This means the *actually exploitable* subset of 2–3M Elementor Pro sites is materially smaller, though the exact fraction is unknown.
• Weaponization velocity (upward pressure): WordPress plugin file-upload vulns are weaponized at extreme speed. The wp2shell chain saw mass exploitation within 48 hours; Ninja Forms CVE-2026-0740 was targeted the same day as disclosure. The patch diff is small and reverse-engineerable.
• Role multiplier: Elementor Pro runs on WordPress web servers. (a) *Low-value role:* personal blogs, brochure sites — compromise is nuisance-level. (b) *Typical role:* business websites, small e-commerce — compromise yields customer PII, stored credentials, SEO spam pivot. (c) *High-value role:* WooCommerce stores processing payments, customer portals with regulated data, or sites serving as software download sources (supply-chain risk). The chain succeeds identically across all roles; blast radius is host-level (web server + database), not domain/fleet-level. WordPress is NOT a canonically high-value-role component (not a DC, hypervisor, IdP, or CI/CD server), so the CRITICAL floor rule does not apply. Some e-commerce deployments with PCI-scoped data push toward HIGH but not CRITICAL.
• No exploitation evidence yet (marginal downward): No KEV listing, no PoC, no campaign reports. This is a 24-hour-old disclosure, so this factor is ephemeral and should not drive long-term severity.

Why not higher?

The CRITICAL floor requires the affected component to canonically occupy a high-value infrastructure role (DC, hypervisor, IdP, CI/CD, PAM, etc.) with fleet-scale or domain-scale blast radius. WordPress/Elementor Pro is a web application tier — compromise is contained to the host and its database. The AC:H rating and non-default file upload form requirement further narrow the reachable population below what a CRITICAL rating demands.

Why not lower?

Dropping below HIGH would ignore that this is an unauthenticated, zero-interaction, network-reachable RCE pathway against 2–3 million internet-facing sites. WordPress plugin file upload vulns are among the fastest-weaponized vulnerability classes in the ecosystem, with documented patch-to-exploitation timelines under 48 hours. The predictable upload path (/wp-content/uploads/elementor/forms/) eliminates post-upload guesswork, and no authentication or user interaction is required at any step.

1. Block PHP execution in the Elementor uploads directory immediately — Add a .htaccess rule (deny from all or php_flag engine off) or nginx directive (location ~ /wp-content/uploads/elementor/ { deny all; }) to prevent execution of any uploaded PHP files. This neutralizes the webshell even if the upload succeeds. Deploy within the noisgate mitigation SLA of 30 days — but given weaponization speed, do it today.
2. Disable or remove file upload fields from Elementor Pro forms — If your forms don't require file uploads, remove those fields entirely. This eliminates the attack surface. If file uploads are business-critical, restrict allowed extensions to images only (jpg, png, gif) at both the Elementor form config and the server level.
3. Deploy a WordPress-aware WAF rule — Cloudflare, Sucuri, or Wordfence WAF rules can inspect multipart POST bodies to Elementor form endpoints and block uploads containing PHP code signatures. Wordfence and Patchstack typically ship virtual patches within 24–48 hours of disclosure for high-profile CVEs like this.
4. Update to Elementor Pro 4.2.2 — The definitive fix. Test in staging and push to production. Given the HIGH severity and WordPress weaponization speed, target deployment within the noisgate remediation SLA of 180 days — realistically, push this within the first week.

Run this on each WordPress host (or from a management/jump box with HTTP access to your WordPress fleet). Invoke with bash check_cve_2026_32475.sh https://example.com. No special privileges needed — it makes unauthenticated HTTP requests only.

#!/usr/bin/env bash
# check_cve_2026_32475.sh — Detect vulnerable Elementor Pro versions
# Usage: bash check_cve_2026_32475.sh <wordpress_url>
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

URL="${1:?Usage: $0 <wordpress_url>}"
URL="${URL%/}"  # strip trailing slash

# Attempt 1: Read version from the readme.txt (common in plugins)
README_URL="${URL}/wp-content/plugins/elementor-pro/readme.txt"
VERSION=$(curl -sL --max-time 10 "$README_URL" | grep -i 'Stable tag:' | head -1 | sed 's/.*: *//;s/[[:space:]]//g')

if [ -z "$VERSION" ]; then
  # Attempt 2: Check changelog.txt
  CHANGELOG_URL="${URL}/wp-content/plugins/elementor-pro/changelog.txt"
  VERSION=$(curl -sL --max-time 10 "$CHANGELOG_URL" | grep -oP '^[0-9]+\.[0-9]+\.[0-9]+' | head -1)
fi

if [ -z "$VERSION" ]; then
  # Attempt 3: Check if plugin directory exists at all
  HTTP_CODE=$(curl -sL -o /dev/null -w '%{http_code}' --max-time 10 "${URL}/wp-content/plugins/elementor-pro/")
  if [ "$HTTP_CODE" = "404" ]; then
    echo "PATCHED — Elementor Pro not detected on this host."
    exit 0
  fi
  echo "UNKNOWN — Elementor Pro may be installed but version could not be determined."
  exit 2
fi

echo "Detected Elementor Pro version: $VERSION"

# Compare versions: vulnerable <= 4.2.1, patched >= 4.2.2
MINOR=$(echo "$VERSION" | cut -d. -f1,2)
PATCH=$(echo "$VERSION" | cut -d. -f3)

# Version comparison using sort -V
if printf '%s\n' "4.2.2" "$VERSION" | sort -V | head -1 | grep -q "4.2.2"; then
  echo "PATCHED — Elementor Pro $VERSION is >= 4.2.2."
  exit 0
else
  echo "VULNERABLE — Elementor Pro $VERSION is <= 4.2.1. Update to 4.2.2 immediately."
  exit 1
fi

Sources

1. Elementor Pro Security Vulnerabilities (stack.watch)
2. Elementor Pro Changelog
3. Patchstack — Elementor Vulnerability Disclosure Program
4. ELLIO — wp2shell: Patch to Mass Exploitation in 48 Hours
5. Patchstack — 90 Minutes: Watching Attackers Weaponize WordPress Core RCE
6. Elementor Statistics 2026 (Colorlib)
7. CISA Known Exploited Vulnerabilities Catalog