absholi7ly/elementor-pro-unauthenticated-arbitrary-file-upload-to-rceCVE-2026-32475 The Elementor Pro Forms File Upload field handles validation and file processing in two separate loops with different handling of empty upload entries (UPLOAD_ERR_NO_FILE). An unauthenticated attacker can submit a multipart
The Elementor Pro Forms File Upload field handles validation and file processing in two separate loops with different handling of empty upload entries (UPLOAD_ERR_NO_FILE). An unauthenticated attacker can submit a multipart request with an empty first file part followed by a PHP payload for the same field, causing validation() to return early while process_field() still moves the PHP file into a public directory: wp-content/uploads/elementor/forms/.php
Automatically retrieves the post_id, form_id, and field_id from the target page:
python poc.py -t http://localhost/wp --page-url "http://localhost/wp/?page_id=16" -c "whoami"
Or:
python poc.py -t http://localhost/wp --page-id 16 -c "whoami"
Start an interactive session:
python poc.py -t http://localhost/wp --page-id 16 -i
The core of the vulnerability is bypassing the file upload mechanism itself. This part does not differ whether you perform the test in a local lab or against a real server: the empty first file part + PHP payload in the upload field bypass extension validation, yet the file is still processed by process_field(). We demonstrated that the file is successfully written, which is exactly what it describes.
Regarding the hardcoded Laragon path:
That was only to facilitate local verification.
On the real target, the directory pattern is known and fixed:
/wp-content/uploads/elementor/forms/
What is not fixed is the final filename.
Elementor does not retain the original filename. In process_field(), the stored filename is generated as follows:
Therefore, if you upload shell.php, the filename may become something like:
66f3a1c2e9b47.php
inside:
/wp-content/uploads/elementor/forms/
uniqid() is time-based and is not a strong random value; it is based approximately on the timestamp + microseconds. Therefore, recovering the file remotely becomes a filename discovery problem rather than an upload problem.
For example, you can use a timing window based on the server's Date header and request timing, search within a narrow range around the upload time, or recover the exact URL if the form sends an email containing [all-fields].
I kept the PoC focused on proving the core issue itself, which is unauthenticated file upload, clearly and directly. Fully explaining the remote recovery of the uniqid() value would make the demonstration much longer than necessary to validate the vulnerability itself.