Elementor Pro

Elementor Pro versions up to 4.2.1 contain a critical unauthenticated arbitrary file upload vulnerability in the Forms module. Update to 4.2.2 or later and inspect Elementor form upload directories for unexpected executable files.

Quick answer: Elementor Pro versions up to and including 4.2.1 are vulnerable to an unauthenticated arbitrary file upload flaw in the Forms module. The issue can lead to remote code execution when a public form uses the File Upload field. Update Elementor Pro to 4.2.2 or later immediately.

Patchstack published the advisory on August 19, 2026. The vulnerability is tracked as CVE-2026-32475, has a CVSS score of 9.0, and requires no authentication. Patchstack credits Tin Pham, also known as TF1T, for reporting the issue.

Table of Contents

Affected software

Plugin: Elementor Pro, the commercial extension for the Elementor page builder.

Affected versions: 4.2.1 and earlier.

Fixed version: 4.2.2.

Attack class: unauthenticated arbitrary file upload, with remote code execution possible if the uploaded file is executable from the public uploads path.

What is vulnerable

The issue is in Elementor Pro’s Forms module, specifically the File Upload field. Patchstack describes the bug as a validation mismatch: one loop validates uploaded file entries, while a second loop moves files into the public forms directory. Empty upload entries are handled differently between those loops.

That disagreement matters because the extension blocklist is applied during validation, while the final write happens later. A malformed multipart upload can cause the validator and file mover to disagree about which submitted file entry is safe. This article intentionally avoids reproducing the exploit shape or payload.

The highest-risk sites are those running Elementor Pro 4.2.1 or earlier with public forms that allow file uploads, such as job application forms, support forms, quote request forms, and document submission forms.

Immediate remediation

Update Elementor Pro to 4.2.2 or later. If you cannot update immediately, disable public Elementor Pro forms that include a File Upload field until the site is patched.

# Check installed Elementor-related versions
wp plugin list --field=name,version,status | grep elementor

# After updating through WordPress admin or your deployment process, confirm Elementor Pro is no longer <= 4.2.1
wp plugin get elementor-pro --field=version

Because Elementor Pro is a commercial plugin, many sites update it through the WordPress admin, Elementor account/licensing flow, Composer/private repository, or a managed host. Verify that the Pro plugin itself updated; updating only the free Elementor plugin does not fix a Pro-only vulnerability.

Check upload directories

Updating closes the vulnerable path, but it does not remove files that may already have been uploaded. Review Elementor's form upload directory for unexpected executable or script-like files.

# Common Elementor form upload path
find wp-content/uploads/elementor/forms -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" -o -name "*.shtml" \) -print

# Also inspect recently modified files in Elementor uploads
find wp-content/uploads/elementor/forms -type f -mtime -14 -print

If you find suspicious files, preserve a copy for review before deletion, then check web server access logs for direct requests to those filenames. Also review administrator users and recently installed plugins, because successful file upload to RCE can become full site compromise.

Block script execution in uploads

Upload directories should not execute PHP or other server-side scripts. This control does not replace patching, but it limits the impact of upload bugs across form plugins, media tools, and custom upload handlers.

For Apache, place a rule like this inside the relevant upload directory or a parent directory that covers Elementor form uploads:

<FilesMatch "\.(php|phtml|php3|php4|php5|php7|phar|shtml)$">
    Require all denied
</FilesMatch>

For Nginx, block script execution under WordPress uploads at the server configuration layer:

location ~* /wp-content/uploads/.*\.(php|phtml|php3|php4|php5|php7|phar|shtml)$ {
    deny all;
}

Reload the web server after changing Nginx configuration. On managed hosting, ask the host to confirm that PHP execution is disabled inside upload directories.

Developer fix pattern

The defensive pattern is to validate and move the same normalized file entry, and to re-check the extension immediately before the write. Do not let separate loops make different decisions about the same upload request.

$allowed_extensions = array( 'jpg', 'jpeg', 'png', 'pdf', 'doc', 'docx' );

foreach ( $files as $file ) {
    if ( UPLOAD_ERR_NO_FILE === (int) $file['error'] ) {
        continue;
    }

    if ( UPLOAD_ERR_OK !== (int) $file['error'] ) {
        return new WP_Error( 'upload_failed', 'The upload did not complete cleanly.' );
    }

    $ext = strtolower( pathinfo( $file['name'], PATHINFO_EXTENSION ) );

    if ( ! in_array( $ext, $allowed_extensions, true ) ) {
        return new WP_Error( 'invalid_file_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_file_signature', 'The file content does not match an allowed type.' );
    }

    // Move only the exact entry that passed validation.
}

The key rule is simple: the code that authorizes the file and the code that moves the file must operate on the same normalized object with the same empty-entry semantics.