CVE-2026-19513 is an unauthenticated arbitrary file upload vulnerability in Gravity Forms 3.0.2 and earlier. Exploitation requires a public form with a File Upload field and multiple-file uploads enabled. The most severe outcome applies to NGINX and other servers that do not enforce .htaccess rules: an uploaded PHP file may be executed. Gravity Forms 3.0.3 contains the fix.
Priority action: update Gravity Forms to 3.0.3 or later, audit public multi-file upload forms, and verify that your server cannot execute scripts inside
wp-content/uploads/gravity_forms.
CVE-2026-19513 at a glance
| Item | Details |
|---|---|
| Affected product | Gravity Forms plugin for WordPress |
| Affected versions | 3.0.2 and earlier |
| Fixed version | 3.0.3 |
| Severity | High, CVSS 8.1 according to Wordfence |
| Access required | No account required, but a public multi-file upload form must exist |
| Potential impact | File write, stored XSS and, depending on server configuration, remote code execution |
| Public disclosure | September 1, 2026 |
How the vulnerability works
Gravity Forms processes large uploads in chunks. According to the Wordfence technical analysis, GFAsyncUpload::upload() did not adequately validate the state used to continue a multipart upload. An attacker could reuse a public form-state hash as a chunk-continuation hash and control a temporary filename before final sanitization.
This could write a polyglot file—such as valid PNG or PDF data with active content appended—under an attacker-selected .php or .html filename in Gravity Forms' temporary upload directory.
Real-world scope: who is exposed?
Running WordPress alone is not enough. Exploitation requires all of the following:
- Gravity Forms 3.0.2 or earlier is active.
- At least one form is available without authentication.
- The form contains File Upload with Enable Multi-File Upload enabled.
- For PHP execution, the server must allow script processing inside the upload directory.
Gravity Forms normally creates an .htaccess file to stop Apache from executing PHP in its upload directory. NGINX does not interpret .htaccess, so the effective web-server configuration matters. Even when PHP execution is blocked, a same-origin HTML file may still enable stored XSS if a victim visits it.
There is no reliable public active-install count for this commercial plugin and no confirmed global victim count. At publication time, CVE-2026-19513 was not listed in CISA's Known Exploited Vulnerabilities catalog. Absence from that catalog is not evidence that exploitation is impossible and is not a reason to delay patching.
How to check whether your site is vulnerable
1. Check the installed version
Open Plugins → Installed Plugins → Gravity Forms, or use WP-CLI:
wp plugin get gravityforms --fields=name,status,version,update
Version 3.0.2 or earlier needs an update. A vulnerable version does not, by itself, prove compromise.
2. Find public multi-file upload forms
Edit every public form, locate each File Upload field, and check whether Enable Multi-File Upload is enabled. Record whether authentication is required. This identifies actual exposure instead of relying on version alone.
3. Verify upload-directory protections
The default temporary path is typically below wp-content/uploads/gravity_forms/<form_id>/tmp/. On Apache, you can check whether the defensive file exists, although existence does not prove that the server enforces it:
find wp-content/uploads/gravity_forms -maxdepth 2 -name .htaccess -print
On NGINX, inspect the effective virtual-host configuration because NGINX ignores .htaccess.
How to patch CVE-2026-19513
Create a tested backup, update through the official licensed channel, and confirm that the final version is 3.0.3 or later:
wp plugin update gravityforms
wp plugin get gravityforms --field=version
Keep WordPress easier to secure and maintain
Host your site on Teramont Web Hosting with a control panel, backups and the resources needed to keep WordPress and its plugins updated.
If no update appears, verify the license and obtain the package only through your official Gravity Forms account. Avoid third-party copies.
Temporary NGINX mitigation
If patching cannot happen immediately, disable the plugin or remove public multi-file upload forms temporarily. As defense in depth, deny script execution in the Gravity Forms directory:
location ~* ^/wp-content/uploads/gravity_forms/.*\.(?:php[0-9]?|phtml|phar)$ {
return 404;
}
Place this before the generic PHP handler, adapt the path, and test before reloading:
sudo nginx -t
sudo systemctl reload nginx
This reduces execution risk but does not fix the upload flaw or replace the update.
Quick compromise check
Review active-content extensions and recent files. Replace the 14-day example with the period during which your site was actually exposed:
find wp-content/uploads/gravity_forms -type f \
\( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' -o -iname '*.html' -o -iname '*.htm' \) -print
find wp-content/uploads/gravity_forms -type f -mtime -14 \
-printf '%TY-%Tm-%Td %TH:%TM %p\n'
A match requires analysis and may be legitimate. No matches do not prove that the site is clean. Correlate paths and timestamps with HTTP logs, administrator accounts, plugins, mu-plugins, scheduled tasks, and known-good backups.
If you find signs of compromise
- Isolate the site without destroying evidence; preserve logs and a system image.
- Establish the earliest possible exposure date and review requests to the form and temporary directory.
- Look for persistence in accounts, plugins, themes,
mu-plugins, cron and PHP files under uploads. - Rotate WordPress, database, SFTP/SSH, control-panel and secret keys after containment.
- Restore from a verified backup or rebuild if system integrity cannot be established.
- Patch Gravity Forms and the rest of the stack before returning the site to service.
Frequently asked questions
Does CVE-2026-19513 affect WordPress core?
No. It affects Gravity Forms 3.0.2 and earlier.
Can it be exploited without logging in?
Yes, when a vulnerable public form allows multiple-file uploads.
Is every NGINX server compromised?
No. NGINX can increase code-execution risk when uploads are passed to PHP, but the vulnerable plugin and form conditions are still required.
Does an .htaccess file remove the risk?
No. It only helps on servers that enforce it, does not patch the flaw and does not address every possible impact.
Which version is safe?
Gravity Forms 3.0.3 fixed the issue. Install that version or a newer official release.
