In August 2026 two of the most widely installed WordPress form plugins each disclosed a critical, unauthenticated remote-code-execution vulnerability in the same place: file-upload handling. Elementor Pro's fix landed on 19 August 2026; Forminator's had shipped on 31 July 2026. Different plugins, different bugs, one lesson for anyone running client sites with public forms.
Elementor Pro: validation that stopped early
CVE-2026-32475 affects Elementor Pro up to and including 4.2.1 and is fixed in 4.2.2, released 19 August 2026. The Forms widget's File Upload field validates and stores uploads in two passes. Submitting an empty file part immediately before a malicious PHP file caused validation to stop on the empty entry, so the PHP file behind it was never checked and was stored anyway. Exploiting it needs a public Elementor Pro form with File Upload and the "multiple file upload" option on (off by default), and no authentication at all. Discovered by researcher Tin Pham (TF1T), reported through Patchstack.
Forminator: a wider blast radius and a longer patch gap
CVE-2026-15748 (CVSS 9.8) affects Forminator Forms, installed on over 600,000 sites. The cause is insufficient file-type validation in the plugin's handle_file_upload function, bypassable by forging Select field values and using pipe-alternative MIME type keys. Patched in 1.56.2 on 31 July 2026; every version up to 1.56.1 is vulnerable. Defiant, Wordfence's parent company, disclosed it and reported no confirmed exploitation at publication, but noted that sites using a custom, non-default upload location lose the protected-directory safeguard, which would allow a planted web shell to compromise the site fully. Roughly half of the installed base, around 300,000 sites, was still on a vulnerable version when the flaw went public.
| Aspect | Elementor Pro | Forminator |
|---|---|---|
| CVE | CVE-2026-32475 | CVE-2026-15748 (CVSS 9.8) |
| Vulnerable | Up to 4.2.1 | Up to 1.56.1 |
| Fixed in | 4.2.2, 19 August 2026 | 1.56.2, 31 July 2026 |
| Needs | Public form, File Upload with "multiple" on; no login | Public form with file upload; no login |
| Worst case | PHP file stored under wp-content/uploads/elementor/forms/ | Web shell, full compromise on custom upload paths |
The pattern is the upload field
Both bugs sit in a form field built to accept a file from an untrusted visitor, where the validation had a gap an attacker could route around. Neither needed a tricked administrator or a stolen password. Both worked against a form in plain view. File-upload fields in any form plugin are a standing risk to monitor, not a setting to configure once.
What to check on your own sites
- Elementor Pro on 4.2.2 or later. If any form uses File Upload with multiple uploads, look in
wp-content/uploads/elementor/forms/for files that should not be there, especially anything ending in .php. - Forminator on 1.56.2 or later. If you cannot update today, disable file-upload fields on public forms until you can.
- On any site with a form plugin that accepts uploads, avoid custom upload paths that move files outside the platform's default protected directory. That default limits what a bypass like this can do.
Auditing what a form plugin's upload handling does is a smaller version of the question the BdThemes incident raised: where does trusted-looking functionality quietly accept something it should not.
Two things to do this week on every site with a public form
- Stop PHP from running inside the uploads folder. On Apache, a small .htaccess file in wp-content/uploads that denies execution of PHP files; on nginx, a location rule that returns 403 for PHP under uploads. Both bugs above needed a PHP file to be stored and executed. Removing the second half turns a critical vulnerability into a stored file that does nothing.
- List every form with an upload field. Most sites have one contact form and no uploads. The ones that do accept uploads, a job application form, a warranty claim, a photo for a quote, are the ones to review: what file types are allowed, where files land, and who can reach that folder.
How to know an upload field was used against you
Look in the upload folder the form plugin uses for files with a .php extension or a double extension such as image.jpg.php, and for files whose timestamps do not match any real submission. Compare against the form's own entries: a file in the folder with no matching entry was not uploaded through the form as intended. Then read the access log for the first request to that file; that is the moment the shell was first used.
A monthly form audit that takes ten minutes
- Form plugin on the current version on every site. This is the whole story for most sites.
- No upload field on a form that does not need one. Remove rather than restrict.
- Uploads cannot execute, as above.
- Submissions go to a mailbox someone reads. A form that has been broken for a month is its own kind of incident.
Sources
- cybersecuritynews.com, "Critical WordPress Plugin Vulnerability Exposes Sites to RCE Attacks" (Elementor Pro, CVE-2026-32475)August 2026
- SecurityWeek, "300,000 WordPress Sites Potentially Exposed to Hacking Due to Form Plugin Flaw" (Forminator, CVE-2026-15748), disclosed by DefiantAugust 2026