Elementor Pro 4.2.2 closed an unauthenticated file upload (CVE-2026-32475)

Two loops disagreed about an empty file. That was the whole bug, and it let anyone upload a PHP file to a site running Elementor Pro 4.2.1 or below.

What the flaw was

Elementor Pro's Forms widget validated uploads in one loop and moved them in another. When the first entry in a multipart upload array came back as "no file", validation returned early instead of carrying on to the later entries. Processing did not stop. A second entry, carrying a PHP file, went past extension and type checks and got written to disk.

Wordfence scores it 9.8 and tracks it as CVE-2026-32475; Patchstack, who published the technical write-up, score the same issue 9.0. Either way it is the shape of bug that turns a contact form into a shell, and Wordfence reported blocking more than 190,000 exploit attempts after disclosure on 19 August 2026.

Elementor Pro 4.2.2, published the same day, is the fix. Elementor free is not affected. The flaw is in the Pro Forms upload field.

What it needed

One thing, and most Elementor Pro sites have it: at least one published page with a Form widget that has a File Upload field. Job applications, support requests, quote forms, anything that takes a document. No unusual setting was required, because the default state of the field was enough.

A site running Elementor Pro with no upload field anywhere was not exposed through this path. That is worth knowing before anyone panics at a client, and worth checking rather than assuming, because forms accumulate quietly over the years a site has been live.

The folder to open

Uploaded files landed in wp-content/uploads/elementor/forms/, named from PHP's uniqid() with whatever extension the attacker chose. So on any site that ran 4.2.1 or below with a form upload field, open that folder once and look for anything that is not a document or image type your forms actually accept. A .php file in there is not ambiguous.

Two follow-ups if you find one. First, the file's timestamp tells you roughly when, which tells you which backup predates it. Second, a dropper that ran can have left an administrator account or other files behind, so check accounts created around that date before calling it done.

One more thing worth fixing whether or not anything turns up: ask your host whether PHP executes under wp-content/uploads. On a server that refuses to run PHP there, the same bug leaves a useless file instead of a shell. Respira's security audit can test this directly by writing one inert file, requesting it, and deleting it, which is the only honest way to know, since the answer lives in server configuration that PHP cannot read.

Across a fleet

The agencies i talk to did not miss this update because they are careless. They missed it on the three sites that are not in the monthly maintenance list, the ones a client set up themselves and handed over.

Respira's WordPress vulnerability scanner compares every plugin and version on every connected site against the Wordfence Intelligence database, refreshed every six hours, so a site still on 4.2.1 shows up without anyone remembering to look. The fix is approval-gated: the agent proposes the update, you approve it, and a second scan produces the receipt.

If you also want your AI assistant to read and edit those Elementor pages rather than only report on them, that is what the Elementor MCP server does: classic widgets and Atomic elements, every edit on a copy first, with undo.

Sources

• Wordfence record: Elementor Pro <= 4.2.1, unauthenticated arbitrary file upload
• Patchstack: the technical write-up

Checked on 22 September 2026.