Critical Vulnerability in Elementor Pro allows CERs for file uploading without authentication

Security researchers have published details of critical vulnerability in Elementor Pro - registered as CVE-2026-32475- that allows an unauthenticated attacker to upload dangerous files and, in common scenarios, get remote code execution (CERs) on WordPress sites using vulnerable plugin. The failure has a CVSS score of 9.0 / 10.0 and affects all versions of Elementor Previous Pro and up to 4.2.1; the manufacturer released a patch in version 4.2.2 on August 19 following the report of the researcher Tin Pham through the Patchstack reward program.

What is confirmed: vulnerability lies in the file uploading field of the Elementor Pro Forms module. The file extension check and the file movement uploaded to the public directory are run in two separate loops and treat empty file entries differently. An attacker can send two parts (multipart) with the same field name; that tactic jumps the extension lock list and causes a PHP file to end in wp-content / uploads / elementor / forms /< uniqid > .php, where < uniqid > is the value returned by PHP uniqid (). The discoverer and Patchstack have verified that this flow converts an apparently restricted upload control into an CERs vector when the server interprets and runs PHP files from that directory.

Necessary conditions (confirmed): to exploit the failure it is only necessary that the site has at least one published Elementor page that includes a Form widget with a file upload field. The field is usually in its default configuration with "Required" disabled, so it is a very common configuration (use forms, support tickets, attachments, etc.). The attacker is not required to have an account on the site.

How it works technically (vector reconstruction): when receiving a multi-part / form-data form, the Elementor code validates extensions from each part and then moves the accepted file to the public route. If the server receives two parts with the same field name, one can be processed as "empty" by the first loop (skipping the extension check) and the other can be the one that finally moves to the public destination without reapplying the lock list. This logical gap between validation and persistence allows a file with .php extension (or with embedded payload PHP) to end up in the public directory and be executable by the PHP server engine.

Actual consequences: successful operation allows you to upload a web shell or any PHP script with malicious content that, when requested by the attacker, will run code on the web server with the same privileges as the PHP process. In practice this can result in defacement, persistence with back doors, malware deployment (e.g., droppers that spread ansomware), use of the site as malware distribution or command and control node, and exfiltration of data. Given the extensive use of forms with attachments, the vector is applicable to a large number of sites using Elementor Pro with exposed forms.

What is not confirmed (uncertainties): until publication there are no verified public data on wild mass exploitation (zero-day) before the patch. Nor has the exact number of vulnerable production facilities been quantified or whether there are variants of the explosion that require different environments. It is reasonable to estimate that sites without automatic updates and with public forms are likely targets, but the actual scope of targeted attacks remains uncertain.

Immediate and prioritized actions for managers: the most urgent and recommended action is to update Elementor Pro to version 4.2.2 or later. If the update cannot be applied immediately, implement at least one of these time mitigation measures:

- Disable or temporarily remove any Form widget that includes a Upload File on public pages until the patch is applied.

- Block PHP execution in the affected directory(wp-content / uploads / element / forms). On Apache / Nginx servers you can prevent the server from treating .php files there through a configuration directive or a html access; this prevents an uploaded .php from being interpreted as a code even if it exists on disk.

- Inspect and clean upload directory: look for .php files in wp-content / uploads / element / forms and in general in wp-content / uploads. For example, from console: find wp-content / uploads / elementor / forms -type f -name '* .php' -maxdepth 1 (setting according to your environment). If you find PHP files that should not be, treat them as a sign of commitment: move them out, change names and analyzes in a safe environment, and review timstamps and access logs.

- Review records and accounts: check web access logs for requests to elementor / forms / * .php routes and review the list of users, sessions and recent changes; if there is suspicious activity, consider temporary site blocking and forensic analysis. Change administrator and FTP / SSH keys if there is evidence of intrusion.

- Add WAF / ModSecurity rules to filter suspicious multipart uploads (for example, requests with two parts with the same file name or with .php extensions in upload fields). Although not infallible, a WAF can mitigate automated attempts.

- Scanning the site with specialized tools: use WordPress-oriented security scanners such as WPScan or endpoint / antimalware solutions (Wordfence, Sucuri, etc.) and web shells search tools. Also perform an audit of plugins and topics to detect unauthorized modifications and unknown plugins.

Medium-term context and recommendations: this incident coincides with other recent vulnerabilities in the WordPress chain that have allowed CERs through malicious file uploads, so it is urgent for administrators to adopt robust patch management policies, principle of less privilege and segmentation. Block execution of scripts in uploads directories is a hardening practice that reduces the impact of similar failures. For more technical information on public vulnerability and CVE entry, see the tab in the NIST / NVD: https: / / nvd.nist.gov / vuln / detail / CVE-2026-32475, and details and context of the discovery on the researcher's platform through Patchstack: https: / / patchstack.com /.

Conclusion: the incorrect logic between validation and persistence in a form component turns a daily entry point into a high-risk vector. Updating Elementor Pro 4.2.2 is the immediate and definitive measure; meanwhile, disable exposed climbing fields, ban the execution of PHP in uploads and actively scan for webshells are concrete steps that significantly reduce the risk of commitment.