Elementor Pro’s Form Bug Left Hosts Holding the Cleanup

A critical Elementor Pro form bug, CVE-2026-32475, let anyone upload a PHP file to a public WordPress folder, and attackers started the same day the fix shipped. Wordfence has blocked over 190,000 exploit attempts on customer sites since August 19, 2026.

The plugin has more than 6 million active installs. Hosts inherited the cleanup, because a license-gated update does not stop PHP from running in uploads and does not delete a webshell already sitting there.

The Empty Slot That Skipped Every File Check

Elementor Pro’s Forms widget is the paid plugin’s builder for contact, job, and support forms. In version 4.2.1 and earlier, it checked an upload’s file type in one loop and saved the file in another. Those loops did not agree about a blank first slot.

When the File Upload field was not marked required, PHP reported that blank slot as UPLOAD_ERR_NO_FILE. The checker treated the empty part as a reason to stop the whole method. The mover treated it as a reason to skip one entry and keep going. A second slot carrying a.php name never hit the extension blocklist, and it still landed on disk.

Patchstack scored the flaw 9.0 and assigned CVE-2026-32475. Its advisory walks through two separate loops with different handling of empty file entries in modules/forms/fields/upload.php. The blocklist itself is not the failure. It names php, phtml, pht, and a long list of other executable types. That check simply never ran on the payload slot.

HOW THE TWO LOOPS TREATED THE SAME UPLOAD

The request is an ordinary form post to /wp-admin/admin-ajax.php with the action elementor_pro_forms_send_form, which the plugin exposes to visitors who are not logged in. Every value the request needs sits in the public page HTML: the post id, the form id, and the field name. Elementor Free does not ship this Forms upload field, so the free plugin is out of scope.

The saved name is not the original filename. It is a 13-character uniqid() string plus the attacker-chosen extension, written under /wp-content/uploads/elementor/forms/. Eight of those characters encode the Unix second and five encode microseconds, so the name is time-based rather than random. The upload reply does not return the path. Form notification emails that print every field can, because the default template includes the file URL.

The only site setup this needed is a published page with a Form widget and at least one File Upload field that is not required. Patchstack notes that Required is off by default, which is the everyday state for “attach a resume” and “attach a photo” forms.

Anchor Hosting’s Founder Found It Independently

Tin Pham, working as TF1T, reported the bug to Patchstack on July 16, 2026. Patchstack confirmed it the same day, assigned the CVE, and told Elementor. The vendor had a patch ready on July 17. Patchstack reviewed that patch on August 3.

Austin Ginder, founder of Anchor Hosting, hit the same logic eight days later. On July 24 he scanned an Elementor Pro 4.2.0 zip, then proved the finding on a clean WordPress site with Elementor Free and Pro before he filed it with Wordfence. Wordfence paid him $15,600. He was not first, and he said so.

This month Wordfence paid me $15,600 for an unauthenticated remote code execution bug in Elementor Pro.

Austin Ginder, founder, Anchor Hosting

He later wrote up the record Wordfence bounty payout and the lab work behind it, and he described it as the largest publicly disclosed single-finding payout from that program that he could see. Wordfence validated the report on July 27 and told the vendor. It later dropped its own CVE number and used Patchstack’s.

The useful part for a hosting desk is not the bounty figure. It is that someone who runs WordPress sites for a living found a no-login remote code bug by looking at a plugin his customers actually use, then had to wait for a vendor release his unlicensed clients could not even download.

Most of a 2.6 Million Site Fleet Stayed Exposed

Elementor shipped 4.2.2 on August 19, the same day the advisory went public. That is fast vendor work. It was not fast enough for the fleet that actually runs the plugin.

Imunify360 published numbers on September 2 from the servers it protects. At disclosure, 2.6 million sites on that network were still on a version the advisory listed as affected, meaning 4.2.1 or earlier. Twelve days later, 84 percent still exposed through the bulk of the campaign. That 84% is Imunify360’s own fleet, not a census of every Elementor Pro site on the internet, and it is still the only public hosting-scale snapshot of the lag.

THE AUGUST WINDOW ON IMUNIFY360 SERVERS

• Affected at disclosure: 2.6 million sites were still on Elementor Pro 4.2.1 or earlier.
• Still on a listed version August 31: 84% of that group had not patched.
• Already on the fixed release: Sites running the patched plugin rose from 100,000 on August 20 to 415,000 on August 31, a separate count from the 2.6 million that started exposed.
• Peak attack day: 431,000 fingerprint requests on August 25.

Most of the lag is structural. Imunify360 said the bulk of those sites run older major versions, so reaching 4.2.2 is a major-version jump rather than a one-click minor update, and Elementor Pro updates need an active license. An expired subscription does not offer the fix. Unpatched sites in that window were not all careless. Plenty were unpaid.

Reverse-Engineering Began the Afternoon of the Fix

Elementor’s own changelog for 4.2.2, dated August 19, lists security enforcement in Form widget as a one-line fix next to a Dynamic Tags note. It does not name CVE-2026-32475. It does not say a logged-out visitor could write PHP into a public folder. A reader who only scans release notes could treat it as a routine hardening pass.

Wordfence said attackers started that same day. The firm’s firewall saw the empty-slot-plus-.php shape as soon as the patched zip was public, which is the usual pattern when a changelog is enough to reconstruct the bug. Over 190,000 blocked attempts is a customer-side number. It is not a count of sites that actually got a shell.

THE DISCLOSURE AND ATTACK CALENDAR

1. July 16, 2026: Tin Pham reports the flaw to Patchstack, which assigns CVE-2026-32475 and tells Elementor the same day.
2. July 17, 2026: The vendor prepares a patch, with release still pending.
3. July 24, 2026: Austin Ginder independently reports the same bug to Wordfence.
4. August 3, 2026: Patchstack reviews the vendor patch and confirms it closes the hole.
5. August 19, 2026: Elementor Pro 4.2.2 ships, the advisory goes public, and Wordfence sees exploitation begin.
6. August 25, 2026: Imunify360 records 431,000 fingerprint requests in one day, more than half of the 757,000 it would count through August 31.
7. September 2, 2026: Wordfence publishes the over 190,000 blocked-attempt figure, and Imunify360 publishes the 84% lag.

Public proof videos showed up within a day of the patch. The first ones were local lab demos that assumed known form ids and even a folder path on the tester’s own machine. Live scanning did not need that. It posted to the public form endpoint and recovered the time-based filename, in some cases from the form’s own confirmation mail.

Write-ups dated October 19 still treated CVE-2026-32475 as a live attack path against leftover 4.2.1 installs. Elementor Pro 4.3.2, released October 13, adds another “improved code security enforcement in Form handling” line. The floor for this CVE remains 4.2.2.

What Hosts Can Block Without a License

Hosts can deny PHP under wp-content/uploads at Apache or Nginx, so a planted.php file will not run even on Elementor Pro 4.2.1. The control needs no Elementor license and no plugin update. Wordfence users get the same outcome from Disable Code Execution for Uploads.

The plugin’s own forms folder is supposed to hold resumes and photos, not scripts. Elementor creates that folder for form submissions. It does not turn PHP off there. On shared servers that still execute PHP inside uploads, the empty-slot trick becomes command execution. On servers that refuse those files, it becomes a junk object in a directory.

SERVER CONTROLS THAT DO NOT NEED A PLUGIN UPDATE

• Apache deny rule: A FilesMatch block for.php,.phtml, and.phar under wp-content/uploads returns 403 instead of running the file.
• Nginx location: A regex location on /wp-content/uploads/.*\.ph(p|tml|ar)$ with deny all does the same job on Nginx.
• Wordfence option: Disable Code Execution for Uploads, in Global Options, is the same control for sites that already run that firewall, and Wordfence says the malicious-upload rule depends on it.
• License check: Confirm every paid Elementor Pro site is on 4.2.2 or later; an expired license will not present that update.

On a PHP-FPM stack, php_flag engine off does nothing, which is why an old.htaccess line that worked under mod_php fails silently on most current hosts. The durable rule is to deny the files at the web server. Patchstack and Wordfence also shipped WAF rules for customers, which covers the sites behind those products and leaves everyone else on the hosting setting.

A PHP File There Means Someone Got In

Updating to 4.2.2 or later closes the hole. It does not delete a file that already landed. Any.php,.phtml, or.phar file under /wp-content/uploads/elementor/forms/ is a strong sign of compromise, because that folder is for form uploads, not scripts. A 13-character lowercase hex name plus.php matches the uniqid() pattern the mover uses.

If one of those files is there, copying it off the site and keeping the timestamps beats deleting first and asking questions later. The shell can have read wp-config.php, so database credentials, salts, and any API keys in that file need rotation, and new administrator accounts around the file’s created time need a look. Logs for POST requests to admin-ajax.php with elementor_pro_forms_send_form, followed by a GET to a new file in the forms folder, close the loop.

WHAT WE KNOW

• The fix version: Elementor Pro 4.2.2, shipped August 19, 2026, aligns the two loops and re-checks the extension before the file is moved.
• The folder test: A PHP file in /wp-content/uploads/elementor/forms/ is not a form attachment and should start cleanup.
• The host control: Denying PHP in uploads turns this bug class into a file that never runs, including on unpatched 4.2.1.

WHAT IS UNCONFIRMED

• Working shells: No public tally shows how many sites actually got a command-executing file, only blocked attempts and fingerprint requests.
• October leftovers: There is no fleet-wide count of how many of those PHP files still sit on disk after the August wave.

Sites that ran 4.2.1 with a public upload form in August should open that forms folder and look for PHP. Then ask the host whether PHP can run under wp-content/uploads at all.