Forminator Forms <= 1.56.1 - Unauthenticated Arbitrary File Upload
Forminator Forms versions up to 1.56.1 contain a critical unauthenticated arbitrary file upload vulnerability. Update to 1.56.2 or later and review public forms that combine Select and File Upload fields.
Quick answer: Forminator Forms versions up to and including 1.56.1 are vulnerable to unauthenticated arbitrary file upload under specific form configurations. Sites should update to 1.56.2 or later immediately. The plugin directory currently lists 1.57.0 as the latest version.
Wordfence published the advisory on August 17, 2026. The issue is tracked as CVE-2026-15748 with a CVSS score of 9.8. Wordfence credits researcher daroo and reports that the vendor released a patched version on July 31, 2026.
Affected software
Plugin: Forminator Forms – Contact Form, Payment Form and Custom Form Builder
Affected versions: 1.56.1 and earlier
Fixed version: 1.56.2. WordPress.org currently shows 1.57.0 as the latest version and 600,000+ active installations.
Attack class: unauthenticated arbitrary file upload, with remote code execution possible if the uploaded file lands in a location where the web server can execute PHP.
When a site is exposed
The vulnerable path requires a public Forminator form that contains both a File Upload field and a Select field. According to Wordfence, the issue comes from a chain where submitted Select-field data can influence the internal upload-processing data structure, and the upload handler then trusts attacker-controlled field configuration too far.
The second part of the chain is file type validation. The plugin attempted to remove dangerous extensions, but the blocklist matched exact keys. That allowed an equivalent extension/MIME pattern to avoid the blocklist while still being interpreted as a PHP upload by WordPress file-type matching. This article intentionally does not include the bypass payload.
Wordfence also notes an important hosting condition: Forminator normally places uploads in a directory protected by an .htaccess rule that blocks PHP execution. Risk increases where a custom upload storage root is used and that directory does not have equivalent execution blocking.
Immediate remediation
Update Forminator first. If you cannot update immediately, temporarily disable public forms that combine File Upload and Select fields, or remove the upload field until the plugin is patched.
# Check the installed version
wp plugin get forminator --field=version
# Update to the latest available release
wp plugin update forminator
# Confirm the active version after updating
wp plugin get forminator --field=version
Then review any custom upload locations used by Forminator or other form plugins. Upload directories should store user files, not execute them.
Block PHP execution in upload directories
For Apache, place an .htaccess rule in the upload directory or custom storage directory. Keep the rule simple: deny script-like extensions and allow static files to remain downloadable.
<FilesMatch "\.(php|phtml|php3|php4|php5|phar)$">
Require all denied
</FilesMatch>
For Nginx, block PHP execution under upload paths at the server configuration layer.
location ~* /wp-content/uploads/.*\.(php|phtml|php3|php4|php5|phar)$ {
deny all;
}
If Forminator uses a custom storage path, add an equivalent rule for that path too. Restart or reload the web server after changing Nginx configuration.
Check for suspicious uploaded files
Wordfence did not publish campaign-specific indicators of compromise in the advisory. The practical check is to look for script files inside upload directories, especially near the time public forms received submissions.
# Linux/macOS shell
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -print
# WP-CLI path check
wp eval 'echo wp_upload_dir()["basedir"] . PHP_EOL;'
Any PHP-like file in an upload directory should be treated as suspicious unless you can prove why it belongs there. Preserve a copy for forensic review before deleting it, then check web server access logs for direct requests to that file.
Developer-side fix pattern
The safer pattern for upload handling is to use a small allowlist, normalize extensions before comparison, and validate the file with WordPress file APIs before moving it into a public directory.
$allowed_extensions = array( 'jpg', 'jpeg', 'png', 'gif', 'pdf' );
$ext = strtolower( pathinfo( $file['name'], PATHINFO_EXTENSION ) );
if ( ! in_array( $ext, $allowed_extensions, true ) ) {
return new WP_Error( 'invalid_upload_type', 'This file type is not allowed.' );
}
$check = wp_check_filetype_and_ext( $file['tmp_name'], $file['name'] );
if ( empty( $check['ext'] ) || empty( $check['type'] ) ) {
return new WP_Error( 'invalid_upload_signature', 'The file content does not match an allowed type.' );
}
Do not let frontend field configuration decide which executable or script-like file types are accepted. User-submitted form metadata should be treated as request data, not trusted form configuration.
Sources
Primary advisory: Wordfence – 600,000 WordPress Sites Affected by Arbitrary File Upload Vulnerability in Forminator Forms.
Plugin changelog and current release metadata: Forminator Forms on WordPress.org.