WPMU DEV Forminator Forms (WordPress, 600,000+ installs) — unauthenticated arbitrary file upload to remote code execution in handle_file_upload: the dangerous-extension blocklist matches MIME-type keys exactly and is bypassed by a pipe-alternative key, while a forged Select-field value overrides the upload field's own type configuration. CVSS 9.8, Wordfence as CNA. Exploitable only on forms carrying both a File Upload and a Select field. Fixed in 1.56.2 (2026-07-31); root-cause write-up published 2026-08-17, relayed by NCSC-CH 2026-08-18. No exploitation reported.

CVE-2026-15748 — Forminator Forms (600,000+ WordPress sites): a forged Select-field value overrides the upload allow-list, and the root cause went public seventeen days after the patch (CVSS 9.8)

Wordfence published the technical write-up for CVE-2026-15748 on 2026-08-17, seventeen days after the fix shipped, and Switzerland's NCSC relayed the disclosure to its own constituency the following day alongside three other WordPress plugin flaws (NCSC-CH Cyber Security Hub, 2026-08-18). The flaw affects the Forminator Forms plugin, which carries more than 600,000 active installs, and it is rated CVSS 9.8 with Wordfence acting as CVE Naming Authority: "The Forminator Forms plugin for WordPress is vulnerable to Arbitrary File Upload in all versions up to, and including, 1.56.1 via the handle_file_upload function" (Wordfence Intelligence, 2026-08-17).

The mechanism is two defects meeting. The upload screen is a blocklist of dangerous extensions matched against MIME-type keys, and it compares those keys exactly — so a key expressed in pipe-alternative form is simply not found in the list and the file passes. Separately, the public submission handler trusts the upload field's type configuration as submitted, which means a forged value in a Select field on the same form can rewrite what the upload field is willing to accept. Wordfence's own description puts both halves together: the blocklist "performs exact-key matching that is bypassed by pipe-alternative MIME type keys, combined with a public submission handler that trusts attacker-controlled upload field configuration injected via a forged Select field value" (Wordfence Intelligence, 2026-08-17). The consequence is a PHP file written into the site and executed — full site compromise, with no authentication required. The concrete payload pattern Wordfence publishes is omitted here.

Two preconditions decide which of those 600,000 sites actually matter, and they are unusually easy to check. First, the form itself: "The vulnerability is only exploitable on sites that have a form containing both a File Upload field and a Select field" (Wordfence Intelligence, 2026-08-17) — an installation with no such form is not reachable by this path, which turns a plugin-version sweep into a much smaller, form-level triage. Second, and cutting the other way, the built-in mitigation is not always present. By default uploads land in a directory whose .htaccess file blocks PHP execution, but Wordfence notes that "if an administrator has configured a Custom File Upload Storage root, that root can end up without the .htaccess protection because it is created only when it is first needed" during a frontend request where the helper that writes that file is not loaded (Wordfence Intelligence, 2026-08-17). A site that looks hardened by default configuration may not be, and the deciding factor is an administrator setting rather than the plugin version.

The timeline is what puts this in scope now rather than in July. Wordfence's published timeline records the submission from the researcher credited as daroo arriving through its bug-bounty programme on 2026-07-11, validation and full disclosure to the vendor on 2026-07-14, the vendor submitting a patch for review on 2026-07-20, release of the fully patched 1.56.2 on 2026-07-31, and the root-cause write-up on 2026-08-17 (Wordfence Intelligence, 2026-08-17). Neither Wordfence's post nor the Swiss advisory reports observed exploitation — Wordfence makes no statement either way about attempts in the wild, and NCSC-CH records the exploitation status for its whole four-CVE bundle as unknown (NCSC-CH Cyber Security Hub, 2026-08-18). That absence is not reassurance here: the mechanism is now public in enough detail to rebuild, the affected estate is large, publicly enumerable and largely unmanaged, and WordPress plugin flaws of this class are routinely mass-scanned within days of a write-up. This pipeline has already covered Swiss websites compromised through a WordPress chain and repurposed to serve paste-and-run lures, so the downstream consequence for this constituency is not theoretical.

Detection concentrates on the file-system outcome, because the request that produces it is an ordinary form submission. In web and file-integrity telemetry, the durable signals are new or modified .php files appearing anywhere under the WordPress root — especially inside upload directories, which should never contain executable code — and subsequent direct HTTP requests to those paths, which is the step that turns an uploaded file into execution. In access logs, POST submissions to the plugin's public form-submission endpoint followed within seconds by a GET to a newly created path under the uploads tree is the sequence worth alerting on. Triage: legitimate form traffic uploads files to those same directories all day, so an upload event alone is meaningless — the discriminators are the file extension, whether the file is subsequently requested directly rather than only referenced by an administrator viewing the submission, and whether the storage directory carries its execution-blocking configuration. Hardening beyond the update is the same control the default configuration already relies on: ensure PHP execution is blocked in every directory that receives uploads, including any custom storage root.