Form Builder Plugin Vulnerabilities: 85 CVEs in Two Months

Between August 3 and October 1, 2026, our database logged 85 critical or high-severity vulnerabilities in WordPress form plugins. Seventy-six of them need no login at all. Twenty score 9.0 or higher.

Those 85 sit in 40 plugins. That's about 6% of the 633 plugins with a critical or high disclosure in the same window, producing about 10% of the 879 disclosures. Forms aren't the biggest category, but they're a steady one, and they punch above their weight for a simple reason: a form is a public door built to accept input from strangers.

How We Counted

We matched plugin slugs that contain form, forms, contact-form or form-builder, plus the named builders (Forminator, Gravity Forms, Ninja Forms, Formidable, JetFormBuilder, WPForms and a few others), and counted anything scored 7.0 or above. Add-ons are included, so a Ninja Forms add-on counts on its own. The window is August 3 to October 1. The numbers move every day, and the live list is on our vulnerabilities page.

What the Bugs Actually Are

Forms skew toward two bug classes more than the rest of the plugin ecosystem does.

Close to half of the form-plugin disclosures are stored XSS. That fits how a form works. A visitor submits text, the plugin saves it, and an administrator opens the entries screen later. The payload runs in the admin's browser with the admin's session. We covered why this class keeps growing in our post on unauthenticated stored XSS in WordPress plugins.

File upload is the other one to watch. It's a smaller share of the count, but a form with an upload field that accepts a PHP file is a full site takeover, which is why Super Forms landed on our exploited-in-the-wild list and Ninja Forms got its own writeup.

Key finding

Forms attract two bug classes more than other plugins do: stored XSS, because an administrator reads what strangers typed, and file upload, because a form is built to accept files.

The Plugins That Keep Coming Back

A few plugins account for a large share of the count. These are the form plugins with the most critical or high disclosures in the window.

Forminator is the clearest case. Counting every severity, it has 22 disclosures since August 3, and 15 of them need no login. Those fixes landed across 13 different releases, from 1.55.1 to 1.57.3. Unauthenticated XSS alone was fixed in 1.57.0.1, 1.57.0.2, 1.57.0.3 and 1.57.2.1.

Ninja Forms follows the same pattern on a shorter clock. Since September 2 it has had 9 disclosures, 7 of them unauthenticated, and it has shipped unauthenticated stored XSS fixes in three releases within about four weeks: 3.15.2, 3.15.4 and 3.15.5.

None of that says these are bad plugins. Fast, repeated fixes usually mean researchers are looking hard and the vendor is responding. It does mean there's a new window to be exposed in every time a release is missed, and a site running a form plugin one version behind is carrying real risk.

Does Install Count Explain It?

In our look at new plugins, disclosures followed installs more than age. The form plugins mostly fit that. The two biggest, Forminator and Ninja Forms, also top the count.

Two of them break the pattern. ACF Frontend Form Element has about 8,000 installs and still had 6 critical or high disclosures, 5 of them with no login. RegistrationMagic has about 7,000 and had 5. A small install base doesn't protect a plugin that publishes a public form, because that form is reachable by anyone who finds it, and researchers go looking for plugins with that kind of door.

So install count is a good guide to which plugins get attention, but it isn't a safe rule here. A form plugin with a few thousand installs still deserves the same update discipline as one with half a million.

What to Do on Your Own Sites

Start by seeing what's out of date. This lists every plugin with an update waiting:

wp plugin list --update=available --fields=name,status,version,update_version

Then work through the sites that matter most.

Run one form plugin, not three. Sites accumulate form tools over the years: one for contact, one for payments, one a developer installed for a single page. Every extra one is another public endpoint to patch. Consolidate, then delete the rest.

Delete deactivated form plugins, don't just switch them off. The files stay on disk, and a vulnerable file can still be requested directly in many cases.

Turn on auto-updates for the form plugins. They're the plugins most likely to get an urgent fix. In WP-CLI that's wp plugin auto-updates enable <plugin>, or the toggle on the Plugins screen.

Remove upload fields you don't use. If a form doesn't need to accept files, take the field out. If it does, restrict the allowed types and check where the files land.

Check add-ons separately. Add-ons ship on their own schedule. A premium add-on with an expired license may never show an update notice, which we explain in our guide to premium plugin licenses and security updates.

Choosing and Keeping a Form Plugin

The data doesn't say which plugin is safest, and we wouldn't pick one from a CVE count alone. A plugin that's audited a lot collects disclosures, and one nobody reviews may collect none. These are the questions that do help.

• Does it get a fix quickly? Check the changelog for security entries and how soon after a disclosure they appear. Forminator and Ninja Forms both ship fixes within weeks.
• Do you need all of it? Many sites use a form plugin for one contact form. A smaller plugin, or a form feature in your theme or page builder, means fewer public endpoints.
• Where do entries go? Plugins that store submissions in the database and show them in the dashboard are the ones exposed to stored XSS. If you don't read entries in the dashboard, turn that storage off.
• Is it still maintained? A form plugin with no update in a year is a public door nobody is watching.

Find Every Form on the Site

The plugin you think of as your form plugin is rarely the only one. List everything active with "form" in its name, and check the plugins that add forms as a side feature:

wp plugin list --status=active --fields=name,version,update | grep -i -E "form|survey|quiz|register"

Page builders and membership plugins ship their own form widgets, and those count. The Elementor Pro form flaw on our patch list, where a visitor could upload a PHP file through a File Upload field, sat in a form widget rather than in a form plugin. If a site collects input from visitors anywhere, that code path needs the same updates as the dedicated plugins. Check them on every site, including the ones you inherited.

If a Form Plugin Was Behind When the Fix Shipped

Updating closes the hole, but it doesn't remove anything left behind. For an XSS bug, look for new administrator accounts and unfamiliar entries in your form submissions. For an upload bug, look for PHP files in the uploads folder. Our guide to the signs your WordPress site has been hacked walks through the checks, and the malware removal guide covers cleanup.

We update our weekly patch list every week with the form plugins and everything else worth patching first. To check what's installed on your site against the same database, run a scan.

References

• Wordfence Intelligence vulnerability database
• WP Vanguard vulnerability database