Elementor Pro Vulnerability Exploited on Patch Day

On August 19, 2026, Elementor shipped version 4.2.2 of Elementor Pro. Attacks against the flaw it patched started the same day. That's the part of this Elementor Pro vulnerability story that should worry you more than the CVSS score, and the score is already a 9.8.

CVE-2026-32475 affects Elementor Pro up to and including version 4.2.1, a plugin running on more than 6 million active WordPress sites according to BleepingComputer. The bug lets an unauthenticated visitor upload a PHP file through a form's File Upload field and have it saved to disk, which is about as close to game over as a WordPress vulnerability gets. The attacker doesn't need an account or anyone's help.

We've covered this exact vulnerability class before in our writeup on the Super Forms nopriv AJAX upload flaw, and the pattern rhymes here: a validation check that looks solid on the surface, undone by one wrong keyword.

How the flaw works

The root cause, per Wordfence's advisory, sits in a single method: Upload::validation(). That method loops over the files submitted through a form's File Upload field, checking each one's extension and file type before Elementor Pro accepts it. The advisory says it's reached through the plugin's process_field function, and it runs for visitors who aren't logged in.

Here's the bug. When the loop hits the first array element and that element has an UPLOAD_ERR_NO_FILE status, the validation function returns immediately instead of moving on to check the next file. In a loop, return and continue look like they might do similar things. They don't. continue skips to the next item and keeps checking everything after it. return exits the entire function right there, on the spot, and nothing after that line runs.

A simplified illustration of the mistake looks like this. This isn't Elementor's actual code, just the shape of the error:

// Simplified illustration, not Elementor's real code
foreach ( $uploaded_files as $file ) {
    if ( $file['error'] === UPLOAD_ERR_NO_FILE ) {
        return; // should be: continue;
    }
    validate_extension( $file );
    validate_mime_type( $file );
}

Feed that loop an array where the first file is empty and the second carries a malicious payload, and the function bails before it ever looks at file two. No extension check, no file type check. That's exactly the shape of the real attack: submit the File Upload field as an array, leave the first slot empty so it trips UPLOAD_ERR_NO_FILE, and put a PHP file with a .php extension in the second slot. The loop exits on element zero and waves the payload straight through.

There's one condition that has to be true for a site to be exploitable. The site needs a published page carrying an Elementor Pro Form widget with at least one File Upload field configured. No such form, no reachable code path. Every site running that widget with uploads enabled, though, was sitting exposed from the moment 4.2.1 (or any earlier vulnerable version) went live until it updated.

Worth sitting with for a second: this form field is, by design, meant to accept files from anyone who lands on the page. That's the entire point of a public contact form or job application form with an attachment field. The plugin doesn't need to authenticate the visitor first, because the visitor was never supposed to need an account. The validation loop was the only thing standing between "stranger submits a resume" and "stranger writes PHP to your server," and that loop had a hole in it in every version up to and including 4.2.1.

Affected and fixed versions

If you're running 4.2.1 or older, treat this as urgent. Not important, not scheduled-for-next-maintenance-window. Urgent.

Attacks started the day the patch did

Wordfence's telemetry shows exploitation beginning August 19, 2026, the same day 4.2.2 went out the door. A security release tells attackers where to look, and a bug this simple doesn't take long to reproduce once they know. The window between "patch available" and "patch installed" is where sites get hit.

By August 23, four days later, Wordfence says it had blocked close to 200,000 exploitation attempts. The Hacker News, reporting on September 4, cites a figure of 190,000 blocked attempts from the same wave.

Numbers like that don't come from a few hand-picked targets. They point to automated scanning that fires the exploit at site after site and keeps whatever lands. With more than six million active installations, Elementor Pro gives that kind of campaign plenty to work with.

Uploaded files land in wp-content/uploads/elementor/forms/ with randomly generated file names, which is standard behavior for that directory since it's where Elementor Pro stores every form submission's attachments. The randomness that normally keeps submitted files from colliding also means a malicious PHP file dropped there won't stand out by name. It will stand out by extension. A legitimate form attachment is a resume, an image, a PDF. It is never a .php file.

The Hacker News published a set of IP addresses tied to the exploitation wave:

• 2602:fa59:10:7a1::1
• 185.196.220.85
• 103.84.230.85
• 103.90.148.202
• 216.126.225.208
• 167.254.240.75
• 167.254.241.119
• 114.10.17.253
• 114.10.45.151
• 2406:ef80:2:7d19::1

Cross-reference these against your access logs for the window starting August 19. A hit doesn't automatically mean you were compromised, since these could show up as failed attempts against sites already patched or without a File Upload form. But it's a starting point, not the whole investigation.

One thing worth stating plainly: as of today, September 11, 2026, CVE-2026-32475 is not listed in CISA's Known Exploited Vulnerabilities catalog. Some secondary sources have implied otherwise. Active exploitation and formal KEV listing are two different facts, and only one of them is confirmed here.

The Super Forms parallel

Elementor Pro isn't the only form plugin under fire right now. Super Forms' CVE-2026-14894, fixed in version 6.3.314, has been under exploitation since July 14, 2026, peaking near 40,000 requests around August 18 with more than 250,000 blocked attempts total. Attackers there dropped a shell named Mushr00w_upl.php.

Different plugin, different root cause: Super Forms failed on authorization, treating a nonce as proof of permission it never had. Elementor Pro failed on a loop control statement. Same outcome both times. Anywhere a form accepts a file from a stranger on the internet, the validation logic carries the full weight of keeping that upload from becoming a webshell, and a single line can undo all of it.

What to do right now

Update to Elementor Pro 4.2.2 or later first. There's no partial mitigation that makes sense to run in place of the patch; disabling the File Upload field on your forms would close the path, but it's a worse trade than just updating.

After that, go look for evidence. Start with the uploads folder itself:

find wp-content/uploads/elementor/forms/ -name "*.php" -type f

Any result from that command is a serious finding. That directory has no legitimate reason to contain a PHP file, ever. If it returns something, don't assume it's the only foothold; check for others.

Next, look for administrator accounts you don't recognize. Attackers with a webshell often create their own admin user, since that's a quieter path back in than re-running the exploit each time. Sort your users list by registration date and look closely at anything created since August 19.

Check for recently modified files across the site, not just in the uploads directory. A webshell that got a foothold is frequently used to drop or modify other files, including theme templates and plugin code, as a second and third way back in. If your host or server gives you file modification timestamps, filter for anything touched since the patch date and treat unexplained hits with suspicion. A single clean scan of the uploads folder isn't a full clearance if the attacker had days of access before you looked.

Pull your access logs and look for POST requests to the form submission endpoint carrying an array-style File Upload field, and check them against the IP list above. A form submission where the file field is submitted as an array with an empty first element is not normal traffic; it's the specific shape of this exploit.

While you're in there, disable PHP execution inside wp-content/uploads/ if your server config allows it. That doesn't patch this vulnerability, and it won't stop a determined attacker who has other ways in. What it does is turn a successful arbitrary file upload into a dead end instead of a running shell, which is worth doing regardless of which plugin's bug caused the upload in the first place.

If you find a .php file in that forms directory, don't delete it and call the incident closed. A file like that means code ran on your server with the same permissions as your web server user, and that's a foothold an attacker can use to plant something else the moment you're not looking. Our WordPress malware removal guide and our deeper piece on PHP backdoors in WordPress both walk through what a real cleanup looks like once a shell has landed, and it's more than one deleted file.

If you want the fuller picture of how bugs like this fit into the broader landscape of WordPress compromise, our rundown of how WordPress sites actually get hacked covers the other common paths attackers use alongside plugin vulnerabilities like this one. A related file upload flaw in a different plugin is covered in our Ninja Forms file upload vulnerability writeup, if that plugin is also in your stack.

How WP Vanguard catches this

WP Vanguard's deep scan lists every .php file inside wp-content/uploads and flags it as an infection indicator, which covers the elementor/forms directory this vulnerability targets. You don't have to remember to run the find command by hand every time a new plugin CVE drops.

If you're running Elementor Pro, or any plugin with a public-facing upload form, run a scan on your site and see what's actually sitting in your uploads folder.

References

• BleepingComputer: Critical Elementor Pro flaw exploited to take over WordPress sites
• SecurityWeek: Elementor Pro WordPress plugin vulnerability exploited to hack sites
• The Hacker News: exploitation of Elementor Pro and Super Forms flaws (September 4, 2026)
• NVD: CVE-2026-32475 Detail