CVE-2026-32475: Elementor Pro's File Upload Flaw Hands Attackers Your Server

If your WordPress site uses Elementor Pro and you have even one form with a file upload field, you have a critical problem. A vulnerability disclosed on August 19, 2026 — CVE-2026-32475 — lets an unauthenticated attacker bypass Elementor Pro's file extension blocklist entirely and write an executable PHP file directly into your web root. No login. No nonce. No JavaScript. Just a crafted HTTP request.

Patchstack, which discovered and reported the flaw, rated it CVSS 9.0. Wordfence independently assessed it at 9.8. The fix landed in Elementor Pro 4.2.2, released the same day as the advisory. If you are running 4.2.1 or earlier, you need to update before you read the rest of this.

How the Bug Actually Works

The root cause is a subtle desynchronization between two loops that handle a multi-part file upload. In the Forms module's File Upload field, the plugin runs one loop to validate file entries and a separate loop to move them into place. The problem is how each loop handles an empty file part (UPLOAD_ERR_NO_FILE):

• The validation loop uses return when it hits an empty entry — it exits the function completely, concluding there is nothing to check.
• The processing loop uses continue — it skips the empty entry and then moves right along to the next file part.

An attacker exploits this by crafting a multipart POST with two file parts for the same upload field: an empty (no-file) entry first, then a .php payload second. The validator sees the empty entry, calls return, and exits before ever inspecting the PHP file. The processor, running afterward, skips the empty entry and happily moves the PHP file into wp-content/uploads/elementor/forms/. The blocklist never fires.

Once the file is on disk, finding it is straightforward. Elementor Pro names uploaded files using PHP's uniqid() function, which produces a 13-character hexadecimal string derived from the current Unix timestamp in microseconds. That is not a random token — it is a time-based value an attacker can narrow down quickly by brute-forcing a small window around the request time. The result: an attacker drops a shell, finds the filename, and has full code execution on your server.

Who Is Actually Exposed

The precondition — a published Elementor page containing a Form widget with a File Upload field — sounds narrow. In practice it is not. Elementor powers somewhere between 10 and 20 million websites worldwide, making it one of the most installed WordPress page builders on the planet. File upload forms are standard for job applications, support tickets, client portals, photo contests, and lead-generation flows. Any agency or business that built those common page types with Elementor Pro is in scope.

No authentication is required. The upload field does not even need to be marked as required in the form settings — the default is off, and that setting does not affect exploitability. The CVSS vector reflects high attack complexity (AC:H) because the upload field must be present and published, but that complexity is on the victim's configuration, not the attacker's craft. Once the precondition is met, the attack itself is trivial.

As of the August 19 advisory, no public proof-of-concept exploit had been released and no confirmed active exploitation had been observed. That window will not stay open indefinitely. History with Elementor vulnerabilities is instructive: when a critical RCE bug in the free Elementor plugin dropped in 2023, mass scanning started within hours. Patchstack deliberately withheld certain technical specifics — the handler function name, endpoint, and upload parameter — to slow weaponization, but the general mechanism is now public enough that a motivated attacker can fill in the blanks.

What to Do Right Now

• Update Elementor Pro to 4.2.2 or later immediately. This is the only complete fix. The patch synchronizes the two loops so extension validation runs immediately before each file is moved, not in a prior pass that can be short-circuited.
• Audit your upload directory. Check wp-content/uploads/elementor/forms/ for any .php files. A legitimate upload should never be a PHP script. If you find one, treat your environment as compromised: rotate credentials, audit access logs for requests to that filename, and consider a full incident review.
• Check your Elementor Pro license. Auto-updates for premium plugins require a valid, connected license. Sites running expired or disconnected licenses often miss security releases entirely — a common footgun in the WordPress ecosystem.
• If you cannot update immediately, the safest interim measure is to temporarily remove File Upload fields from any published forms. Disabling the form entirely is preferable to leaving a vulnerable upload endpoint live.
• Enable server-side PHP execution blocking in uploads. A properly configured web server should already deny PHP execution inside wp-content/uploads/ via an .htaccess rule or Nginx config. If yours does not, this is the moment to add it — it is a defense-in-depth measure that limits the blast radius of any file upload vulnerability, not just this one.

The Broader Pattern

Form plugins are among the highest-value targets in the WordPress ecosystem precisely because they are designed to accept untrusted input. File upload fields take that further: the plugin has to receive, inspect, and store attacker-controlled bytes. Every step in that pipeline is an opportunity for a logic error. Forminator's CVSS 9.8 flaw, disclosed just days before this one, followed the same template. WPForms, Gravity Forms, Contact Form 7, and Elementor Pro have all had upload-related vulnerabilities in the past few years. The category is structurally risky.

The lesson for any site running form plugins with file upload capability: treat those features as elevated-risk attack surface. Keep the plugins current, know which forms expose upload fields, block PHP execution in the uploads directory at the web-server layer, and have a process to detect unexpected files there. At Falcon Internet, checking for stray executables in upload directories is a routine part of how we maintain WordPress environments — CVE-2026-32475 is a reminder of why that habit matters.