Forminator Forms CVE-2026-15748: The CVSS 9.8 Flaw That Left 300,000 WordPress Sites Exposed Since July 31

digital interactive web development hero image

Half of Forminator’s Install Base Is Running a Pre-Auth RCE Hole

The patch has been available since July 31. The plugin updated to version 1.56.2. WordPress.org published the advisory. And as of mid-August, over 300,000 sites are still running a version of Forminator Forms that lets an unauthenticated visitor upload a PHP file and execute arbitrary code on the server.

That is not a theoretical threat. CVE-2026-15748 carries a CVSS score of 9.8. The plugin has over 600,000 active installations. Per WordPress.org install data reviewed by Defiant (Wordfence), approximately half have not applied the patch. The math is straightforward and unpleasant.

What the Exploit Actually Does

The vulnerability lives in handle_file_upload(), the function Forminator uses to process file attachments submitted through its drag-and-drop form builder. The flaw is not a single weak point — it chains three separate weaknesses.

First, the plugin’s dangerous-file-extension blocklist uses exact-key matching. An attacker can bypass it by supplying a pipe-alternative MIME type key — the blocklist doesn’t recognize the alternative key format, so the PHP file clears the check. Second, Forminator’s public submission handler trusts the upload field configuration passed in the request body. An attacker can forge a Select field value to inject and control the field configuration reaching handle_file_upload(). Third, because the submission endpoint is public and unauthenticated, no login or prior account is required. The only actual prerequisite is that the targeted form contains both a File Upload field and a Select field.

Successful exploitation drops an executable PHP file — effectively a webshell — into the site’s upload path. From there the attacker has server-level access: WordPress credentials, database contents, configuration files, the ability to install additional payloads. Full site compromise in the language of the advisory means exactly that.

The Exploitation Timeline Is the Real Urgency

Security guidance published by OOPSpam in early August put a number on how fast this kind of disclosure turns into active scanning: automated bots begin probing WordPress sites for newly disclosed plugin vulnerabilities within hours, routinely before site administrators have seen an alert. That compression between disclosure date and first probe is the operational problem. A vulnerability disclosed on a Friday afternoon can be hitting sites across an agency’s entire client roster before Monday morning.

CVE-2026-15748 was disclosed publicly alongside the July 31 patch. The EPSS score trajectory on CVEfeed shows exploitation probability climbing through August as the disclosure spread across security feeds. No confirmed in-the-wild exploitation has been reported as of August 18 — but the absence of a confirmed incident is not evidence that scanning isn’t happening.

With 300,000 exposed installs sitting in search engine indexes, the attack surface is large enough to attract automated tooling regardless of whether a targeted campaign is underway.

What Needs to Happen on Every Site You Manage

Update Forminator Forms to version 1.56.2 or later. That is the non-negotiable starting point. If you manage WordPress sites at scale, run a query across your fleet before anything else:

“bash wp plugin list --field=name,version --format=csv | grep forminator “

Or with WP-CLI across multiple sites:

“bash wp plugin update forminator --path=/var/www/html “

After the update, three additional checks matter.

Audit your upload directories. Navigate to wp-content/uploads/forminator/ and scan for any .php files that shouldn’t be there. If you find one, you have a compromise, not a vulnerability — the investigation scope changes immediately. A WAF or server-side rule blocking PHP execution inside wp-content/uploads/ is worth adding regardless of whether you find anything.

Review any forms combining File Upload and Select fields. That configuration is the exploit prerequisite. If a form doesn’t need file uploads, remove the field. If it does need file uploads, confirm the updated plugin is restricting file types server-side, not just client-side.

Check your upload root for .htaccess protection. On Apache, a file at wp-content/uploads/.htaccess containing php_flag engine off or an equivalent deny rule blocks PHP execution even if a file gets through. Nginx requires a location block. Neither is a substitute for patching — both are useful defense-in-depth layers.

The Pattern Behind the Specific Flaw

Forminator is the third high-profile WordPress plugin to surface a critical vulnerability in this patch window. Earlier this month, WooCommerce’s Apple Login authentication chain was broken by three concurrent plugin patches, and BdThemes plugins were pulled from WordPress.org entirely after a supply chain attack delivered rogue admin accounts without touching a single file on disk.

The Forminator flaw is structurally different from both of those but shares one characteristic: it exploits a gap between what the plugin assumed about its own input validation and what an attacker can actually supply. The blocklist bypass via pipe-alternative MIME type keys is exactly the kind of edge case that passes code review and fails under adversarial testing. File upload handling is consistently among the highest-risk surfaces in the WordPress plugin ecosystem — Patchstack’s 2026 security whitepaper identifies unrestricted file upload (CWE-434) as a recurring critical vulnerability category across the ecosystem.

For agencies managing sites at scale, the operational implication is not just “patch faster.” It is maintaining a continuous, accurate plugin inventory across every client deployment — because the gap between “we use Forminator” and “which version are all 40 of our client sites running” is where incidents start.

FAQ

Is my site vulnerable if Forminator Forms is installed but I have no forms with both a File Upload and Select field? The specific chained exploit requires both fields in the same form. A site running Forminator Forms without that combination is technically less exposed to this particular attack path. Update anyway — the version boundary is the clean line, and other vulnerabilities may surface in later advisories against older builds.

Will Wordfence’s free firewall block this attack? Wordfence released a firewall rule for CVE-2026-15748 alongside the public advisory. Free tier users receive firewall rules on a 30-day delay. That means free-tier sites running Forminator 1.56.1 or earlier were unprotected at the firewall level for the first month after disclosure. The patch is the correct fix — the firewall rule is a secondary layer.

How do I confirm the patch applied correctly? In wp-admin navigate to Plugins > Installed Plugins and locate Forminator. The version displayed should read 1.56.2 or higher. If auto-updates are enabled and the plugin shows an older version, the update may have failed silently — trigger a manual update and check server disk write permissions on wp-content/plugins/.

Sources: