Vulnerability · Web Application Security

Critical Elementor Pro Flaw Exploited to Take Over WordPress Sites

September 4, 2026 · 5 min read

On August 19, 2026, Elementor shipped version 4.2.2 of its Pro plugin with a quiet changelog note about improved code security in the Form widget. Within four days, Wordfence had blocked more than 190,000 exploitation attempts against that exact fix. The underlying flaw, CVE-2026-32475, carries a CVSS score of 9.8 from Wordfence and 9.0 from Patchstack, the researcher who found it. Both ratings land squarely in critical territory, and the attack requires no authentication whatsoever. If your site ran Elementor Pro through version 4.2.1 with a file upload field in any published form, you were exposed from the moment the patch and the public write-up landed at the same time.

What actually happened

The vulnerability lives inside Elementor Pro's Forms module, specifically the File Upload field. The root cause is a logic mismatch between two separate validation and processing loops. One loop handles the case where a file part is empty (UPLOAD_ERR_NO_FILE) differently than the other, and an attacker can exploit that inconsistency by crafting a multipart request with an empty first file part followed by a PHP payload. The extension blocklist that is supposed to reject dangerous file types gets bypassed entirely, and the PHP file lands in a publicly accessible path under wp-content/uploads/elementor/forms/. From there, the attacker sends a plain HTTP request to that path and executes arbitrary server-side commands. That is a full remote code execution chain from an unauthenticated starting point.

Patchstack discovered the flaw and coordinated disclosure with Elementor. The patched version, 4.2.2, was released on August 19, 2026. Elementor notified subscribers directly, clarifying that only sites using an Elementor Pro form with a file upload field were at risk. That scoping detail is worth holding onto, because it changes remediation priority for multi-site operators, but it does not reduce the severity for anyone who does fall in scope. A published form with a file upload field on a site running any version through 4.2.1 was a standing invitation for unauthenticated code execution. Wordfence telemetry recorded over 190,000 blocked attempts between August 19 and August 23 alone, which tells you that threat actors were scanning and hitting at scale within hours of public disclosure.

"Improved code security enforcement in Form widget" — Elementor Pro 4.2.2 changelog

Why this should matter to you even if you don’t run Elementor Pro

Elementor's free plugin has more than 10 million active installs. The Pro version adds the Forms module with the file upload capability, so the exposed population is a meaningful subset of that base, but it is still an enormous attack surface spread across shared hosting environments, small business sites, and enterprise WordPress deployments alike. This pattern repeats constantly in the WordPress plugin ecosystem: a widely deployed commercial plugin ships a critical flaw, a patch and a CVE drop at the same time, and mass exploitation follows within hours because the CVE itself tells attackers exactly where to look.

The precondition here deserves specific attention. You need a published Elementor Pro form with a file upload field for the attack to work. That sounds narrow, but contact forms with file attachment options are common across industries: support portals, job application pages, client intake forms, document submission workflows. If you manage a portfolio of WordPress sites, the honest question is whether you know which of them have Elementor Pro forms with file upload fields active right now. In most organizations I have seen, that inventory does not exist in any reliable form, which means you cannot quickly triage who was actually exposed.

There is a broader architectural point worth making here. Arbitrary file upload to remote code execution is a well-understood attack class. CWE-434 has been on the books for years. When a plugin in active use by millions of sites ships a flaw of this type with no authentication requirement, it is a reminder that the plugin vetting process for WordPress marketplaces does not guarantee ongoing security review of the codebase. The responsibility for catching and closing these windows falls on whoever operates the site, which in practice means it falls on your patch management process.

The control that would have blunted it

The control that would have blunted this attack is prompt plugin patching, ideally automated or at minimum systematically tracked with a short remediation window. Cyber insurers increasingly ask for documented patch management processes that cover third-party software, and WordPress plugins are squarely in scope for that question. A policy that patches core OS and application software within 30 days but leaves plugins on a whenever-I-remember schedule creates a gap that underwriters will probe.

For Elementor Pro specifically, version 4.2.2 was the fix, available August 19, 2026. Any site still running 4.2.1 or earlier after that date with a file upload form field active was in the exploitation window. The practical target for a critical CVSS 9.x vulnerability with confirmed active exploitation is patching within 24 to 72 hours of disclosure, which is genuinely difficult without automation or at least a monitoring pipeline that surfaces new critical plugin CVEs as they drop.

Beyond patching, a few additional controls reduce the blast radius if a site does get caught in the window. Restricting the file types that PHP can execute from the uploads directory at the web server level (via .htaccess or nginx configuration) would prevent a successfully uploaded webshell from running even if it gets written to disk. File integrity monitoring on the wp-content/uploads/elementor/forms/ path would surface unexpected PHP files. And if you manage multiple WordPress sites, a centralized plugin inventory that tells you which sites have Elementor Pro installed at which version is the prerequisite for any of this to work at speed. Without that inventory, you are patching reactively and hoping your scan coverage finds the vulnerable instances before an attacker does. That is an uncomfortable position to be in when the exploitation volume is 190,000 attempts in five days.

One tradeoff worth acknowledging: automated plugin updates can break sites when a plugin update introduces a compatibility issue with a theme or another plugin. That is a real operational cost, and it explains why many teams hesitate to enable auto-update for plugins. A reasonable middle ground is staging environment validation with a short turnaround window for critical severity findings, accepting that for a CVSS 9.x with active exploitation, a brief staging check and same-day production push is the right call even if it carries some compatibility risk.

Strondex's patch management platform gives you centralized visibility into plugin versions across your WordPress fleet, automated update scheduling, and audit-ready reporting for cyber insurance documentation.