What changed
CVE-2026-32475 was patched in Elementor Pro 4.2.2 on August 19, 2026, but active exploitation is now established. Wordfence reported that attackers began targeting vulnerable sites the same day the issue was publicly disclosed and said its firewall had blocked more than 190,000 exploitation attempts by its September 2 update. The flaw affects Elementor Pro 4.2.1 and earlier and can let an unauthenticated attacker bypass file validation in certain Form widget configurations, upload executable PHP and potentially take control of the site. Independent security reporting has confirmed exploitation activity and public proof-of-concept material is circulating.
Why it matters
Elementor Pro is installed on millions of WordPress sites, and the vulnerable condition can sit in an ordinary public-facing form rather than an administrative interface. Once exploitation is active, simply knowing that a patch exists is not enough: operators need to verify the deployed plugin version, look for signs that a web shell was already uploaded and prevent PHP execution in upload directories where their stack permits it. The event also illustrates why WordPress plugin inventory and automated patch visibility matter as much as core-version hygiene.
The bug can turn an optional form upload into code execution
The vulnerable validation loop can stop checking remaining files in a multi-file upload when an earlier array element reports no file. On a published Elementor Pro Form widget with at least one non-required File Upload field, an unauthenticated request can therefore reach a path where a later malicious file is not correctly rejected. If the server executes PHP from the resulting upload location, that can become remote code execution.
The remediation boundary is concrete: 4.2.2 or later
Elementor released the patched 4.2.2 build on August 19. Sites on 4.2.1 or earlier are affected. Operators should verify the version actually running on each production site rather than assuming a control panel or staging environment updated successfully.
Active exploitation changes the response from patching to incident checking
Wordfence says exploitation began on the day of public disclosure and reported more than 190,000 blocked attempts. Independent reporting describes web-shell delivery and command execution. A site that remained exposed after disclosure should therefore be checked for unexpected PHP files, administrator accounts, modified plugins/themes and suspicious requests rather than treated as clean merely because it has now been updated.
Firewall coverage is useful but configuration still matters
Wordfence says its malicious-file-upload protection can block exploitation, and separately recommends disabling code execution in WordPress upload directories. That is defense in depth, not a replacement for installing the fixed Elementor Pro release. Other WAF products and hosting controls should be evaluated against the actual exploit pattern rather than assumed to provide equivalent protection.