Critical 9.8 file upload flaw in WordPress Forminator plugin fixed in 1.56.2

A critical-severity vulnerability in Forminator Forms, a widely used WordPress form builder, allows unauthenticated attackers to upload arbitrary PHP files to a site and execute them. Tracked as CVE-2026-15748 and rated 9.8 on the CVSS 3.1 scale, the flaw affects version 1.56.1 and earlier and was fixed in 1.56.2. According to a technical write-up published on dev.to, which reconstructs the bug from Wordfence's public advisory, the plugin is active on more than 600,000 WordPress sites, and the issue was reported by a researcher using the handle daroo through Wordfence's bug bounty program.

There is one prerequisite: the targeted form must contain both a File Upload field and a Select field.

Two weaknesses that combine

The write-up explains that the remote code execution is not the result of a single mistake but of two independent weaknesses that compose into one exploit chain.

The first sits in how Forminator decides which file types an upload field accepts. Form submissions are handled through an admin-ajax.php action that requires no authentication, and the allowed-type configuration for the upload field is assembled from data carried in the request rather than read from the form definition stored on the server. That means an attacker can embed a forged upload-field configuration inside the value of an unrelated field — the Select field — and redefine what the upload field accepts at submission time, even if the administrator had restricted it to image formats such as jpg or png.

The second weakness is in the plugin's remaining safety check: a blocklist of dangerous extensions and MIME types inside the upload handler. The check looks up the submitted MIME type as an exact key in a PHP array, with no normalization of the input. Appending a single pipe character to the MIME string defeats it: a type of "application/x-php" is blocked, but "application/x-php|" matches no entry in the blocklist and passes through.

With both flaws combined, an attacker controls the uploaded file's name and its contents, so a PHP file with attacker-chosen code can be written into the upload directory.

Custom storage removes the final safeguard

By default, Forminator's upload directory contains a .htaccess file that disables PHP execution, so an uploaded .php file is often served as inert text rather than run. The write-up, citing Wordfence's advisory, notes that this protection effectively disappears when an administrator configures a custom file upload storage root. The .htaccess is supposed to be generated when a frontend submission is processed, but the WordPress helper function that writes it is not loaded on that code path. As a result, files can accumulate in the custom directory with no execution safeguard ever having been created, and simply requesting the uploaded file by URL is enough for the server to execute it as PHP — no authentication or further tricks required.

What changed in 1.56.2

The fix in Forminator 1.56.2 addresses both structural problems. An upload field's allowed file types are now taken exclusively from the form configuration stored on the server, so request data can no longer redefine them. The dangerous-type blocklist comparison was also changed to normalize input before matching, which means trailing delimiters like the pipe character no longer bypass the check.

Administrators running Forminator should update to 1.56.2 as soon as possible. Sites using a custom upload storage root, or forms that combine Select fields with File Upload fields, fall squarely within the vulnerable configuration described in the advisory.

Why it matters

A 9.8-rated flaw that needs no authentication, no privileges and no user interaction, on a plugin with a six-figure install base, sits near the ceiling of what a WordPress vulnerability can cost a site — the CVSS vector recorded in the advisory implies high impact on confidentiality, integrity and availability alike. Beyond the immediate patching urgency, the bug is a compact lesson in two recurring design mistakes: trusting client-supplied data where a server-side setting belongs, and implementing a blocklist as an exact string match rather than a normalized comparison. Both are cheap mistakes to make and, as this case shows, very expensive when they coincide.