Elementor Pro 4.2.2 Fixes Unauthenticated File Upload to RCE

A critical security update for the Elementor Pro WordPress plugin fixes a vulnerability that let anyone on the internet upload a PHP file and run code on a website without logging in. The flaw, tracked as CVE-2026-32475 with a CVSS severity score of 9.0 out of 10, was discovered and reported to Patchstack by researcher Tin Pham, also known as TF1T. Elementor Pro version 4.2.1 and all earlier versions are affected, and the patch was released on August 19, 2026 in version 4.2.2. Patchstack published its advisory on the same day and has issued mitigation rules for its customers.

Elementor Pro is a popular premium extension for the Elementor page builder, which many WordPress site owners use to design pages without writing code. Among its features is a Forms widget that lets site owners create contact forms, job application forms, and support ticket forms. Those forms can include a File Upload field so visitors can attach documents. That field is where the problem lives.

The vulnerability comes from how the plugin handles uploaded files in two separate steps. In version 4.2.1 and below, the Forms module first checks the file extension in one loop of code, and then moves the file to a public folder in a second loop. These two loops treat empty file entries differently. An empty file entry is an upload part with a blank filename, which PHP reports with the error code UPLOAD_ERR_NO_FILE. The validation loop, which checks the file type, has an early exit: if the field is not required and it sees an empty entry, it returns immediately and stops checking any further entries. The processing loop, which moves the files, only skips that empty entry and continues on to the next one. That mismatch is the core bug.

To exploit it, an attacker submits two file parts for the same upload field. The first part is empty, with a blank filename. The second part is a file with a .php extension. The validation loop sees the empty first entry and returns without ever checking the second entry's extension. The processing loop skips the empty entry and then moves the .php file into the public uploads directory. The plugin's intended defense is an extension blocklist that rejects PHP and other executable file types, but because the validation loop stops early, that blocklist never runs on the second file. The file is then saved in the folder wp-content/uploads/elementor/forms/ with a random-looking name based on PHP's uniqid() function, which generates a time-based identifier. The attacker's original filename is discarded, but the .php extension is kept. That means the file can be requested directly by its URL, and the server will run it as PHP code, giving the attacker remote code execution.

The only requirement for a successful attack is that the target website has at least one published Elementor page containing a Form widget with a File Upload field. This is a very common configuration for job application forms or support ticket forms. The field's "Required" option is off by default, so no special setting is needed. All the values the attacker needs, such as the post ID, the form ID, and the field name, are visible in the public page source code. The upload is sent through the elementor_pro_forms_send_form AJAX action, which does not require a login session or a nonce security token.

Because the upload response does not tell the attacker where the file was saved, the attacker must recover the exact filename. The filename uses PHP's uniqid() function, which is not random but based on the current time. The first 8 characters come from the Unix timestamp of the second the upload happened, and the last 5 characters come from the microsecond part. An attacker can often narrow this down using the server's date header and the timing of their own request, then brute-force only the few possible microsecond values. There is also a zero brute-force method if the form has an autoresponder email action enabled, which is common on job application and support forms. Elementor Pro's default email template includes a line with the exact URL of every uploaded file, so the attacker receives their own email with the file location.

Websites using Elementor Pro should update to version 4.2.2 or later immediately. The patch makes the two loops agree on what an empty file entry means, so an entry cannot slip past the validator while still being moved by the processor. The updated version also re-checks the file extension inside the processing loop right before the file is moved, so the blocklist now guards the move step directly. Updating only closes the hole for future attacks; it does not remove a malicious file that was already uploaded before the patch. Site owners who ran a vulnerable version with a public file upload form should review the wp-content/uploads/elementor/forms/ folder for any .php files that do not belong there. Patchstack customers are already protected by mitigation rules.

For website owners on managed WordPress hosting, services such as AEU Hosting can help keep the underlying platform secure, but the required fix is still to update the Elementor Pro plugin to version 4.2.2 or newer. Managed hosting can simplify updates and provide security monitoring, which reduces the chance of a vulnerable plugin being exploited in the first place.

The timeline reported by Patchstack shows the disclosure process: on 16 July 2026, the researcher reported the vulnerability; on the same day Patchstack confirmed it, contacted the vendor, and assigned CVE-2026-32475. The vendor prepared a patch on 17 July, Patchstack reviewed and confirmed it on 3 August, and the final version 4.2.2 was released on 19 August 2026, when the advisory was published.

This is a classic desynchronization flaw: the code that decides whether an upload is allowed and the code that moves the upload use different rules for the same data. The fix makes both loops share the same view of which entries are real uploads, closing the gap that turned a restricted file upload field into an unauthenticated remote code execution primitive.