On July 31, 2026, WPMU DEV released version 1.56.2 of Forminator Forms to patch CVE-2026-15748, a vulnerability rated 9.8 on CVSS v3. This flaw allowed unauthenticated attackers to upload and execute arbitrary PHP files on WordPress sites running versions 1.56.1 and earlier. The Wordfence threat intelligence team discovered the vulnerability and reported it to the vendor.
Timeline
Discovery to patch: Wordfence identified the vulnerability and coordinated disclosure with WPMU DEV. The vendor released version 1.56.2 on July 31, 2026.
Attack surface: All Forminator Forms installations prior to 1.56.2 were vulnerable. The plugin had no effective file type validation on its upload functionality, allowing any unauthenticated user to submit a form containing a PHP file.
Exploitation path: An attacker could craft a form submission with a malicious PHP payload. Because the plugin failed to validate file extensions or MIME types, the uploaded file would land in a web-accessible directory. The attacker could then request that file directly via HTTP, triggering code execution with the web server's privileges.
Which Controls Failed
Input validation: The plugin accepted file uploads without verifying the file type against an allowlist. This violates the principle that all user input is untrusted until proven otherwise.
Authentication bypass: The vulnerability existed in unauthenticated endpoints. Form submissions didn't require any user session or credential check, expanding the attack surface to anyone who could reach the site.
File storage location: Uploaded files landed in directories accessible via direct HTTP requests. Even if validation had been present, storing user-supplied files in the webroot without execution restrictions creates unnecessary risk.
Configuration defaults: Sites using custom upload directories (a configuration option in Forminator) compounded the risk. Custom paths often bypass WordPress's built-in upload protections, which at least attempt to prevent direct execution of uploaded PHP files in the standard wp-content/uploads directory.
What Standards Require
OWASP ASVS v4.0.3 Requirement 12.3.1: "Verify that user-uploaded files are served by octet stream downloads or from an unrelated domain, such as a cloud file storage bucket. Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file."
PCI DSS v4.0.1 Requirement 6.4.3: "For public-facing web applications, all payment page scripts are managed as follows: The functionality of the script is confirmed, and the script is authorized." While Forminator isn't a payment form by default, any plugin on a PCI-scoped system must meet this bar. Unauthenticated file uploads that execute code clearly fail this requirement.
OWASP Top 10 2021 A03: Injection: File upload vulnerabilities are a subset of injection attacks. The standard explicitly calls out "hostile data used within object-relational mapping (ORM) search parameters to extract additional, sensitive records" and similar patterns. Uploading executable code is the most direct form of injection.
NIST 800-53 Rev 5 SI-10 (Information Input Validation): "Check the validity of the following information inputs: organization-defined information inputs to the system." File uploads are inputs. The control requires validation at the application boundary, not just at the web server level.
Lessons and Action Items
Implement an allowlist-based plugin update policy. Don't wait for vulnerability announcements. Set a maximum age for any plugin version (30 days is reasonable for most environments). Use WP-CLI or a management platform to audit versions across your WordPress estate weekly.
wp plugin list --format=csv | awk -F',' '$4 == "available" {print $1}'
Disable file uploads where you don't need them. Review every form on every site. If a form doesn't require file attachments, disable the upload field in the form builder. This reduces your attack surface even if a future vulnerability emerges.
Move uploads outside the webroot. Configure WordPress to store uploads in a directory that's not directly accessible via HTTP. Serve files through a PHP script that validates the request, checks permissions, and sets appropriate headers. This adds overhead but eliminates direct execution risk.
Apply web application firewall rules for upload paths. If you run ModSecurity, Cloudflare WAF, or similar, create rules that block requests to upload directories if the URL ends in .php, .phtml, or other executable extensions. This won't stop a determined attacker with a zero-day, but it raises the bar.
Audit your plugin inventory monthly. Track which plugins you're running, who maintains them, and when they were last updated. Abandon plugins that haven't seen a commit in 12+ months. The WordPress.org repository shows last update dates; use this as a signal. A plugin with no recent activity is a plugin that won't get emergency patches.
Test your restore process. Before you patch a production site, verify you can roll back. Take a database dump and a filesystem snapshot. Confirm you can restore both in under 30 minutes. Patches sometimes break functionality; you need a known-good fallback.
Scope your compliance boundaries carefully. If you're under PCI DSS, don't run WordPress in the cardholder data environment. If you must, treat every plugin as a custom application and apply Requirement 6.3.2's secure coding practices. That means code review, SAST scans, and penetration testing for every plugin update.
The Forminator vulnerability isn't novel. It's the same file upload mistake developers have made since PHP 4. What makes it significant is the reminder that your security posture is only as strong as your least-maintained dependency. Version 1.56.2 is available. Update today.
