Most critical WordPress bugs ask something of the attacker: a session, a guessed nonce, a race condition won. CVE-2026-14894, the 9.8-rated file upload flaw in the Super Forms plugin, asks for two unauthenticated HTTP requests, and the first one exists only so the site will hand the attacker a valid nonce. Wordfence has already logged over a quarter of a million blocked exploit attempts against it, which tells you exactly how fast a bug like this becomes a production line.
The two bugs and the numbers
In a pair of reports published the week of September 4, 2026, Wordfence described more than 250,000 blocked exploit attempts against Super Forms and over 190,000 against Elementor Pro, both unauthenticated arbitrary file upload flaws leading to remote code execution. Super Forms is fixed in 6.3.314, Elementor Pro in 4.2.2. The Super Forms campaign peaked at more than 40,000 exploit requests in a single day, August 18. Elementor Pro's CVE-2026-32475 is scored 9.0 in some reports and 9.8 in others, and the reason for that split is worth understanding, which I'll get to.
Super Forms: a nonce dispenser next to an upload endpoint
SentinelOne's root-cause analysis of CVE-2026-14894 is the part of this story that should change how you prioritize plugin bugs. The flaw sits in the submit_form function in includes/class-ajax.php, exposed on the unauthenticated AJAX hook with no file type validation and no capability checks (CWE-434). Normally a missing nonce check still forces an attacker to scrape a valid nonce from a page, which adds friction. Here it doesn't, because a companion AJAX action, super_create_nonce, is also unauthenticated and mints a valid sf_nonce and session cookie to any anonymous visitor on demand.
So the kill chain is two requests. One GET or POST to mint a nonce, then one crafted POST to /wp-admin/admin-ajax.php with the super_submit_form action, carrying a Base64-encoded PHP payload prefixed with a data:image/gif;base64 content type and an attacker-chosen .php filename. The observed payload drops Mushr00w_upl.php, a file-uploader webshell used to stage further payloads, run commands, and create admin accounts. Every version through 6.3.313 is affected. The vendor fix (commit c5838f5, shipped in 6.3.314) rejects data URI file payloads unless the form has PDF generation enabled.
Elementor Pro: read the prerequisite before you panic or shrug
CVE-2026-32475 has a real precondition: the target site needs at least one published Elementor page containing a Form widget with a File Upload field. No field, no exploit, at least not today. The bypass itself is a parser trick, and Wordfence's description is worth quoting directly:
"The attacker submits the form's File Upload field as an array, where the first element is empty and the second element carries a PHP payload with a .php file name, which is the structure that triggers the validation bypass."
The file lands in /wp-content/uploads/elementor/forms/ under a randomly generated name that keeps the .php extension, and it is directly requestable, so the attacker just browses to the shell. Patchstack published technical details about a month before Wordfence's telemetry reports, giving anyone watching a comfortable head start.
My take on the prerequisite: it likely explains the 9.0 versus 9.8 scoring spread, but do not treat it as protection. Upload fields are common in contact, quote, and application forms, and an unpatched site becomes exploitable the moment an editor adds one. Check your exposure, then patch anyway.
Why plugin RCEs industrialize faster than you can patch
Three mechanics are doing the damage here, and none of them are new. They are just getting cheaper.
The exploit is a curl command. Two requests, no authentication, a nonce served on request. Turning the public writeup into a scanner module is an afternoon of work, and the compression keeps getting worse. We watched an AI build a working Avada exploit in two hours, and that is the trend line your patch window competes against. For an unauthenticated RCE in a widely deployed plugin with public details, "we'll patch this weekend" is a losing bet. Same day is the correct default.
Campaigns run in parallel. Wordfence tracked ten source IPs per campaign, twenty total, hitting both plugins simultaneously. Security Arsenal reads this as actors opportunistically maximizing coverage across the WordPress install base, and I agree. The scanner does not care which plugin you run. It fires both payloads and keeps whatever answers. If your alerting model assumes one attacker IP probing one thing at a time, that assumption breaks against swarm-style campaigns like this one.
Volume is automated, targeting is not. Forty thousand requests in a day against one plugin, from ten addresses. Nobody picked you. Every site with the plugin installed is a candidate, found by scanning IP space, regardless of how obscure your domain is. Obscurity has never been a control, but it is worth saying out loud because a surprising number of WordPress owners still quietly rely on it.
The WAF rule gap nobody prices in
Wordfence's 440,000 blocked attempts come from sites where the firewall already had a rule for these exploits. Wordfence's long-standing model ships new firewall rules to premium customers first and to free-tier users later, historically on roughly a 30-day delay. Run the arithmetic for a realistic site: vulnerable plugin, public exploit details, active scanning, and a free WAF that receives the rule weeks after the campaign peaks. That is an unprotected window measured in weeks, and the traffic inside that window is fully automated.
The predictable pushback: "440,000 blocked means the control works." For sites that had the rule, after it shipped, yes. Two caveats. First, a block does nothing about a shell dropped before the rule existed, and as LavX's writeup points out, updating the plugin cannot remove a webshell uploaded earlier. Second, signatures get bypassed. The Wordfence quote above is literally a description of a validation bypass, and WAF rules are one parser difference away from the next one.
So my position is unchanged: a WAF is a bridge that buys you patch time, and only if you actually hold the rule. The update is the fix.
Assume you were hit. Then check.
Order matters. Patch first to stop new uploads, then hunt, because anything you find was written before the patch and the patch will not remove it. The same batch-triage discipline we laid out for the miniOrange SAML forgery bugs applies here.
Access logs
SentinelOne's key IoC is the two-request pattern: an unauthenticated POST to admin-ajax.php with action=super_create_nonce immediately followed by action=super_submit_form from the same source. If the action parameter rides in the query string, your access logs have it:
grep -E "admin-ajax\.php\?[^\"]*action=super_create_nonce" /var/log/nginx/access.logIf the actions were sent in POST bodies, access logs will only show the POST to admin-ajax.php, and you need ModSecurity audit logs or WAF request logs. Grep those for super_submit_form alongside data:image/gif;base64 and .php. For Elementor, the tell is execution rather than upload: direct requests for PHP under the forms upload directory.
grep -E "uploads/elementor/forms/[^ ]*\.php" /var/log/nginx/access.logWordfence published ten source IPs per campaign. The ones named publicly include 103.168.147.235, 103.154.152.178, 64.176.209.104, and 37.9.33.62 for Super Forms, and 185.196.220.85, 216.126.225.208, 114.10.17.253, 2602:fa59:10:7a1::1, and 2406:ef80:2:7d19::1 for Elementor Pro. Grep your history for them, but treat a clean result as weak evidence. Twenty addresses are a thin slice of the infrastructure running these scans.
Filesystem
Uploads directories on a healthy WordPress site contain almost no PHP, so any hit here deserves attention:
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -ls
find /var/www -name "Mushr00w_upl.php" 2>/dev/nullDouble-extension files like shell.jpg.php match the first pattern. Then list admin users with wp user list --role=administrator and question anything you do not recognize, since creating admin accounts is part of the observed post-exploitation behavior.
Process and network
Security Arsenal published an experimental Sigma rule (id 8c1f4a2e-3b7d-4e91-a5c6-2d8f9b0e1a34, dated 2026/09/15, mapped to MITRE ATT&CK T1505.003) that fires when php-fpm, Apache, or nginx spawns sh, bash, curl, wget, nc, python, perl, whoami, or id. That is the classic webshell execution signature, and it generalizes well beyond this campaign. Expect noise from backup or management plugins that legitimately shell out, so baseline before you alert hard. On the network side, watch for outbound connections from the PHP-FPM or web server process following Super Forms activity, another SentinelOne IoC.
If you find a shell
Isolate the host and restore from a backup that predates the first suspicious log entry. Then rotate everything: WordPress secret keys and salts in wp-config.php, API tokens, and user credentials, since the shell exists to mint access that survives a patch. Finish by auditing for the persistence that was the point of the exercise: new admin accounts and recently modified plugin or theme files.
Decision rules for this week
- Super Forms at 6.3.313 or earlier: update to 6.3.314 today. If you cannot, deactivate the plugin entirely (SentinelOne's stated workaround) or scope a WAF rule to the two Super Forms AJAX actions. A broad block on all unauthenticated
admin-ajax.phptraffic will break other plugins, so keep it narrow. A broken form is a support ticket; a webshell is an incident. - Elementor Pro: update to 4.2.2, then inventory published pages for Form widgets with File Upload fields. If one existed while you ran a vulnerable version during this campaign, hunt using the steps above even though the update is applied.
- Do not wait for the CISA KEV catalog to permission your response. KEV listing is not a fact today; Security Arsenal calls it a realistic near-term outcome. Absence from a catalog is lag, not signal.
- If your only edge protection is a free-tier plugin firewall, budget as if the rule arrives after the attack, because for fast-moving campaigns that is what happens.
Incidents like this are what the space between annual pentests looks like: a plugin update, a public writeup, and an automated campaign inside the same month. If the gap here is coverage between annual tests, Axeploit's pentest workflow is the product page that matches this article. Recurring testing catches the exposed upload field and the forgotten form plugin before a scanner does.
If you want this checked automatically
If you want the auth and object-level checks in this article run against a live app, start with Axeploit's API security checker.
Key takeaways
- CVE-2026-14894 (Super Forms, fixed in 6.3.314) is exploitable in two unauthenticated requests because a companion AJAX action hands out valid nonces to anyone. Patch or deactivate today.
- CVE-2026-32475 (Elementor Pro, fixed in 4.2.2) requires a published Form widget with a File Upload field. Verify exposure, then patch anyway, because preconditions change the day an editor adds a form.
- Over 440,000 blocked attempts with a 40,000-per-day peak means automated scanning, not targeting. Your site's obscurity is irrelevant.
- Free-tier WAF rules lag premium by weeks. Treat the firewall as a bridge and the plugin update as the fix.
- Patching does not remove webshells. After updating, hunt logs, uploads directories, and process execution, and rotate credentials if anything turns up.
