Two things converged on WordPress form plugins in 2026: spam bots got dramatically better at evading detection, and two of the most-installed form plugins in the ecosystem shipped critical, publicly disclosed vulnerabilities within months of each other. Neither is speculative — both are documented, sourced, and actionable. This covers what actually happened, with real numbers, and what to do about it regardless of which plugin you're running, plus the perennial "why isn't my form submitting" complaint that never really goes away.

The AI bot spam surge, with real numbers

Contact form spam used to be a nuisance handled by a honeypot field and a basic CAPTCHA. That's no longer sufficient on its own. Bots are now powered by AI, running through headless browsers with human-like timing and mouse movement, filling out forms in ways that are difficult to distinguish from a real visitor using pattern-matching alone.

Source: Imperva threat research, cited across multiple 2026 web security reports — daily blocked AI-powered attacks across their customer base rose from roughly 2 million to roughly 25 million, a ~12.5x year-over-year increase. This tracks blocked attacks generally, not WordPress forms specifically, but form endpoints are a common target within that volume.

The practical effect on a WordPress site: a contact form that received a handful of obvious spam submissions a day two years ago can now receive dozens or hundreds of bot submissions that pass a basic CAPTCHA, because the bot is genuinely simulating human interaction rather than submitting a raw HTTP request. This isn't just an annoyance — high-volume bot traffic against a form endpoint is a measurable performance cost (server resources spent processing junk submissions), a data-quality problem (a CRM or email list polluted with fake entries), and in some cases a security probe (testing which fields exist and how validation responds, ahead of a more targeted attack).

What AI-powered bot spam actually costs a site

The abstract "spam is worse now" framing undersells the real, measurable cost across a few distinct categories:

• Server resources. Every bot submission still triggers the full form-processing pipeline — validation, database writes, notification emails, sometimes a webhook or CRM sync. At 25M-scale daily bot traffic industry-wide, a site receiving even a small fraction of that volume is spending real compute and database load on submissions that will never become a customer.
• Data quality. A CRM, email list, or lead pipeline polluted with fake entries doesn't just waste storage — it corrupts whatever decisions get made from that data. A marketing team calculating conversion rate against a lead list that's 30% bot-generated garbage is working from a wrong number without realizing it.
• Team time. Someone has to review and manually purge bot entries from an inbox or CRM, or build automation to do it — either way, that's ongoing operational cost that scales with bot volume, not a one-time setup cost.
• False negatives on real leads. Overly aggressive spam filtering to compensate for bot volume risks blocking real submissions too — a visible CAPTCHA challenge that's annoying enough measurably reduces real-visitor completion rates, which is exactly why the industry shift toward invisible, behavior-scored defenses (reCAPTCHA v3, Turnstile) matters: they add bot friction without adding human friction.

Why old defenses alone aren't enough anymore

A honeypot field — an input real visitors never see or fill in, that a bot fills in blindly — still works against unsophisticated bots, and it's free and invisible to real users, so there's no reason not to have one. But it does nothing against a bot sophisticated enough to render the page and only interact with visible fields, which describes a meaningful share of 2026-era bot traffic.

The layered approach security researchers currently recommend:

1. Honeypot fields — free, catches the least sophisticated bots, zero friction for real visitors.
2. Behavior-scoring CAPTCHAs — reCAPTCHA v3 and Cloudflare Turnstile score interaction patterns rather than presenting a visible challenge, adding friction for bots without interrupting real visitors with a puzzle to solve.
3. Server-side content filtering — services like Akismet check submission content against a continuously updated spam-detection model trained across a very large cross-site dataset, catching patterns invisible to any single site's own traffic.
4. Server-side verification of any client-side signal — a CAPTCHA token, a honeypot value, anything computed in the browser needs to be re-verified against the provider's own API server-side, not just trusted because the client said it passed. A forged client-side "success" is trivial for a sophisticated bot to fake if the server doesn't independently confirm it.

No single layer is sufficient alone in 2026's threat environment; the combination is what actually holds up.

Two critical WordPress form plugin vulnerabilities in 2026

Spam is the volume problem. These are the severity problem — both publicly disclosed, both CVE-numbered, both affecting extremely widely installed plugins.

Forminator: unauthenticated remote code execution (CVE-2026-15748)

This is the more severe of the two, rated CVSS 9.8 (Critical). The flaw was in Forminator's file upload handling: the plugin's dangerous-file-extension blocklist used exact-key matching that could be bypassed with a pipe-alternative MIME type key, combined with a public submission handler that trusted attacker-controlled upload field configuration injected via a forged Select field value. In practice, this meant an attacker with no login and no user interaction from a victim could upload an executable PHP file to a vulnerable site and achieve full remote code execution.

• Affected versions: Forminator up to and including 1.56.1
• Fixed in: version 1.56.2
• Install base: 600,000+ active installs
• Real-world exposure: SecurityWeek estimated over 300,000 sites were still running a vulnerable version when the issue was publicly disclosed
• Prerequisite: exploitation required a form with both a File Upload field and a Select field present — not every Forminator site had this exact combination, but a large share of forms that collect applications, resumes, or document uploads do

WPForms: broken access control (CVE-2026-32446)

The second flaw, disclosed within months of the first, was a missing authorization / broken access control vulnerability. Certain AJAX endpoints didn't properly verify user permission level before allowing an action — meaning an authenticated user without administrator privileges could access functionality or data that should have required a higher permission level, including potentially sensitive form submission data or configuration settings.

• Affected versions: WPForms up to and including 1.9.9.3
• Fixed in: version 1.9.9.4, released March 3, 2026
• Severity: lower than the Forminator flaw since it required an authenticated account first (not a fully unauthenticated attack), but still a real data-exposure risk on any multi-user WordPress install — a compromised low-privilege account, or a malicious logged-in contributor, could exploit it

What these two have in common

Both flaws trace back to the same category of mistake: trusting client-supplied configuration or state without re-verifying it server-side. Forminator trusted a forged field configuration; WPForms didn't sufficiently re-check permission level before an action. This is the exact pattern security-conscious form plugin architecture is supposed to guard against — every meaningful decision (what file type is allowed, who's permitted to do what) has to be re-verified on the server at the moment of the request, not inferred from what the client claims.

How a vulnerability like this actually gets found and fixed

It's worth understanding the disclosure pipeline both of these went through, since it explains why the timeline between "vulnerability exists" and "you need to act" is often much shorter than a normal feature-update cycle:

1. Discovery. Independent security researchers (often working with a bug-bounty program or a vulnerability research firm) find the flaw, frequently through manual code review or automated static analysis of the plugin's source, since both Forminator and WPForms are open-source-adjacent (available on WordPress.org, source visible).
2. Responsible disclosure. The researcher reports it privately to the plugin vendor rather than publishing immediately, giving the vendor time to build and release a fix before attackers learn the details. Both vendors here followed this pattern — a fixed version shipped before or alongside public disclosure, not after.
3. CVE assignment. The flaw gets a formal CVE identifier (Common Vulnerabilities and Exposures) once verified, which is what lets it be tracked consistently across security tools, scanners, and databases like NVD, WPScan, and Patchstack.
4. Public disclosure. Once the fix is available, full technical details get published — partly for transparency, partly so security tools can build detection signatures. This is also the exact moment automated attacker scanning tools start looking for unpatched installs, which is why the gap between disclosure and patching matters so much.
5. Patch adoption lag. This is the real risk window. WordPress plugins don't universally auto-update by default, so a meaningful share of the install base stays on the vulnerable version for weeks or months after a fix ships — exactly the population SecurityWeek's 300,000-site estimate for Forminator was describing.

How fast this actually gets exploited

The gap between disclosure and real-world attack is smaller than most site owners assume. Security researchers tracking 2026 WordPress exploitation patterns have observed mass exploitation beginning within as little as 5 hours of a critical vulnerability's public disclosure — automated scanning infrastructure picks up a new CVE, generates an exploit, and starts scanning the internet for vulnerable installs essentially as soon as the technical details are public, sometimes faster than site owners even see the update notification in their WordPress dashboard.

This is specifically why "I'll update when I have time" is a meaningfully riskier posture for a critical-severity, unauthenticated vulnerability than it might feel like in the moment — the realistic window to patch before automated scanning finds an unpatched site is measured in hours, not the days or weeks it might take on a normal update cadence.

What to actually do about this

Regardless of which plugin you're running:

1. Check your installed version against the fixed version for any CVE affecting your plugin. For the two above: Forminator needs to be at 1.56.2+, WPForms at 1.9.9.4+. If you're below either threshold and use that plugin, update now, not on your next scheduled maintenance window.
2. Turn on automatic updates for security-sensitive plugins, form builders specifically, given how much of a site's attack surface runs through them (file uploads, payment data, arbitrary user input).
3. Audit which forms actually need a file upload field. The Forminator flaw specifically required a File Upload + Select field combination — reducing which forms have file upload fields at all reduces your exposure to this entire vulnerability class, independent of which plugin you use.
4. Bookmark a vulnerability database — WPScan and Patchstack both track WordPress-specific CVEs by plugin and version range, and are worth checking periodically if you manage more than a couple of sites. Both also offer email or Slack alerts for new CVEs affecting plugins you specify, which is a more reliable habit than remembering to check manually.
5. Layer your spam defenses as covered above — a single CAPTCHA is no longer sufficient against 2026-era bot sophistication.
6. If you manage client sites as an agency, treat this as a recurring maintenance task rather than a one-time check — a new critical CVE in a widely used form plugin is not a rare event at this point, and a standing monthly (at minimum) version-audit pass across every client site catches the next one before it becomes an incident.

Where ChargeForms differs on both fronts

On file uploads specifically: uploads are validated through WordPress's own wp_handle_upload (real MIME-type checking against actual file contents, not extension-string matching), combined with a hard denylist of executable file types that applies regardless of a form's own configured field allowlist — meaning a forged field configuration can't override the executable-file block the way the Forminator flaw exploited. On spam: reCAPTCHA v2, hCaptcha, and Cloudflare Turnstile are all verified server-side against the provider's own API, so a forged client-side "passed" token is rejected rather than trusted. Full detail on both (and the rest of the security architecture) is on the Security page.

This isn't a claim that any software is invulnerable — new vulnerability classes get discovered in every widely used piece of software, ChargeForms included, which is exactly why the responsible disclosure process on that same page exists. It's a description of the specific architectural pattern (server-side re-verification of everything client-supplied) that the two 2026 CVEs above both failed on.

The other trending complaint: "why isn't my form submitting"

Separate from spam and security specifically, "my WordPress form stopped working" remains one of the most common form-related searches, and it's worth covering since a form that silently fails to submit is its own kind of urgent problem — every failed submission is a lost lead or a frustrated customer who won't try again. In rough order of how often each cause actually turns out to be the culprit:

1. A caching plugin serving a stale page. The most common cause by a wide margin. If a page-caching plugin (WP Rocket, W3 Total Cache, a host-level cache) served a cached version of the page before a form-related update was made, visitors can be interacting with an outdated version of the form's JavaScript. Clear the cache, then test in a private/incognito browser window to rule this out first, before investigating anything else.
2. A JavaScript conflict with another plugin or the active theme. Two plugins loading conflicting versions of a shared library (jQuery being the classic culprit), or a theme's own JavaScript throwing an error that halts execution of everything after it on the page, including the form's submit handler. Check the browser console (F12 → Console tab) while attempting a submission — a JavaScript error there is a strong signal of exactly this.
3. A PHP execution or memory limit too low for the form's processing. More common on forms with file uploads, complex conditional logic, or a payment integration doing extra API calls at submission time. Check with your hosting provider about current PHP memory_limit and max_execution_time settings if a form processes normally for a while, then times out.
4. Email deliverability, not actual submission failure. Sometimes the form worked correctly — the entry was created — but the notification email didn't arrive, landed in spam, or was blocked by the receiving mail server. Check the plugin's own entries/submissions log (most form plugins keep one independent of email) before assuming the form itself failed.
5. A security plugin or firewall rule blocking the submission. Overly aggressive WAF (web application firewall) rules occasionally flag legitimate form submissions as suspicious, particularly ones with unusual characters or longer text fields. Temporarily whitelisting the form's submission endpoint is a reasonable diagnostic step if the above don't explain it.

The bottom line

If you're running Forminator or WPForms, check your version against the fixed releases above right now — this isn't a "get to it eventually" item given how fast post-disclosure exploitation moves. If you're running any WordPress form plugin, treat the AI bot spam increase as a real shift, not a temporary spike — a single-layer defense that worked in 2023 is measurably less effective against 2026-era bot traffic, and layering honeypot + behavior-scoring CAPTCHA + server-side content filtering is the current baseline, not an advanced configuration.

Related posts

Guides

We Did the Math: What a 'Free' WordPress Form Plugin Actually Costs

Every major WordPress form plugin advertises a free plan. We calculated the real first-year cost of getting conditional logic and payments working on each one — the numbers aren't close.

2026-09-30·4 min read

Guides

ChargeForms MCP Server: The Complete Tool Reference (2026)

Every MCP tool ChargeForms exposes to Claude, ChatGPT, or any MCP client — all 15, with exact parameters — plus how to connect one and how the preview-confirm safety model actually works.

2026-09-25·5 min read

Guides

Contact Form 7 Is in Maintenance Mode: What That Actually Means

Contact Form 7's creator confirmed at WordCamp Asia 2026 that version 6.2 is the last feature release — the plugin now gets security patches only. Here's what changes, what doesn't, and what to actually do about it.

2026-09-23·4 min read