Forminator’s 9.8 Flaw, and Eleven More Fixes in Nineteen Days

A critical vulnerability in Forminator Forms, a WordPress form builder with more than 600,000 active installations, lets an unauthenticated attacker upload an executable PHP file. It scores 9.8 of 10 and needs no login and no click from anyone.

The score describes the worst case. Reaching it needs a form built a particular way and a site configured a particular way, and neither condition travels with the headline number.

The dates are worth as much. The fix shipped on 31 July, seventeen days before the flaw became public, and the plugin’s own changelog records twelve security releases in nineteen days, of which this is one.

Key facts

• The vulnerability: CVE-2026-15748, CWE-434, CVSS 9.8 critical. Unauthenticated arbitrary file upload leading to remote code execution. Affects every version up to and including 1.56.1.
• The fix: version 1.56.2. Wordfence dates its release to 31 July; the plugin repository dates it to 30 July.
• What to run: 1.57.1, released 18 August. It includes the fix for this flaw and all nine security fixes released that day; 1.56.2 was the first version to close CVE-2026-15748.
• Two conditions: the form needs both a File Upload field and a Select field, and code execution depends on whether the upload directory actually blocks script execution. Forminator’s default protection is an .htaccessfile. Apache can enforce it, NGINX does not read .htaccess, and behavior on LiteSpeed-based stacks depends on the server product and configuration.
• Timeline: reported 11 July, sent to the vendor 14 July, patch submitted for review 20 July, published by Wordfence 17 August, added to the national vulnerability database 18 August.
• Found by: a researcher credited as daroo, through the Wordfence bug bounty program, for $2,048.
• What the changelog shows: three security releases on 30 July and nine more on 18 August, addressing different problems.

A Blocklist That Matched the Wrong Way

Forminator strips dangerous extensions from the list of file types a form will accept, and the function doing that removes the literal key php. It does not remove the equivalent pattern-style key ph(p), because the blocklist compares keys exactly rather than interpreting them.

WordPress, further down the chain, does interpret them. Supplying the extension and MIME pattern ph(p)|text/x-php gets past the extension check while still describing a file ending in .php, so validation passes on a file the plugin believes it has already rejected.

Reaching that function is the other half. Forminator’s generic request sanitizer deliberately returns the nested values of select, radio and checkbox fields unchanged, leaving each field type to sanitize its own data later. An attacker uses a Select field on a published form as a carrier, injecting a forged upload record with its own field name and configuration. The upload handler then treats that attacker-supplied configuration as trusted and accepts the custom MIME types it declares.

Two Conditions the Headline Number Does Not Carry

A CVSS score describes the worst case, not the population. Wordfence is explicit that the flaw “is only exploitable on sites that have a form containing both a File Upload field and a Select field”. The Select field is the carrier and the Upload field is the destination, and a form with only one of them is not a route in. So 600,000 installations is the size of the user base, not the size of the exposure, and what share of those forms combines both field types is not something we could establish.

The second condition decides whether an uploaded file runs, and it is where a hosting audience should read carefully. By default Forminator writes uploads into a directory carrying an .htaccess file that forbids execution. That is an Apache mechanism, and it does not travel.

NGINX does not read .htaccess at all, so on an NGINX stack the file sits in the directory doing nothing unless an equivalent rule exists in the server configuration. LiteSpeed Web Server supports Apache-style .htaccess to varying degrees depending on configuration, and OpenLiteSpeed reads only rewrite rules from it, silently ignoring other Apache directives. Forminator’s protective file is built from directives of exactly that other kind, so the protection should not be assumed to behave the same across LiteSpeed stacks.

There is a second way to lose it. Sites that moved uploads to a custom storage root can end up without the file entirely, because it is written only when first needed, during a front-end request, at a point where the WordPress helper that creates it is not loaded. Without an equivalent server-side execution block, a direct request to the uploaded PHP file can reach the PHP handler and execute it.

None of this makes the vulnerability less real for the sites that meet both conditions, where the outcome is full compromise. It does mean the honest description is a serious flaw with a narrower blast radius than the install count suggests. SecurityWeek estimated that more than 300,000 sites were still running vulnerable versions when the details went public, which is a count of unpatched installations rather than exploitable ones.

Twelve Security Releases in Nineteen Days

We read the plugin’s changelog through the WordPress.org API rather than the coverage of it, and the single CVE turns out to be one entry in a run.

The nine releases dated 18 August are separate problems, published the day after Wordfence disclosed the file upload flaw. Three of them credit a contributor named Jakub Herman. Five earlier releases going back to April also carry security entries described only as “security improvements”, without specifying what was fixed.

Read together, the pattern is a plugin under sustained security attention, whether from a coordinated review or from accumulated findings arriving at once. Both readings point the same way for anyone running these sites: a single patch is not the end of the update cycle here.

Why This Lands on the Host, Not Just the Site Owner

An unauthenticated file upload on a plugin this widely installed is a shared hosting problem before it is a website problem. A compromised account on a shared server becomes a source of spam, a staging point for further scanning, and an abuse report against the provider’s address space. The site owner discovers it late; the host discovers it through its own monitoring or through a blocklist.

The dates matter here too. The patched version was available from the end of July, so any site with automatic plugin updates enabled was covered before the public disclosure. Sites that update manually learned about the flaw on the same day as everyone else, including anyone building an exploit from the published analysis. That gap is the argument for automatic updates, and it is also the argument for hosts that patch on their customers’ behalf.

Wordfence says its firewall, including the free version, blocks exploitation through a built-in malicious file upload rule. We have seen no report of exploitation in the wild.

The version to be on is 1.57.1. Anything from 1.56.2 upward closes the file upload flaw, but only 1.57.1 includes all nine security fixes released on 18 August. A site sitting on 1.56.2 today is patched against the vulnerability that made the news but not against those later fixes.

About the Data

The vulnerability record, score, vector and affected range come from the national vulnerability database entry for CVE-2026-15748. The install count, version history and release dates come from the WordPress.org plugin API and the plugin’s own listing, read on 20 August. The disclosure timeline, the researcher credit, the bounty and both exploitability conditions come from Wordfence’s published analysis. The estimate of unpatched sites is SecurityWeek’s. WPMU DEV has not commented to us.