A critical security flaw in Elementor Pro, one of the most widely used premium page-builder plugins for WordPress, could allow attackers to remotely execute code on affected sites without needing any login credentials. The vulnerability, tracked as CVE-2026-32475, affects Elementor Pro versions up to and including 4.2.1 and centers on how the plugin’s Forms widget handles file uploads.

How the Flaw Works

The vulnerability lives in the File Upload field of Elementor Pro’s Forms widget, a feature commonly enabled on contact forms, job application pages, and support request forms across countless WordPress sites. Under normal circumstances, file upload fields are expected to validate that submitted files match an allowed type and reject anything else, particularly executable scripts.

According to the disclosure, the underlying issue stems from a mismatch between how the plugin validates uploads and how it actually processes them. The code runs uploaded files through two separate loops — one for validation and one for processing — and those loops treat empty upload entries inconsistently. By carefully crafting a form submission that includes multiple file entries, some of them deliberately empty, an attacker can cause the validation logic to be bypassed while the processing logic still accepts and stores a malicious PHP file on the server.

Once a PHP file is successfully written to a location the web server will execute, the attacker effectively gains the ability to run arbitrary code in the context of the website — a full remote code execution primitive that could lead to complete site takeover, data theft, or the site being used as a staging point for further attacks.

Exploitation Requirements

Two conditions need to be met for a site to be exploitable. First, the site must have a publicly accessible Elementor Pro form with the File Upload field enabled. Second, the “multiple file uploads” option must be turned on for that field, since the bypass technique depends on submitting several file entries in a single request. Sites that don’t use file upload fields in their forms, or that only allow a single file per submission, are not exposed to this specific technique.

Because no authentication is required to submit a form on a public-facing website, any site meeting these conditions is exposed to remote, unauthenticated attackers — a combination that significantly raises the severity and urgency of the issue. Automated scanning tools frequently probe the web for exactly this kind of exploitable form configuration once a vulnerability like this becomes public knowledge.

Patch Already Available

Elementor has already addressed the flaw. Version 4.2.2, released on August 19, 2026, contains the fix and should be applied immediately by any site running Elementor Pro. Given how quickly vulnerabilities in popular WordPress plugins tend to be weaponized once details circulate, site owners should not treat this as a routine, low-priority update.

Recommended Actions

Website administrators running Elementor Pro should take the following steps as soon as possible:

• Update Elementor Pro to version 4.2.2 or later immediately
• Audit any forms using the File Upload field and confirm whether “multiple file uploads” is enabled
• Review server logs and the uploads directory for unfamiliar PHP files or other unexpected executable content
• Restrict direct execution of PHP files within upload directories at the web server configuration level as a defense-in-depth measure
• Consider disabling file upload fields on public forms entirely if the functionality isn’t strictly necessary

Why This Matters

Elementor Pro’s install base spans millions of WordPress sites, ranging from small business pages to larger commercial operations, many of which rely on contact and application forms as core functionality. A remote, unauthenticated code execution vulnerability in such a widely deployed plugin represents exactly the kind of flaw that opportunistic attackers and automated botnets move quickly to exploit. Site owners who haven’t already updated should treat this patch as time-sensitive rather than something to schedule for a future maintenance window.