## https://sploitus.com/exploit?id=1BE58F90-6785-5F3E-B5C2-337E17ED292D
# CVE-2026-32475 PoC : Elementor Pro Unauthenticated Arbitrary File Upload to RCE
**Elementor Pro Pre-Authentication Arbitrary File Upload Leading to Remote Code Execution**
Proof-of-concept for CVE-2026-32475, a critical unauthenticated arbitrary file upload in Elementor Pro's Forms module that ends in remote code execution. The PoC submits two file parts for the same upload field — an empty first entry (blank filename, triggering `UPLOAD_ERR_NO_FILE`) followed by the payload. The `validation()` loop exits early on the empty entry via `return` while `process_field()` skips it via `continue`, so the payload is never extension-checked and lands in a public directory with a `.php` extension. PoCs testing the corrected behavior, the same request after patching, must be dropped by the extension check.
> **Note:** This PoC is for authorized security testing and research only. CVE-2026-32475 is being actively exploited in the wild, and Wordfence has blocked 190,000+ attempts since the August 19 disclosure. You are responsible for complying with all applicable laws and obtaining written authorization before testing any system.
---
## Vulnerability Information
- **CVE**: CVE-2026-32475
- **Type**: CWE-434 Unrestricted Upload of File with Dangerous Type
- **CVSS 3.1**: 9.0 (Critical, `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`)
- **Authentication**: Unauthenticated (pre-auth, remote, low attack complexity)
- **Active exploitation**: Yes (same-day weaponization; 190,000+ blocked attempts Aug 19–23)
- **Affected software**: Elementor Pro (commercial WordPress plugin), versions ` HTTP 200
[*] result: vulnerable - upload accepted
response : {"success":true,"data":{"message":"Your submission was successful.","data":[]}}
uploaded to : /wp-content/uploads/elementor/forms/.php
[+] CONFIRMED EXECUTION: 6a9bb5d70fba6.php -> 'POC3f9a2c...'
[*] done: 1/1 vulnerable
```
A `success:true` on the AJAX response means the payload was accepted **without** being extension-checked. Step 4 with `--brute` (a `200` on the guessed `.php` file containing the marker) confirms server-side PHP execution — i.e. full RCE.
Result statuses: `vulnerable` | `patched` | `unknown` | `error`
- `vulnerable` — web server returned `"success":true`; the payload skipped the extension check
- `patched` — the upload was rejected with a file-type error (extension check ran)
- `unknown` — HTTP succeeded but the response was not `success:true` (wrong IDs or unexpected state)
- `error` — request/parse failure (timeout, non-200, form not found)
---
## Payload Behavior & WebShell Notes
- The stored filename is always `.` — the submitted basename is discarded, so double-extension/null-byte tricks are irrelevant; only the extension check matters, and it is the thing that breaks.
- Elementor ships an `.htaccess` in `wp-content/uploads/elementor/forms/` that sets `Content-Disposition: attachment` on all files. **This does not stop execution** — PHP still runs server-side and the downloaded response is the executed output. To render a shell in-browser in a lab, disable that `.htaccess`; in the real world treat it as cosmetic only and rely on server-level PHP blocking.
- `uniqid()` is time-derived (Unix seconds + microseconds). The brute step brackets the server-side `Date` header; a marker-bearing response confirms execution. The worst case is ~1M microsecond guesses per second.
---
## Detecting / Verifying a Compromise
```bash
# PHP files that should not exist in the uploads dir
find wp-content/uploads/elementor/forms/ -type f -name "*.php*"
```
- Treat any `.php`/`.phtml`/`.phar`/`.hta` file under the forms directory as evidence of compromise.
- Search access logs for `GET` under `/wp-content/uploads/elementor/forms/` and `POST` carrying `elementor_pro_forms_send_form`.
- If a shell executed, look for rogue admins, `mu-plugins`, modified core/theme files, and unexpected WP-Cron events; prefer restoring a known-good backup over cleaning in place.
---
## Mitigations
- Upgrade to Elementor Pro **4.2.2** or newer. Elementor Pro updates are delivered by Elementor's own service — a lapsed licence will not offer the update.
- If you cannot patch immediately, block PHP execution inside the uploads directory at the web-server layer (nginx `location` rule or Apache ``). This is the durable fix and degrades this and future upload bugs to "disk wasted".
- Enumerate published forms; restrict accepted file types; remove unused upload fields.
- After upgrading: scan the uploads directory, review admin accounts, and audit logs for the action `elementor_pro_forms_send_form`.
---
## References
- [Patchstack — Critical Unauthenticated File Upload to RCE in Elementor Pro](https://patchstack.com/articles/critical-unauthenticated-file-upload-to-rce-in-elementor-pro-plugin/)
- [Wordfence — Attackers Actively Exploiting Critical Vulnerability in Elementor Pro](https://www.wordfence.com/blog/2026/09/attackers-actively-exploiting-critical-vulnerability-in-elementor-pro-plugin/)
- [MagicWP — CVE-2026-32475: Elementor Pro Arbitrary File Upload](https://magicwp.io/blog/cve-2026-32475-elementor-pro-file-upload)
- [NVD — CVE-2026-32475](https://nvd.nist.gov/vuln/detail/CVE-2026-32475)
- [dev.to — Active Exploitation of PHP Web Shell via Array Validation Bypass](https://dev.to/anoymask/elementor-pro-cve-2026-32475-active-exploitation-of-php-web-shell-via-array-validation-bypass-581k)
- [deniz.in — Elementor Pro RCE: unvalidated file uploads fixed in version 4.2.2](https://deniz.in/elementor-pro-rce-unvalidated-file-uploads-fixed-in-version-4-2-2)