Wordfence has blocked over 440,000 exploit attempts against two WordPress plugin flaws, and the worse one demands nothing from the attacker. No session, no scraped nonce, no race condition. Two unauthenticated HTTP requests and you have code execution.
Two requests, one webshell
CVE-2026-14894 (9.8) sits in the Super Forms submit_form AJAX handler: no file type validation, no capability checks. Normally a missing nonce check still forces the attacker to scrape a valid nonce from a page, which adds friction. Here the plugin ships a second unauthenticated AJAX action, super_create_nonce, that mints a valid nonce and session cookie to any anonymous visitor on demand. The server hands over the lock pick.
So the chain is: request one mints the nonce, request two POSTs to admin-ajax.php with a Base64 PHP payload disguised as data:image/gif;base64 and an attacker-chosen .php filename. The observed drop is Mushr00w_upl.php, an uploader webshell used to run commands and create admin accounts. Fixed in 6.3.314.
Elementor Pro's CVE-2026-32475 is a parser trick instead. Submit the File Upload field as an array where the first element is empty and the second carries a .php payload, and validation waves it through into /wp-content/uploads/elementor/forms/, directly requestable. One real caveat: the site needs a published page containing a Form widget with a File Upload field. That likely explains why it's scored 9.0 in some places and 9.8 in others. Don't treat it as protection. Upload fields are common in contact and quote forms, and an unpatched site becomes exploitable the moment an editor adds one. Fixed in 4.2.2.
Why this industrializes before you patch
The exploit is a curl command. Turning a public writeup into a scanner module is an afternoon of work. Wordfence tracked campaigns hitting both plugins in parallel, ten source IPs each, peaking at 40,000 requests in a single day against Super Forms alone. Nobody picked your site. Every host running the plugin is a candidate, and obscurity is not a control.
Also worth pricing in: Wordfence ships new firewall rules to premium customers first, free tier roughly 30 days later. If you're on the free tier, you had no rule during the campaign peak. And even a working rule does nothing about a shell dropped before it existed, because updating the plugin does not remove a webshell. The WAF buys patch time. The update is the fix.
Patch first, then hunt
Order matters. Patch to stop new uploads, then hunt, because anything you find predates the patch and the patch won't remove it.
# the two-request kill chain, if the action rode in the query string
grep -E "admin-ajax\.php\?[^\"]*action=super_create_nonce" /var/log/nginx/access.log
# Elementor shells being executed after upload
grep -E "uploads/elementor/forms/[^ ]*\.php" /var/log/nginx/access.log
# PHP where no PHP should be
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -ls
Then run wp user list --role=administrator and question every account you don't recognize. Admin creation is part of the observed post-exploitation behavior. If you find a shell: isolate the host, restore from a backup that predates the first suspicious log entry, and rotate every credential on the box.
Do today:
- Patch Super Forms to 6.3.314 and Elementor Pro to 4.2.2. Same day is the correct default for unauthenticated plugin RCEs with public writeups.
- Hunt even if your WAF blocked the attempts. A block is not a cleanup.
- Audit your Elementor pages for File Upload fields so you know your exposure before an editor adds one.
Argue with me in the comments: should a security plugin's free tier get firewall rules at the same time as paying customers, or is the 30-day delay a legitimate business model?
Longer writeup if you want the full argument: https://axeploit.com/blog/the-super-forms-exploit-needs-two-requests-attackers-sent-440000
Top comments (0)