CVE-2026-32475 is an unrestricted file upload flaw in the Forms module of Elementor Pro, rated CVSS 9.0. It lets an unauthenticated attacker write a PHP file into a public directory, which on a WordPress host means remote code execution.

Every version up to and including 4.2.1 is affected. 4.2.2 fixes it, released on 19 August 2026.

It was found by security researcher Tin Pham (TF1T) and reported through the Patchstack bug bounty programme on 16 July 2026.

The bug is a disagreement between two loops

Elementor checks the extension of an uploaded file against a blocklist, and separately moves the accepted file into place. Those are two loops over the submitted parts — and they do not treat empty entries the same way.

So an attacker submits two file parts for the same field. The loops fall out of step, and per Patchstack's description the unauthenticated attacker skips the extension blocklist entirely and writes a PHP file into a public directory.

The file lands at a predictable path under wp-content/uploads/elementor/forms/, named with a unique id and ending in .php. Request it, and it runs.

This is a validate-here-act-there bug, the same family as the MLflow SSRF where the URL was checked and then not pinned. The check was written correctly. It just was not the thing that governed what happened next.

Why almost every affected site qualifies

The precondition is thinner than it sounds: one published Elementor page containing a Form widget with a File Upload field.

That is a job application form. A support ticket with a screenshot. A photo competition entry. A "send us your brief" box. And the field's Required toggle defaults to off, so a form that has an optional attachment nobody ever uses is just as exploitable as one built around uploads.

The population here is large. Elementor is one of the most widely installed WordPress page builders in existence, and the affected component is its default form. Compare the BdThemes flaw that let unauthenticated visitors create admin accounts: the WordPress plugin ecosystem keeps producing these because the install base is enormous and the update path is manual.

The upload directory should not execute anything

The deeper point, and it is not Elementor's alone.

A file arriving in an uploads folder is not by itself a compromise. It becomes one because the web server will happily execute a .php file it finds there. Most WordPress hosts still allow that, and almost no site needs it — the uploads directory exists for images and documents, not code.

Blocking PHP execution under wp-content/uploads turns an entire recurring class of WordPress bug from critical into noise. It is a few lines in nginx or an .htaccess rule, and it would have neutralised this one before the patch existed.

What to do

  • Update to Elementor Pro 4.2.2. Everything below it is affected.
  • Look in the uploads folder for .php files. Specifically wp-content/uploads/elementor/forms/. A PHP file there is not a false positive.
  • Block PHP execution in the uploads directory if you have not. Do it once, benefit permanently.
  • Check your users, scheduled tasks and theme files if you find something. A web shell is the first step, not the objective.
  • Check the sites you built for other people. Agencies and freelancers carry this risk on behalf of clients who will never read a CVE.

What is not established

  • Whether it has been exploited. No exploitation had been reported at the time of writing, though the patch is public and the bug class is easy to diff.
  • How many sites are affected. No install-base figure for the vulnerable versions has been published.
  • Whether older major versions are separately affected. The advisory covers versions through 4.2.1.