On 17 August 2026, security researchers published technical details for CVE-2026-15748, a CVSS 9.8 critical vulnerability in the Forminator Forms WordPress plugin. Forminator is a contact-form and payment-form builder with 600,000 active installations. The flaw is an unauthenticated arbitrary file upload — any visitor can send a PHP webshell to the server without an account, without a token and without any prior foothold. Once the webshell lands, the visitor becomes someone who can run system commands.
Wordfence received the initial disclosure on 14 July 2026. WPMU Dev released the patched version, 1.56.2, on 31 July. At the time of public disclosure two weeks later, approximately 300,000 of those 600,000 installations were still running a vulnerable version.
How the attack works — two weaknesses, one combined exploit
The vulnerability lives in Forminator's handle_file_upload() function, and it requires two flaws working in sequence.
The first weakness: a blocklist that does not recognise its own entries. Forminator checks uploaded file extensions against a list of blocked types. The check uses exact key matching. An attacker bypasses it by supplying a MIME type key that uses a pipe-separated alternative format — something like application/x-php|application/octet-stream. The parser does not recognise this as matching the blocked PHP entry, so the file passes the check.
The second weakness: the server trusts the upload field configuration supplied in the POST request. A legitimate Forminator form has an upload field configured by the site administrator in the WordPress backend. The public form-submission handler, however, accepts a field configuration injected by the attacker in the same POST request as the file — via a forged Select field value. The server processes the upload using the attacker-supplied configuration rather than the one set by the admin.
The practical result: any visitor who can reach a form containing both a File Upload field and a Select field can upload a PHP file to the web server. That combination is common in contact and order forms.
What an attacker does with the webshell
The moment an attacker's PHP file is uploaded and they know its URL, they have code execution running as the web server process. The post-exploitation path is short:
- Read
wp-config.phpto extract database hostname, name, username and password. - Connect to the database, dump user tables, extract email addresses, hashed passwords and any payment or personal data stored there.
- Deploy a persistent backdoor — a second webshell, a rogue plugin, a modified theme file — that survives updating the Forminator plugin.
- Redirect visitors to external sites, inject SEO spam, or install malware served to anyone who loads a page.
On shared hosting, the impact extends further. When multiple WordPress installations share a single hosting account's file system, a webshell in one of them can often read files belonging to the others. One vulnerable form on one site can become an entry point for every site on that account.
What to do — and why updating is the starting point, not the finish line
Update to version 1.56.2 or later. That closes the upload intake. But it does not remove a webshell that was uploaded before you patched, and it does not change the server configuration that made one executable.
After updating, work through the following:
Check for shells already uploaded. Look inside wp-content/uploads/ for files with the extensions .php, .phtml, .php5 or .phar. None should exist there. If you find any, treat the site as compromised rather than as a false alarm.
Block PHP execution in the uploads directory. Add a .htaccess file inside wp-content/uploads/ containing php_flag engine off. On Nginx, configure the equivalent fastcgi_pass restriction in your server block. This ensures that even a webshell already present cannot run — the server will refuse to pass PHP files from that directory to the interpreter.
Set DISALLOW_FILE_MODS in wp-config.php. Adding define('DISALLOW_FILE_MODS', true); prevents WordPress from writing to the plugin and theme directories, which breaks a common post-exploitation technique where attackers reinstall malware through the plugin installer.
Review uploads for unusual file timestamps. Files with modification dates from before you patched, sitting in directories where nothing should have been written, are a concrete indicator of prior compromise.
On shared hosting where you control neither the web server configuration nor a WAF, the .htaccess execution block is the most impactful single step available to you.
This is the second critical WordPress plugin flaw in eight weeks
CVE-2026-15748 is not an isolated event. The wp2shell vulnerability, published on 20 July 2026, allowed an unauthenticated request to execute code on any WordPress installation — also without authentication, also via a public-facing handler. Before that, CVE-2026-16292 in the Frontend File Manager plugin allowed file upload via a CSRF-triggered path when guest uploads were enabled.
The pattern across all three cases is the same: a plugin registers a public AJAX or REST endpoint that accepts file uploads, validates them using a blocklist or client-supplied configuration, and stores them somewhere the web server will execute. WordPress's plugin architecture means any of the 60,000+ plugins in the repository can introduce this surface without the WordPress core team reviewing it. The platform is not the problem — the trust boundary is.
Why file-upload endpoints need a dedicated test, not just a scanner
The reason this flaw exists is not careless development. It is that blocklist-based file type validation is fragile when the input is attacker-controlled. Developers test against "php" as a MIME key, not against "php|application/x-httpd-php". They confirm a visible extension is not .php, but not that the server refuses to execute a file with an unusual double extension or an unexpected MIME type. They verify that client-side JavaScript rejects the upload, without verifying that the server-side handler performs the same check independently.
The OWASP Testing Guide treats file-upload endpoints as a dedicated testing category. The checks include: whether server-side extension validation is independent of client-side; whether uploaded files land in a non-executable directory; whether the upload path can be influenced by user-supplied input; and whether a renamed file with a dangerous extension can be retrieved at a predictable URL. Automated vulnerability scanners answer some of these questions reliably, but not all of them — several require actually attempting the upload and observing the server's response.
Knowing what your site exposes on the public internet — which endpoints answer, which plugins are installed and at what version, whether your uploads directory executes PHP — is the starting point for answering these questions. ClickScan checks your external attack surface and flags exposed services, missing security headers and configuration issues before someone else finds them.
Sources: The Hacker News, 17 August 2026; SecurityWeek; SecurityOnline; CVEfeed.io; Rapid7. No in-the-wild exploitation had been confirmed at the time of disclosure; treat the exposure risk as researcher-assessed rather than observed-in-the-wild.