Elementor Pro

Wordfence reports active exploitation of CVE-2026-32475 in Elementor Pro <= 4.2.1, with more than 190,000 blocked attempts. Review Elementor form upload paths, block PHP execution under uploads, and update to 4.2.2 or newer immediately.

Wordfence published a new active-exploitation update for CVE-2026-32475 on September 2, 2026. The vulnerability affects Elementor Pro up to and including 4.2.1 and allows unauthenticated arbitrary file upload when a public Elementor Pro Form widget contains a non-required File Upload field.

WPDeeply previously covered the base Elementor Pro vulnerability. This follow-up is focused on the newly published exploitation data, practical indicators of compromise, and server-side hardening checks administrators should run now.

Table of Contents

Vulnerability summary

Product: Elementor Pro
CVE: CVE-2026-32475
Affected versions: Elementor Pro <= 4.2.1
Fixed version: 4.2.2
Severity: CVSS 9.8 Critical
Attack class: Unauthenticated arbitrary file upload leading to remote code execution
Required site condition: a published Elementor Pro Form widget with at least one non-required File Upload field
Active exploitation: Wordfence reports more than 190,000 blocked exploit attempts since disclosure
CISA KEV: not listed at publication time

What changed

The vulnerability was disclosed and patched on August 19, 2026. The new September 2 update confirms broad exploitation attempts against real sites. Wordfence says attackers began targeting sites the same day the vulnerability was disclosed, with heavy activity from August 19 through August 23 and continued attempts afterward.

The vulnerable flow is in Elementor Pro form upload validation. In affected versions, a crafted multi-value upload field can cause validation to stop too early, so later uploaded files bypass extension and file-type checks. A successful attack can write executable files into the Elementor forms upload directory.

Immediate remediation

Update Elementor Pro to 4.2.2 or newer immediately.
Identify all public pages using Elementor Pro Form widgets.
Check whether any form contains a File Upload field that is not marked required.
Block PHP execution under wp-content/uploads, especially wp-content/uploads/elementor/forms/.
Search for recently created PHP files under Elementor’s form upload directory.
Review logs for suspicious unauthenticated requests to the Elementor Pro form AJAX action.

WP-CLI checks

wp plugin list --fields=name,version,status | grep -Ei 'elementor|elementor-pro'
wp plugin get elementor-pro --fields=name,version,status

If your license updater is not available through WP-CLI, update Elementor Pro through the vendor dashboard or WordPress admin and verify the installed version afterward.

File-system compromise checks

The strongest file-system indicator is any executable PHP file inside the Elementor forms upload directory. That directory should contain form-submitted files, not server-executed code.

find wp-content/uploads/elementor/forms -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) -print
find wp-content/uploads/elementor/forms -type f -mtime -21 -print
wp core verify-checksums
wp plugin verify-checksums --all

Unexpected PHP files in this path should be treated as a likely compromise. Preserve a copy and logs for investigation before removal if the site is under incident response.

Log review

Search web-server logs for Elementor form submissions and requests to uploaded PHP files. This is a defensive detection pattern, not proof by itself:

grep -Ei 'elementor_pro_forms_send_form|/wp-admin/admin-ajax.php|/wp-content/uploads/elementor/forms/.*\.php' /var/log/nginx/access.log*
grep -Ei 'elementor_pro_forms_send_form|/wp-admin/admin-ajax.php|/wp-content/uploads/elementor/forms/.*\.php' /var/log/apache2/access.log*

IP indicators

Wordfence listed these high-volume source IPs in the active attack data. Use them for log enrichment and short-term blocking, but do not rely on IP blocks as the primary fix because attackers rotate infrastructure quickly:

2602:fa59:10:7a1::1
185.196.220.85
103.84.230.85
103.90.148.202
216.126.225.208
167.254.240.75
167.254.241.119
114.10.17.253
114.10.45.151
2406:ef80:2:7d19::1

Server hardening

For NGINX, deny executable files under uploads. Test with nginx -t before reloading:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar|shtml)$ {
    deny all;
    return 403;
}

For Apache, make sure directory overrides are honored and add an execution deny rule under uploads when your host permits it:

<FilesMatch "\.(php|phtml|phar|shtml)$">
    Require all denied
</FilesMatch>