SURIQ
A form-builder plugin on more than 600,000 WordPress sites shipped a quiet fix on July 31. The technical writeup landed on August 17. That gap is the whole story. CVE-2026-15748 lets an unauthenticated visitor upload a PHP file through a vulnerable Forminator form and run code on the server, and it carries a CVSS score of 9.8. Sites still on version 1.56.1 or earlier are the exposed set, and the exploitation clock did not start on patch day. It started when the details went public.
Two things narrow and sharpen the risk at the same time. The flaw only fires where a form combines a dropdown menu with a file-upload field, so not every Forminator install is reachable. But where a form matches that shape, no login, no user account, and no social engineering are needed. As of publication there is no public proof-of-concept and no confirmed exploitation in the wild, which is exactly the window a defender wants to use.
How the upload filter gets bypassed
Forminator tries to block dangerous uploads with a denylist of file extensions. The problem sits in how that list is checked. According to the disclosure, the handle_file_upload function matches the denylist by exact key, and an attacker can slip past it with a compound MIME type key that uses a pipe-alternative form the lookup never anticipated. The public submission handler then trusts the upload-field configuration the request supplies, so the attacker controls the parameters that were meant to constrain them.
This is a denylist failure, and denylists fail this way over and over. Anything not explicitly forbidden is permitted, so the defender has to predict every dangerous encoding in advance. The durable fix is the opposite posture: an allowlist of permitted types plus server-side inspection of the actual file contents, not a string match on a label the client can shape.
The .htaccess guard is not the guarantee it looks like
On a default install, Forminator drops a .htaccess file into its upload directory that stops the server from executing anything there, so an uploaded PHP file sits inert. That protection is real, but it is conditional in two ways worth understanding before you assume you are safe. First, it only works on a web server that honors .htaccess at runtime. Second, it only covers the default storage path.
Here is the trap. Moving uploads off the default directory is something operators do to harden a site. With this bug, that same move can strip away the one control keeping an uploaded shell from running. A custom storage path that lacks the .htaccess drop turns a blocked upload into a live one. A hardening instinct inverts into exposure, which is why patching, not directory hygiene, is the fix.
Why the danger starts now, not on patch day
The 1.56.2 release closed the hole on July 31, but a fix in an open-source plugin is also a map. The change that repairs a denylist bypass is small and readable, and the difference between the vulnerable and fixed code points straight at the trick. Once the writeup went public on August 17, reproducing the bypass became a matter of reading a diff, not original research. For any site still on 1.56.1, the practical exposure is higher today than it was the day the patch shipped.
A pattern worth naming in WordPress plugin code
This is the third file-handling weakness in a widely installed WordPress plugin we have covered this month. We wrote up a set of plugins found to contain a hidden admin web shell and an unauthenticated stored cross-site scripting bug in Bookly. The common thread is not one vendor. It is that plugins accept attacker-influenced input at the edge of the site, and the validation between that input and the filesystem or the page is where the bodies are buried. A pre-auth flaw in WordPress itself earlier this month made the same point from the core side.
Update to 1.56.2, then watch the upload directories
The first action is the update. Move every site running Forminator to 1.56.2 or later. If you cannot patch at once, the interim step is to check whether any live form combines a file-upload field with a dropdown, and remove the upload field until you can update.
Patching closes the hole, but it does not tell you whether someone reached a form in the window before you updated. That is a detection question, and it has a clean answer if you run WordPress on servers you can watch. The payload here is a file written to disk under the uploads path. File integrity monitoring flags a new executable file appearing where only user uploads should live, whatever plugin or bug let it in. A managed detection setup ties that file-write event to an alert an analyst actually sees, mapped to the relevant attacker technique, so a dropped web shell surfaces as a signal rather than sitting quietly until it is used.
The vulnerable population here is not defined by who runs Forminator. It is defined by who runs Forminator with a matching form and has not read a changelog in three weeks. That describes a lot of sites. Treat the quiet July fix as the loud August problem, and get to 1.56.2 before someone else reads the same diff you could.