Unauthenticated arbitrary file upload leading to remote code execution in Elementor's Elementor Pro plugin

Unrestricted Upload of File with Dangerous Type vulnerability in Elementor Elementor Pro allows Using Malicious Files. This issue affects Elementor Pro: from n/a through 4.2.1.

• Elementor Elementor Pro, distributed as a WordPress plugin, is affected from n/a through 4.2.1 under the supplied lessThanOrEqual condition.
• The normalized affected data gives the default status as unaffected outside the described range and marks a change to unaffected at 4.2.2.
• Patchstack identifies 4.2.2 as the patched release for the affected branch.
• The record names one affected product and does not independently establish the status of parallel branches or later versions beyond the information above.

This is a CWE-434 vulnerability in the Elementor Pro Forms module, specifically modules/forms/fields/upload.php. The validation() handler walks the submitted files and checks each extension against an allowlist and a blocklist of dangerous types. process_field() then walks the same data to move files into a public upload directory, but the two loops handle empty file entries differently. In a specially formed multipart request, an empty entry with UPLOAD_ERR_NO_FILE can cause validation() to return early and skip a later dangerous file, while process_field() continues and moves that file. The submitted extension is retained in the generated filename, so a PHP file can be written into the public forms directory and subsequently processed by the server. The reachability condition is a published Elementor page containing a Form widget with a File Upload field; the advisory states that the request can be sent through elementor_pro_forms_send_form without cookies or a nonce.

The vulnerability is reachable over the network, requires no authentication, and does not require user interaction. The supplied record marks attack complexity as high, so exploitation requires a specific condition or request shape rather than an ordinary single-file upload. The important deployment prerequisite is a public Elementor Form with a File Upload field. The supplied record has known_exploited set to null and public_exploit set to false, but Patchstack's current database page displays a "Known to be exploited! (KEV)" label; the exploitation metadata is therefore conflicting and should be treated as unresolved. The available evidence does not identify a named campaign, victim, or specific exploit artifact.

Successful exploitation can turn the restricted upload feature into a remote code execution primitive on the WordPress server. Because the request does not require authentication, a site with the relevant public form can be attacked without first obtaining a user account. Executed code may run with web server privileges and can therefore potentially affect the confidentiality, integrity, and availability of the site or data accessible to that account. The actual privilege boundary, ability to reach other services, and broader organisational impact depend on server configuration, filesystem permissions, and isolation controls. The requirement for a public upload form and the high attack complexity limit applicability, but they do not remove the risk on sites that meet those conditions.

A successful attack can place a PHP file in a public upload directory and cause server-side code to execute with the web account's privileges. This could let an attacker modify site content or configuration, access data readable by the server account, or disrupt service. The practical impact depends on the WordPress and web server permissions, isolation controls, and other defenses in the deployment. The record does not establish a specific compromise, but updating the plugin does not automatically remove a malicious file that may have been created before remediation.

1. Update Elementor Pro to 4.2.2, the fixed release identified for the affected branch.
2. If an immediate update is not possible, apply Patchstack's mitigation rule to block attacks while the update is being scheduled. The available evidence does not provide another vendor-specific manual workaround.
3. On sites that ran an affected version and exposed a public File Upload field, inspect wp-content/uploads/elementor/forms/ for unexpected files, especially .php files or types outside the documents and images accepted by the forms.
4. If suspicious files or evidence of code execution are found, follow the organization's incident response process; do not assume that updating the plugin removes changes created while the vulnerability was present.
5. Do not infer that all parallel branches or all later versions are covered unless the corresponding vendor update guidance has been verified.

1. Inventory WordPress sites running Elementor Pro and identify sites with published pages containing a Form widget with a File Upload field.
2. Compare installed plugin versions with the affected range in the record, prioritizing sites that expose upload forms publicly.
3. Inspect wp-content/uploads/elementor/forms/ on sites that ran an affected version for files inconsistent with the document or image types accepted by the forms, especially files ending in .php.
4. As a precautionary review, correlate web and application logs for unauthenticated requests to elementor_pro_forms_send_form followed by requests to the public forms directory. These are defensive review points, not confirmed indicators of compromise.
5. Do not treat the absence of suspicious files or related log entries as proof that a site was not exploited.