A visitor can make a public Forminator form accept a PHP upload on WordPress sites running the plugin through version 1.56.1. The Wordfence CNA record for CVE-2026-15748 describes two validation failures that let an unauthenticated submission supply its own upload rules and slip the file past the dangerous-extension check.
Wordfence disclosed the flaw on August 17, and CERT-In rated it critical two days later. WPMU DEV had already shipped the first fixed release, Forminator 1.56.2, on July 30. The current WordPress.org release is 1.57.1 and supersedes that fix.
Forminator has more than 600,000 active installations, according to its WordPress.org plugin page. The sources do not quantify how many installations remain vulnerable, and they do not report exploitation in the wild. CISA’s enrichment in the CVE record marks exploitation as none.
For a related WordPress upload-risk workflow, see Nulltap’s coverage of the Elementor Pro upload flaw.
Forged fields rewrite upload rules
Forminator normally lets an administrator decide which fields accept files and which MIME types are allowed. CVE-2026-15748 crosses that trust boundary inside the public submission flow. A forged Select field value is accepted as attacker-controlled upload-field configuration, so the request can reach handle_file_upload with rules the site owner did not create.
The second failure sits in the dangerous-extension blocklist. The handler performs an exact-key lookup, while WordPress MIME mappings can express alternatives with a pipe, such as jpg|jpeg|jpe. Wordfence found that a crafted pipe-alternative key could avoid the lookup and allow an extension such as .php to survive validation.
Figure details
The chain begins with an unauthenticated submission carrying a forged Select field value. Forminator treats that value as upload-field configuration. A pipe-alternative MIME key then misses the dangerous-extension blocklist's exact-key check. The server can store a PHP file in a web-accessible upload location, where execution depends on the web server's PHP handling. The figure separates the proved validation bypass from the deployment-specific execution condition.
An uploaded file becomes remote code execution only when the server treats that file as executable content. The CNA scores the flaw 9.8, with high confidentiality, integrity, and availability impact. CERT-In says successful exploitation could lead to complete website compromise.
The published evidence establishes capability. It does not establish a campaign, victims, or a known attacker. Defenders should treat an executable file in a public upload tree as a high-priority finding while preserving the request, process, and filesystem evidence needed to determine how it arrived.
One release closes the path
The Forminator release history gives the vendor response in one line: “Fix: Arbitrary file upload vulnerability.” That entry belongs to version 1.56.2. Every release through 1.56.1 is affected; 1.56.2 is the first fixed version, and 1.57.1 is the current superseding release as of August 24.
Inventory the installed version before relying on the WordPress dashboard. From the site root, WP-CLI can print the active package version:
wp plugin get forminator --field=versionAn output of 1.56.1 or earlier is vulnerable. Update to the current release, then run the same command again:
wp plugin update forminator
wp plugin get forminator --field=versionThe expected result is 1.57.1 or a later vendor release. If operational constraints require a pinned build, 1.56.2 is the minimum fixed version, but it has already been superseded by subsequent security releases.
A web application firewall can add useful telemetry and may block known payload shapes. It cannot prove that the vulnerable upload boundary has been removed. The affected code trusts forged configuration before the dangerous-extension decision, so the durable control is a fixed plugin release.
Verify versions and uploaded code
Record the Forminator version across every WordPress instance, including inactive copies retained on disk. Prioritize internet-facing sites with public Forminator forms and file-upload fields. Preserve web access logs, PHP or FastCGI logs, WordPress audit records, filesystem timestamps, and outbound connection telemetry for vulnerable systems.
Search the WordPress upload tree for executable extensions created since the vendor was notified on July 14. Adjust the root when WordPress uses a custom content directory:
find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \) -newermt '2026-07-14' -printThis command is a triage query. A match does not prove exploitation. For each result, capture its hash, owner, permissions, creation and modification times, surrounding files, first HTTP request, and any PHP worker or child-process activity. Also search logs for requests that immediately retrieve a newly uploaded executable or are followed by unexpected outbound connections.
Use a staging copy for the verification test. Submit an allowed benign file through each public Forminator upload field after updating, then confirm that the form still works and that the server stores only the configured type. The expected result is a current plugin version, a successful permitted upload, no executable extension in the upload tree, and no PHP execution from that location.
The fix is a small version boundary around a consequential trust failure. Teams that pair the upgrade with an upload-tree review can close the vulnerable path and still answer the harder incident question: whether an older public form accepted code before the patch arrived.