Elementor Pro Flaw CVE-2026-32475 Lets Unauthenticated Attackers Upload PHP for RCE

A critical Elementor Pro flaw, CVE-2026-32475, lets unauthenticated visitors slip a PHP file past the Forms upload check and run code on the server. It is the second WordPress-plugin RCE disclosed in three days. Update to 4.2.2.

Share
White line-art of a WordPress form upload field passing a PHP file into a server, one flat red dot marking the validation gap.

For the second time in three days, a widely used WordPress plugin can hand an unauthenticated visitor the ability to run code on the server. This time it is Elementor Pro, the paid add-on behind millions of WordPress sites.

Researchers have disclosed a critical flaw, tracked as CVE-2026-32475, that lets an unauthenticated attacker upload a PHP file through the plugin's Forms module and execute it, according to an advisory from Patchstack and reporting by The Hacker News. The bug carries a CVSS score of 9.0, affects every Elementor Pro version up to and including 4.2.1, and is fixed in 4.2.2, which shipped on August 19, 2026. The only thing an attacker needs is a published page with a Form widget that includes a File Upload field, a setup Patchstack describes as "an extremely common, everyday configuration."

The Flaw: A Validation Gap in the Forms Upload Field

CVE-2026-32475 is an unrestricted upload of a dangerous file type, the weakness class cataloged as CWE-434. It lives in the File Upload field of Elementor Pro's Forms module, the widget that powers job-application forms, "attach a photo or ID" fields, and support-ticket attachments across countless sites.

The problem is a mismatch inside the plugin's own upload handling. "The flaw lives in the Forms module's File Upload field, where the extension check and the file-move step run in two separate loops with different handling of empty file entries," Patchstack wrote. Because those two loops disagree about how to treat empty entries, the extension blocklist that is supposed to reject PHP gets sidestepped, and a PHP file lands in a public uploads directory instead of being discarded. Patchstack traced the write to wp-content/uploads/elementor/forms/, where the uploaded file is named from the output of PHP's uniqid() function.

What makes this worse than a typical upload bug is that no login, no special role, and no hardened configuration is required. The field's "Required" toggle is off by default, so the affected forms are the ordinary ones site owners set up without a second thought. In Patchstack's words, "job-application forms, 'attach a photo/ID/receipt' forms, and support-ticket attachments all use it."

Who Is Affected

Only Elementor Pro is affected, not the free Elementor page builder, and that distinction matters. The free plugin has more than 10 million active installs; Elementor Pro is the paid tier, and Elementor does not publish an official Pro install count. Third-party estimates put Pro on the order of a few million sites (Colorlib pegs it at roughly two to three million), so treat any precise number with caution. The population that actually matters is narrower and more knowable: sites running Pro 4.2.1 or earlier that have published at least one form containing a File Upload field.

 Exposure Triage · CVE-2026-32475
Three quick questions decide whether a site needs an emergency patch tonight.
Step 1 · Version
Is the site running Elementor Pro 4.2.1 or earlier? This is the paid Pro add-on, not the free Elementor plugin.
Step 2 · Form Widget
Does any page use a Forms module widget that contains a File Upload field? Think application, ticket, or attachment forms.
Step 3 · Reachable
Is that page published and reachable on the public internet? No login or special role is needed to reach it.
 All Three Yes: Exposed
Treat the site as at risk of unauthenticated remote code execution. Update Elementor Pro to 4.2.2 now, or pull the File Upload field until you can.
Any “no” lowers the immediate risk, but patch anyway: a form can be added later.
Source: Patchstack advisory, August 2026. Diagram: The CyberSignal.

Exposure triage for CVE-2026-32475: version, a Forms File Upload field, and public reachability together mark a site as exposed. Source: Patchstack advisory, August 2026. The CyberSignal.

Why WordPress Form Uploads Keep Breaking

File-upload validation is one of those problems that looks solved and rarely is. The safe approach is an allowlist: decide the handful of extensions and content types you will accept, then reject everything else. Blocklists, which try to enumerate the dangerous types to forbid, invite exactly the kind of edge case at work here, where a gap between "what we checked" and "what we saved" lets a forbidden file slip through. Elementor's bug is not an exotic memory-corruption chain. It is a logic gap between two loops, the ordinary sort of mistake that hides in mature, heavily used code.

That is also why the pattern is worth naming. Forms are user-facing by design, they often accept files by design, and they sit on the public internet by design. When the plugin that renders them mishandles an upload, the result is a pre-authentication foothold on the web server, which is close to the worst outcome a site operator can have. The Elementor disclosure landing in the same week as a similar unauthenticated upload flaw in the Forminator forms plugin is a reminder that "we use a reputable plugin" is not the same as "this input is safe."

How Serious Is This, Really

Serious enough to patch tonight, but worth stating plainly what is and is not confirmed. Patchstack rates it 9.0, and the preconditions are trivial, which is the combination that gets a bug weaponized quickly. The flaw was found by researcher Tin Pham (also known as TF1T) and reported through the Patchstack Bug Bounty Program on July 16, 2026; Elementor shipped the fix on August 19.

What is not confirmed: as of publication there are no public reports of active exploitation of CVE-2026-32475, and the bug does not appear on CISA's Known Exploited Vulnerabilities catalog. Both could change quickly, and the low bar to exploit means defenders should not wait for a KEV listing to act.

My read: the timing is the story. This is the second unauthenticated file-upload-to-RCE flaw in a mainstream WordPress plugin in about three days. Forms handling is turning into a reliable soft spot across the WordPress ecosystem, and any team running third-party form widgets should treat "arbitrary file upload" as a recurring category to watch, not a one-off. (That is my assessment, not a reported fact: I expect proof-of-concept code to follow the advisory within days, which only shortens the window to patch.)

What Defenders Should Do

The fix is a version bump, but a few checks around it are worth the ten minutes:

  • Update Elementor Pro to 4.2.2 or later. This is the whole fix. Confirm you are on the Pro plugin's 4.2.2 build, not just the latest free Elementor.
  • Audit the uploads directory. Look in wp-content/uploads/elementor/forms/ for any .php files. Nothing executable should live there, so a PHP file in that path is a strong indicator of compromise, not a false positive.
  • If you cannot patch immediately, remove the exposure. Disable or delete File Upload fields from published Elementor forms until the update is in place. No File Upload field, no attack surface for this bug.
  • Add a WAF rule to block uploads of PHP and other executable types to the Elementor forms path, and to flag multipart requests that submit duplicate file parts for a single field.
  • Sweep for the aftermath. Check for unknown admin accounts, unexpected scheduled tasks, and web shells, and review access logs for POST requests to your form endpoints followed by direct requests to files under the uploads path.

Elementor Pro updates through the standard WordPress plugin updater, so sites with auto-updates enabled for Pro may already be covered. Verify rather than assume.

Primary Documents