Forminator trusts a forged upload: a dropdown flaw exposes 600,000 WordPress sites to RCE

Wordfence Intelligence disclosed CVE-2026-15748 on 17 August 2026, a high-severity flaw in the Forminator Forms plugin for WordPress that lets an unauthenticated attacker save a PHP file to affected servers ^[1][2][3][4]. Wordfence puts the exposed population at roughly 600,000 sites, and the failure is not a missing check so much as a misplaced trust: Forminator accepts upload configuration that the attacker smuggles into an unrelated field ^[1][2].

The precondition is narrow but common. The site needs a public Forminator form that carries both a File Upload field and a Select field, running version 1.56.1 or earlier ^[5][7]. The attacker injects a fake record into the nested value of the Select field, one that carries `return`, `field_type=upload`, a custom `name`, and a `field_array` ^[8]. Forminator's `set_field_data()` writes that record into its internal `field_data_array` ^[9]. Because a genuine File Upload field is present on the form, `process_uploads()` runs and treats the forged record as a legitimate upload setting ^[10]. From there the attacker controls the custom file type and the `additional-type` value ^[11].

The extension check is where the second mistake compounds the first. Forbidden extensions are blocked by exact match, so the attacker submits `ph(p)|text/x-php` ^[12]. That string is not an exact match for the key `php`, so it clears the blocklist, but the WordPress matcher resolves `ph(p)` back to `.php`, and the server writes the file ^[13][14]. No account and no administrator action are required, and the initial request is anonymous ^[16].

Whether the write becomes remote code execution depends on the storage root. If the custom File Upload directory lacks execution prevention such as an `.htaccess` rule, the attacker fetches the saved URL and runs the code ^[15]. Wordfence notes that default protected upload directories can still refuse to execute PHP even after a successful save, which is the difference between an arbitrary file write and a full compromise ^[17]. That caveat is the one thing standing between many sites and a web shell, and it is a configuration accident rather than a defence anyone chose.

The fix is to update to 1.56.2 ^[6]. Short of patching, removing the File Upload and Select combination from public forms closes the path, and a WAF or a server rule that blocks PHP execution in the upload directory reduces the impact ^[18]. For detection, Wordfence points to POST requests where a Select field carries unusual nested arrays or `field_type=upload`, abnormal `additional-type` patterns, randomly prefixed PHP files in the upload directory, and a GET to a newly written PHP URL from the same address moments after the POST ^[19]. SecurityWeek is listed as a related source ^[20].

What to watch: whether exploitation scales now that the mechanism is public, and how many of the 600,000 sites sit on storage roots that happily run PHP.