SURIQ
Updating Elementor Pro to 4.2.2 closes CVE-2026-32475. It does not tell you whether someone already used the hole while it was open. That gap, between patching and knowing, is the story here, because the flaw drops a live PHP file into a public folder and the update leaves that file exactly where it landed.
The flaw rates CVSS 9.0 and lives in the file-upload field of the plugin's form builder. Security researcher Tin Pham, working through the Patchstack bug bounty program, showed that an unauthenticated visitor can drop a PHP file into a site's public uploads area and then execute it. All it takes is one published page carrying an Elementor form with a file-upload field. No account, no non-default option. Elementor had a fix ready the day after the July 16 report, Patchstack confirmed it on August 3, and 4.2.2 went out on August 19. Everything up to and including 4.2.1 is vulnerable. No one has reported real-world exploitation yet, but with the details and the patch both public, the safe assumption is that opportunistic scanning follows.
How a blank upload slips past the filter
The form handler runs two passes over an upload. The first pass checks each file against a list of banned extensions; the second writes the survivors to disk. They part ways on an empty upload slot. Per Patchstack's analysis, a blank first slot makes the checking pass conclude that nothing was sent and stop, so it never looks at the slots queued behind it. The writing pass simply steps over the blank slot and carries on, so the next slot's PHP payload lands in the public folder at wp-content/uploads/elementor/forms/. One request, two passes, two contradictory readings.
None of this is exotic. It is a parser desync, the same family as HTTP request smuggling, where two components that must agree on how to read one input quietly disagree. For anyone who maintains upload code, the takeaway is that betting on an extension blocklist is betting on the wrong layer. Hardening the .php block changes nothing when the payload sails past the check entirely. What 4.2.2 does instead is settle the file set in a single pass and feed the identical list to both the check and the write.
Why the upload path is not a secret
A defender's instinct is that even if a file lands, an attacker still has to find its URL, and the filename looks random. It is not random. Elementor names the uploaded file with PHP's uniqid(), which is derived from the server clock, not from a cryptographic source. The eight hex digits that encode the seconds are handed to the attacker in the server's own Date response header, leaving only a few microsecond digits to brute force. Where the form also has an autoresponder email action turned on, the confirmation email sent to the attacker's own address discloses the exact upload URL, and the guessing drops to zero. Treating an unguessable path as a control is false comfort. Time-based identifiers are not secrets, and a lot of upload code leans on them as if they were.
Patch to 4.2.2, then go looking for what it left behind
Start with the update: move every site running Elementor Pro to 4.2.2 or later. That is step one, not the finish line. If an unpatched build was live while a public upload form sat on the site, treat the uploads directory as a scene to examine. Open wp-content/uploads/elementor/forms/ and treat any PHP file, or any type your forms were never built to store, as suspect. A script sitting in that folder is not a false positive.
The stronger position is not to rely on remembering to look. A new executable file appearing under an uploads directory is a high-fidelity signal on its own, and reading it does not require knowing this CVE existed. File-integrity monitoring that watches web-writable directories and alerts on a fresh .php file catches this drop the moment it happens, and it catches the next form plugin's version of the same mistake too. We have watched this pattern before: a Joomla page-builder flaw where the patch would not evict the intruder, and a WordPress backdoor that slipped past file scanners. Patching is a point-in-time fix. Monitoring is what tells you the window was clean.
Stop upload folders from running PHP
The control that survives the next plugin bug lives below the plugin, at the web server. An uploads directory has no reason to execute PHP, so configure the server to refuse it: on Apache, deny script handling under the uploads path; on Nginx, decline to pass files in that path to the PHP interpreter. With that in place a dropped webshell is inert text, whatever plugin let it through. On shared and multi-tenant hosting the stakes climb, because one vulnerable form on one tenant's site becomes one webshell and a foothold to pivot from. This is the same class of exposure behind mass campaigns that turn unpatched CMS plugins into webshells, and it is why the server-level control outlasts any single patch. Elementor puts the free plugin above ten million active installs; the paid tier that carries this flaw is a large subset of that, and the form-with-upload precondition is common.
This one is cheap to fix and cheap to verify. Update today, read the forms folder once, and deny PHP in your upload paths so the next form-builder bug is a non-event rather than an incident.