Your Contact Form Could Be the Weak Point: A Practical Guide to the Super Forms and Elementor Pro Flaws

Does your website have a contact form, a job application form, or anything else that lets a visitor attach a file? If so, this week’s news is worth ten minutes of your time. Wordfence has logged more than 440,000 attempts to exploit two critical bugs. One is in the Super Forms plugin, the other in Elementor Pro. Both come down to the same weak point: how WordPress file upload security is handled when a stranger submits a form.

Here’s what actually happened, and what it means for keeping your own site off the same list.

The two flaws, in plain terms

Super Forms – Drag & Drop Form Builder had a bug, CVE-2026-14894, rated 9.8 out of 10 for severity. Its form submission handler didn’t properly check what type of file was being uploaded. A separate bug let attackers skip the security token WordPress normally requires. Put together, anyone on the internet could upload a PHP file and have the server run it. Versions up to 6.3.313 are vulnerable; 6.3.314 fixes it.

Elementor Pro, the page-builder plugin used on over ten million sites, had a related but subtler problem: CVE-2026-32475, severity 9.0. Its File Upload form field had two pieces of code checking the same upload: one validates it, one saves it. They disagreed about how to treat an upload with a blank first entry. An attacker could exploit that gap to sneak a PHP file past the validator. Versions up to 4.2.1 are affected; 4.2.2, released 19 August 2026, fixes it.

In both cases the end result is the same: a working PHP file sitting on your server. The attacker can call it up in a browser and do whatever they like. That includes creating an admin account, reading your database, or using your site to attack someone else.

Why “just a form plugin” matters more than it sounds

A contact form feels low-stakes. It isn’t processing payments or storing customer records, so it’s easy to assume it can’t do much damage. But any code that runs on your server, however small its job, has enough privilege to write files. And a file upload field is designed to accept content from someone you’ve never met. If the validation on that field has a gap, the size or purpose of the plugin doesn’t matter. The blast radius is the whole site.

Wordfence’s numbers back this up. Attackers didn’t need a fresh, undisclosed bug. The Elementor Pro exploit attempts started the same day the patch came out. Someone read the fix, worked out what it protected against, and went straight after every unpatched site. That is now the normal pattern for widely used plugins: patch release day is also attack day.

Why WordPress file upload security keeps failing

File upload handling is one of the oldest problems in web development, and it sits at the centre of good WordPress file upload security. It forces two competing goals into the same piece of code. The form needs to accept whatever a genuine visitor sends: a CV, a photo, a signed document. At the same time it must reject anything that could run as code on the server. Get the check slightly wrong, miss one file type, or mishandle one edge case, and the whole protection collapses. Both plugins here got tripped up by exactly that kind of edge case, not by some exotic new attack technique.

That’s worth knowing because it means the fix isn’t really about these two plugins. Any plugin, theme, or custom form on your site that accepts a file from the public deserves the same scepticism. Wherever a developer hasn’t thought through what happens with a malformed upload, that same gap is probably still there, waiting to be found.

What to actually do about it

Right now, today:

• If you run Super Forms, update to 6.3.314 or later.
• If you run Elementor Pro, update to 4.2.2 or later.
• Look inside wp-content/uploads/ and your theme folder for any PHP file you don’t recognise. Delete anything suspicious and change your WordPress admin passwords if you find something.
• Check your list of admin users. An unfamiliar account is the clearest sign of a successful compromise.

Over the next month:

• Turn off PHP execution inside your uploads folder at server level. Most hosts support this with a simple .htaccess rule or equivalent. That’s a basic rule of WordPress file upload security: a file upload field should never be able to run code, whatever plugin it belongs to.
• List every plugin on the site that accepts uploads from the public (forms, galleries, applicant portals) and check each is current.
• Turn on automatic updates for lower-risk plugins. An update might break something, but that risk is smaller than running a known, exploited flaw for weeks.
• Ask whoever manages your hosting or web application firewall whether it can virtually patch known plugin CVEs. This buys time between a disclosure and your own update window. It doesn’t replace patching.

The habit worth building

Most small businesses set up their WordPress site once and rarely think about it again unless something visibly breaks. These two flaws show why that’s a risk in itself. The plugins keep running and the exploit traffic keeps arriving. The only difference between a near miss and a breach is whether someone applied the patch before the scanners found the site. A recurring calendar reminder to check for plugin updates costs nothing. Though the fix is simple, it only works if someone actually does it. Treating WordPress file upload security as routine maintenance would have been enough to sidestep both of these flaws.