Gravity Forms

CVE-2026-19513 affects Gravity Forms up to and including 3.0.2. Public forms with a multi-file upload field can expose an unauthenticated arbitrary file upload path through chunk-state validation confusion. Update to 3.0.3 or newer and verify upload execution controls.

CVE-2026-19513 is a newly disclosed Gravity Forms vulnerability affecting versions up to and including 3.0.2. Wordfence published the record on September 1, 2026 and reports that the issue can be reached without authentication when a public form contains a File Upload field with Multiple Files enabled.

The practical risk depends heavily on the web server. Gravity Forms normally places a .htaccess file in its temporary upload directory, which blocks direct PHP execution on Apache when overrides are honored. NGINX and other servers that do not enforce that .htaccess control need an equivalent server-level deny rule.

Table of Contents

Vulnerability summary

Product: Gravity Forms
CVE: CVE-2026-19513
Affected versions: Gravity Forms <= 3.0.2
Fixed version: 3.0.3
Severity: CVSS 8.1 High
Attack class: Unrestricted upload of a dangerous file type, CWE-434
Required privilege: none
User interaction: none
Known exploitation: Wordfence reported 6 blocked attacks in the past 24 hours at publication time
CISA KEV: not listed at publication time

Technical cause

The issue is in the multi-file asynchronous upload flow handled by GFAsyncUpload::upload(). Public form state URL hashes can be reused as chunk continuation hashes, and temporary filenames are accepted before final sanitization. Under the right form configuration, that lets an unauthenticated attacker place a file with an attacker-selected public filename in the Gravity Forms temporary upload directory.

On servers where PHP execution is blocked in that directory, the impact is reduced but not eliminated: attacker-written HTML can still create same-origin stored XSS if someone opens the generated file URL. On NGINX or any stack that does not honor Gravity Forms’ directory-level .htaccess protection, a PHP-capable upload directory can turn this into remote code execution.

Immediate remediation

Update Gravity Forms to 3.0.3 or newer.
Identify public forms using File Upload fields with Multiple Files enabled.
Confirm that PHP and HTML execution is blocked from Gravity Forms temporary upload paths.
Review the temporary upload directory and the general uploads directory for unexpected PHP, HTML, or polyglot-looking files.
If suspicious files are found, preserve logs before cleanup and rotate WordPress administrator credentials after containment.

WP-CLI checks

wp plugin get gravityforms --fields=name,version,status
wp plugin update gravityforms
wp plugin get gravityforms --field=version

Search for recently modified executable files under common upload paths. Review every hit manually before deleting anything:

find wp-content/uploads -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.html' \) -mtime -14 -print
find wp-content/uploads/gravity_forms -type f -mtime -14 -print
wp core verify-checksums
wp plugin verify-checksums --all

Server hardening

If you run NGINX, add an explicit deny rule for executable extensions under WordPress uploads. Adjust the path to match your site, then reload NGINX after testing the syntax:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar|shtml|html)$ {
    deny all;
    return 403;
}

For Apache, confirm that override rules are honored and add a directory-level control if your hosting stack allows it:

<FilesMatch "\.(php|phtml|phar|shtml|html)$">
    Require all denied
</FilesMatch>

Log review

grep -Ei 'gravity_forms|gf_page|admin-ajax.php|async_upload|upload' /var/log/nginx/access.log*
grep -Ei 'gravity_forms|gf_page|admin-ajax.php|async_upload|upload' /var/log/apache2/access.log*

Large bursts against public forms, followed by requests for newly created files under uploads, should be treated as a compromise lead.