Elementor Pro Patches a Critical File Upload Bug That Enabled Remote Code Execution

Elementor released Elementor Pro version 4.2.2 on August 19, patching a critical vulnerability that let an unauthenticated attacker upload a working PHP file to any WordPress site running the plugin’s Forms widget with a File Upload field enabled. Patchstack disclosed the flaw the same day the patch shipped. It is tracked as CVE-2026-32475 and classified as CWE-434, unrestricted upload of a file with a dangerous type. Patchstack rated it 9.0 out of 10 on the CVSS 3.1 scale, a score Patchstack assigned itself, since NIST’s own National Vulnerability Database entry confirms NIST has not yet published an independent assessment.

Elementor Pro is the paid extension of Elementor, one of the most widely used WordPress page builders. The free core plugin lists more than 10 million active installs on WordPress.org, but Elementor Pro itself is sold and distributed directly from elementor.com as a downloadable zip file rather than through the WordPress.org plugin directory, so it carries no equivalent public install counter. The vulnerable component is the Forms widget’s File Upload field, a feature site owners commonly add to contact, job-application, and support-ticket forms so visitors can attach documents.

Two Loops That Disagree About an Empty File

According to Patchstack’s technical writeup, the bug lives in modules/forms/fields/upload.php. When a form is submitted, one method, validation(), checks each uploaded file’s extension against an allowed list and a hardcoded blocklist that explicitly rejects .php and other executable extensions. A separate method, process_field(), later moves each file that passed validation into a public uploads directory. Both methods loop over the same submitted files, but they treat an empty file entry, an upload part with no filename, which PHP reports as UPLOAD_ERR_NO_FILE, differently. The validation() method exits the entire function the moment it hits an empty, non-required entry, so it never checks any file listed after it. The process_field() method simply skips that one empty entry and keeps moving every file that follows.

Patchstack found that submitting two file parts for the same upload field, an empty one first and a .php file second, lets the second file skip the extension check in validation() entirely while still reaching process_field(), which writes it into wp-content/uploads/elementor/forms/ without checking it again. The blocklist itself is sound and would normally catch a PHP upload. It simply never runs against the file that matters.

Finding the File Without Much Guessing

Because the vulnerable form sits on a site’s public front end, exploitation needs no WordPress account and no user interaction beyond submitting a form. The uploaded file is saved under a name generated by PHP’s uniqid() function, 13 hexadecimal characters that encode the Unix timestamp and microsecond of the request rather than anything random. Patchstack describes two ways an attacker can recover that filename without much brute-forcing. The server’s own Date response header hands over the eight-character timestamp portion directly, leaving only the five-character microsecond portion to narrow down, and that narrows further once an attacker records the moment just before and after the exploit request. The easier route needs no brute-forcing at all: Elementor Pro’s default form-notification template renders every submitted field, including the uploaded file’s URL, and forms with an autoresponder action enabled, common on the same job-application and support-ticket forms that carry file uploads, email that confirmation straight back to whatever address the attacker typed into the form.

A Five-Week Gap Between Report and Patch

Patchstack’s published timeline shows researcher Tin Pham, who uses the handle TF1T, reported the vulnerability to Patchstack, which confirmed it, notified Elementor, and assigned the CVE on July 16. Elementor prepared a patch the next day, and Patchstack confirmed on August 3 that the vendor’s fix actually resolved the issue. Elementor shipped that fix in version 4.2.2 on August 19, the same day Patchstack published its advisory. Elementor’s own 4.2.2 changelog credits the release with “improved code security enforcement” in the Form widget, without naming the CVE directly. Patchstack says the fix brings the two loops into agreement about what an empty file entry means and adds a second extension check directly inside process_field(), immediately before a file is moved, so the blocklist now guards the actual write rather than only the validation pass a crafted request could skip around.

What Site Owners Should Do

Patchstack published its full technical writeup, including the vulnerable code and the exact upload path, on the same day the patch went live, so site owners running Elementor Pro 4.2.1 or earlier should update to 4.2.2 promptly rather than treat this as routine plugin maintenance. Because Elementor Pro does not ship through the WordPress.org directory, keeping it current depends on an active Elementor license connected under Elementor, then License in the WordPress dashboard, so site owners should confirm both their license status and their installed version number directly rather than assume a routine update notice will catch it. Patchstack notes that because the vulnerability is unauthenticated and can leave a file behind on disk, updating closes the hole but does not undo an attempt that already succeeded. Sites that ran a vulnerable version with a public File Upload form should review wp-content/uploads/elementor/forms/ for anything that is not one of the document or image types their own forms actually accept, in particular any file ending in .php.