Elementor Pro CVE-2026-32475: Active Exploitation of PHP Web Shell via Array Validation Bypass

1. Basic Information

• Article Title: Critical Elementor Pro flaw exploited to take over WordPress sites
• Source: BleepingComputer
• Published Date: 2026-09-03
• Original: BleepingComputer
• Related Sources: Wordfence exploitation analysis
• Related Malware, Threat Groups, CVEs, and Products: CVE-2026-32475, PHP web shells, WordPress, Elementor Pro versions 4.2.1 and earlier
• Severity: Critical
• Review Update: 2026-09-05 Content review: Revised block counts and successful compromise counts, unauthorized uploads and code execution, preconditions such as non-required File Upload fields, facts versus inferences, and Japanese terminology. Updated "Victim/Administrator Perspective" to describe events visible in screens, logs, and devices, along with their observation conditions. Clearly defined "Impact on SOCs" as analysis and summarized lessons learned from the case study in a standard format.

2. One-Sentence Summary

Wordfence blocked over 190,000 attack attempts involving PHP uploads that bypassed file validation in Elementor Pro. While this leads to remote code execution in environments where PHP execution is enabled, this count does not represent successful compromises.

3. Attack Flow

Observed Validation Bypass Attempts and Execution Path on Success

1. An unauthenticated attacker sends a multipart request to the File Upload field of a published Elementor Pro Form. The precondition is that the target field is not set as required.
2. The File Upload field is submitted as an array, with the first element leaving the file unselected, which triggers UPLOAD_ERR_NO_FILE.
3. Upload::validation() exits with a return statement, skipping the extension and file type checks for subsequent elements.
4. If the upload succeeds, the PHP file in the subsequent element is saved under /wp-content/uploads/elementor/forms/ with a random name and a .php extension.
5. If PHP can be executed in the save location, the attacker directly requests the file to try to run arbitrary commands. The published block counts do not indicate success at this stage.

4. Attacker Position and Execution Location

• An unauthenticated external attacker who can reach public forms and admin-ajax.php on the target WordPress site. The execution location for PHP is the target web server.

5. Victim and Administrator Perspective

Victims

• Inference: The attack requires no user interaction, and victims may not notice until site defacement or suspicious redirection occurs.

Administrators

• Inference: Web server access logs may show POST requests to /wp-admin/admin-ajax.php. If the WAF or similar tool also records request bodies, it will show the elementor_pro_forms_send_form action alongside a structure where the same File Upload field contains an unselected file element and a .php file element. Access logs without request bodies do not reveal this array structure.
• If the unauthorized upload succeeds, a file with a random name and a .php extension is saved under /wp-content/uploads/elementor/forms/. The mere presence of the file does not confirm successful PHP execution.
• Inference: If the attacker accesses the saved PHP file, direct requests to that file may appear in access logs. Request records alone do not confirm successful PHP execution.
• Inference: In environments where OS command execution reaches process creation monitoring, EDR or similar tools may record shells or download tools launched from processes handling PHP.

6. Success and Failure Conditions

Success Conditions

• Elementor Pro version 4.2.1 or earlier is running.
• A public page contains an Elementor Pro Form with a File Upload field that is not set as required.
• Achieving remote code execution requires PHP execution to be enabled in the upload directory.

Failure / Risk Mitigation

• Update to fixed versions 4.2.2 or later.
• Disable script execution, such as PHP, in the upload destination directory. This is distinct from preventing unauthorized file saving itself.
• Block the upload of executable files using a WAF or similar controls. Do not uniformly block legitimate form submissions simply because they use an array format.

7. What Happens on Success

• If the attack succeeds, arbitrary code and commands may be executed on the web server.
• A PHP web shell may be installed, allowing continuous access to the site.
• Inference: This can lead to site defacement, theft of credentials or database information, and malware distribution to visitors. These impacts cannot be determined from the published block counts.

8. Observable Logs

• Email: N/A
• Proxy/SWG/DNS: Web server, reverse proxy, and WAF logs: multipart POST requests to admin-ajax.php and GET requests to PHP files under uploads/elementor/forms/. DNS logs alone cannot confirm paths or request bodies.
• Endpoint/EDR: Inference: Confirm the creation and execution of PHP files under uploads, and check for shells or download tools launched from php-fpm or Apache/other web processing PHP. Examine the process lineage based on the actual configuration.
• Identity/IdP: Inference: Check for unauthorized creation of WordPress administrators or logins after a compromise.
• SaaS/Cloud: WAF logs showing blocked file uploads.
• SaaS/Cloud: Inference: Check file audits on the hosting infrastructure and WordPress operational audits.
• Network: Inference: Check for C2 traffic or file retrieval from the web server to unknown destinations.

9. Attack Success Determination

The following criteria are used to investigate individual environments and do not imply that success at all stages was observed in the article.

• Attack Attempt Observed (Success Unconfirmed): Identify crafted multipart requests. WAF block records are evidence of attempts and are not counted as successful compromises.
• User Interaction Confirmed: N/A. No user interaction is required, and this stage is not considered confirmed.
• Initial Execution Confirmed: Confirm the execution of the PHP code placed by the attack. If only file writing occurred, record it as an unauthorized upload success with unconfirmed execution, and do not escalate to this stage.
• Malware Execution or Authentication Success Confirmed: Confirm PHP web shell processing or command execution using related child processes, execution logs, command outputs, or generated artifacts. Simple GET requests are not definitive.
• Information Theft or Session Compromise Confirmed: Confirm that the attacker retrieved and exfiltrated database information or credentials.
• Lateral Movement / Subsequent Compromise Confirmed: Confirm site defacement, additional backdoors, or internal lateral movement resulting from the attack.

10. Investigation Playbook

Inference: Investigation proposals based on the article's observations and feature descriptions.

• Trigger: Running a vulnerable version, abnormal form submissions, suspicious PHP files under uploads.
• Initial Check: Preserve plugin versions, form settings and publication periods, access logs, WAF logs, file contents, and timestamps.
• Endpoints: Investigate uploads/elementor/forms/, core WordPress and plugin diffs, PHP execution processes, and their child processes.
• Authentication & Cloud: Check for unauthorized use of WordPress administrators, hosting infrastructure, and database credentials.
• Subsequent Activity: Track additional web shells, defacement, outbound traffic, and malware distribution to visitors.
• Containment: Preserve evidence, isolate and update the target site, and disable PHP execution in upload directories. Remove suspicious files and rotate potentially exposed credentials.
• Determination Categories: Differentiate between attack requests, successful unauthorized uploads, PHP execution, OS command execution, information theft, and subsequent compromise. File writing alone does not constitute successful execution.

11. Defense and Detection Ideas

Inference: Operational application ideas below. Do not conclude a successful compromise based solely on matching individual logs or IOCs.

• Single Event: Suspicious requests where the same File Upload field uses an array, with the first element unselected and subsequent elements containing .php files.
• Single Event: Suspicious PHP file creation under uploads/elementor/forms/.
• Time-Series Correlation: Correlate crafted POST requests → PHP creation → direct GET requests → execution artifacts → outbound traffic.
• Threat Hunting: Search for requests to admin-ajax.php and suspicious PHP files under uploads from August 19 onward.
• Log Gaps: Lack of request bodies, file creation records, or PHP execution logs makes it difficult to distinguish between validation bypass attempts, successful saves, and successful execution.
• Prioritized Actions: Simultaneously perform emergency updates, disable script execution in upload directories, and check for signs of compromise.

12. Facts / Inference / Hypothesis

Facts

• CVE-2026-32475 is an unauthenticated arbitrary file upload vulnerability related to Upload::validation() in Elementor Pro 4.2.1 and earlier, which was fixed in version 4.2.2.
• When the first array element results in UPLOAD_ERR_NO_FILE, the validation loop exits with a return statement instead of continue, skipping extension and file type checks for subsequent files.
• Wordfence has shown actual attack requests where the first element has no file selected and the second element contains a .php file.
• Successful exploitation requires at least one Elementor Pro Form on a public page containing a File Upload field that is not set as required.
• Upon successful upload, PHP files are saved under /wp-content/uploads/elementor/forms/. In environments where PHP can be executed, this leads to command execution via direct requests.
• Wordfence observed attacks starting from the disclosure date of August 19, 2026, and blocked over 190,000 attack attempts. Activity concentrated particularly between August 19 and 23.
• The 190,000+ figure represents blocked attack attempts, not successful compromises or victim site counts.

Inference

• Correlating form submissions, suspicious PHP file creation, and access to those PHP files serves as a clue to suspect execution. However, access logs alone cannot confirm successful PHP or OS command execution; evidence such as execution records, responses, or generated artifacts is required.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Further Investigation."

13. MITRE ATT&CK Mapping

• T1190 Exploit Public-Facing Application (High): Corresponds to attack attempts targeting file validation bypass in public forms.
• T1505.003 Server Software Component: Web Shell (High): Observed attack requests aim to deploy PHP web shells. Installation and execution success on individual sites must be verified separately.
• T1059.004 Command and Scripting Interpreter: Unix Shell (Medium): Corresponds to invoking OS shells from installed PHP web shells on Unix-based servers. This does not imply that OS or command execution was confirmed across all sites.

14. Unknowns and Further Investigation

• The exact number of successfully compromised sites and the attacker attribution.
• The full variety of PHP payloads used in the attacks.
• The scope of persistence and information theft after web shell installation.

15. Impact on SOCs and Organizations

Exploiting this vulnerability requires a vulnerable version combined with a public form containing a non-required File Upload field. Organizations should review both product deployment status and public feature configurations.

Along with updating to version 4.2.2 or later, organizations should retroactively investigate suspicious PHP files under /wp-content/uploads/elementor/forms/, crafted requests to admin-ajax.php, and access from known attacking IP addresses. File saves and PHP execution successes should be evaluated separately.

16. Summary by Role

• For SOCs: Correlate form submissions, suspicious PHP creation, direct access, and execution artifacts. Do not judge code execution as successful based solely on upload success or GET requests.
• For Administrators: Update to version 4.2.2 or later and disable PHP execution in upload directories. Check for suspicious files and additional web shells.
• For Users: No user interaction is required for the attack. If you notice site defacement or suspicious redirections, report them to the site operators.