A critical vulnerability in the widely deployed Elementor Pro plugin for WordPress can allow unauthenticated attackers to bypass file-type restrictions, upload executable PHP files to a public directory, and potentially achieve remote code execution (RCE) on vulnerable servers.
Tracked as CVE-2026-32475, the vulnerability affects Elementor Pro versions 4.2.1 and earlier and has been assigned a CVSS score of 9.0 (Critical). Elementor addressed the vulnerability in Elementor Pro 4.2.2, released on August 19, 2026.
Technical Analysis
CVE-2026-32475 exists within the File Upload field of the Elementor Pro Forms module, specifically in the handling implemented in modules/forms/fields/upload.php.
Elementor processes uploaded files in two distinct stages.
The first stage performs validation through the validation() function. It verifies that uploaded file extensions match the permitted types configured for the form and checks them against a blocklist containing potentially dangerous extensions such as PHP and other executable formats.
A separate process_field() routine subsequently processes the files and moves accepted uploads into Elementor’s public forms upload directory.
The vulnerability exists because these two routines handle an empty upload entry differently.
When PHP receives an empty file part, it assigns the upload error value:
UPLOAD_ERR_NO_FILE
Inside Elementor’s vulnerable validation logic, encountering such an entry for a non-required field causes the function to return entirely. The validation process therefore stops and does not inspect subsequent files submitted for that field.
The processing routine behaves differently. Instead of terminating, it uses logic equivalent to continue, skips the empty entry, and processes the remaining files.
This creates a security-critical inconsistency: a file that was never validated can subsequently be written to disk.
An attacker can abuse the discrepancy by submitting a specially constructed multipart form request containing multiple file entries for the vulnerable field. An empty entry causes validation to terminate prematurely, while a subsequent malicious file remains available to the processing routine.
As a result, the plugin’s normal extension restrictions can be bypassed and an executable PHP file can be written into:
wp-content/uploads/elementor/forms/
Because this directory is normally web-accessible, execution can occur when the uploaded PHP file is subsequently requested through the web server. The attacker-controlled PHP then executes with the privileges of the web server process.
Why the Vulnerability Can Lead to RCE
Elementor normally uses a blocklist to prevent executable extensions including .php, .phtml, .phps, .asp, .aspx, .exe, and several other potentially dangerous formats.
CVE-2026-32475 does not directly defeat the contents of that blocklist. Instead, it causes the vulnerable code path to skip the validation entirely for the malicious upload.
Once the validation stage has been bypassed, the original extension is preserved when Elementor generates the destination filename.
The file is stored using a generated name based on PHP’s uniqid() function, for example:
wp-content/uploads/elementor/forms/<generated-id>.php
Although the response does not directly reveal the resulting filename, Patchstack notes that uniqid() is time-based rather than cryptographically random. This reduces the difficulty of identifying the resulting file. In certain form configurations, an automated email response may also expose the uploaded file’s URL.
After locating the uploaded PHP file, requesting it through the website causes the PHP interpreter to execute the attacker-controlled content.
From that point, potential attacker actions include:
- deploying a persistent web shell;
- modifying WordPress files or themes;
- extracting database credentials from wp-config.php;
- accessing the underlying WordPress database;
- creating rogue administrator accounts;
- stealing customer or user information;
- redirecting visitors to malicious infrastructure;
- deploying additional malware;
- using the compromised host for phishing, SEO spam, proxy infrastructure, or command-and-control activity;
- attempting lateral movement where the web server has access to additional internal systems.
Exposure Conditions
The primary prerequisite is a publicly accessible Elementor page containing a Form widget with a File Upload field. Its technical analysis additionally notes that the vulnerable validation condition is reached when the field is not marked as required, which is a normal configuration for many upload forms.
Common examples include:
- job application forms;
- customer-support forms;
- document submission portals;
- photo or ID uploads;
- receipt or invoice submission;
- contact forms allowing attachments.
There is, however, an important discrepancy in published exposure guidance.
According to reporting citing an Elementor customer notification, Elementor characterized affected sites more narrowly as those using an Elementor Pro Form containing a File Upload field with the multiple-file-upload option enabled, which Elementor states is disabled by default. Patchstack’s research describes the attack surface more broadly around vulnerable public File Upload fields.
Organizations should therefore avoid relying solely on configuration assumptions. Any internet-facing site running Elementor Pro 4.2.1 or earlier, particularly sites exposing upload forms, should be treated as potentially vulnerable until upgraded and reviewed.
Mitigation
Organizations using Elementor Pro should take the following actions immediately.
1. Upgrade Elementor Pro
Upgrade to Elementor Pro 4.2.2 or later.
Elementor’s changelog confirms that version 4.2.2 was released on August 19 and included improved security enforcement in the Form widget.
The corrected implementation aligns the validation and processing logic and performs additional extension checks immediately before a file is moved.
2. Identify Vulnerable Forms
Inventory Elementor forms that permit file uploads, prioritizing:
- publicly accessible forms;
- optional File Upload fields;
- forms allowing multiple uploads;
- forms that email uploaded-file links back to users.
Disable unnecessary upload functionality until patching and validation are complete.
3. Hunt for Previous Exploitation
Inspect:
wp-content/uploads/elementor/forms/
for unexpected files, particularly PHP or other executable content.
Patching does not delete malicious files uploaded before remediation.
4. Harden WordPress Upload Directories
Where operationally possible, configure the web server so directories intended purely for user uploads cannot execute PHP or other server-side scripts.
This provides an additional security boundary against file-upload vulnerabilities beyond the Elementor-specific fix.
Stay Safe. Stay Secure.
OP Innovate Research Team
