Security Alert Summary
The Gravity Forms plugin for WordPress contains an arbitrary file upload vulnerability in versions up to and including 3.0.2. The issue allows unauthenticated attackers to upload attacker-controlled files to the Gravity Forms temporary upload directory under certain public form configurations, which can lead to remote code execution on servers that do not use .htaccess for execution restrictions and to stored same-origin cross-site scripting when PHP execution is blocked.
CVE Details
- CVE ID:
CVE-2026-19513 - Affected component: Gravity Forms plugin for WordPress
- Affected versions: All versions up to and including 3.0.2
- Published: September 1, 2026 at 2:17:27 PM UTC
- Last modified: September 1, 2026 at 3:17:13 PM UTC
- CVSS v3.1 base score: 8.1
- CVSS v3.1 severity: HIGH
- CVSS v3.1 vector:
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H - Authentication / privileges / user interaction: No authentication required; privileges required: None; user interaction: None (per CVSS data)
- Primary impact: Confidentiality: High; Integrity: High; Availability: High
- CWE: CWE-434 (Unrestricted Upload of File with Dangerous Type)
Technical Details
This vulnerability exists in the GFAsyncUpload::upload() function due to insufficient validation of multi-file upload chunk state. Public form state URL hashes can be reused as chunk continuation hashes, and attacker-controlled temporary filenames are accepted before sanitization. When a public form includes a File Upload field with Multiple Files enabled, an unauthenticated attacker can upload a crafted PNG/PDF polyglot file to an attacker-selected public .php or .html filename in the Gravity Forms temporary upload directory.
On web servers that do not respect .htaccess protection (for example, NGINX or other non-.htaccess-respecting configurations), a successfully written .php file could allow remote code execution. The plugin does place a .htaccess file in the temporary upload directory during installation and activation, which prevents PHP execution in those cases. Where PHP execution is blocked, attacker-written HTML files can still result in stored same-origin cross-site scripting if a victim visits the generated file URL.
How This Could Impact Your Website
Consider a site with multiple users: a site owner who manages plugins, internal staff who create public-facing forms, and external contributors who submit content. If a public form includes a multiple-file Upload field and the site is running an affected Gravity Forms version on a server that does not enforce .htaccess restrictions, an attacker could upload a file that executes code on the server. This could allow the attacker to run commands or modify site content. In environments where PHP execution is blocked, attacker-supplied HTML could be stored and later executed in a visitor’s browser, resulting in same-origin cross-site scripting.
Practical consequences include exposure of site data, increased risk of targeted phishing or social engineering using harvested information, and disruption of site integrity or availability consistent with the CVSS impacts. If you’re unsure whether your site is affected or how to assess your current user roles and plugins, it may be worth having a professional review.
Recommended Actions
- Update the affected plugin as soon as a patched version is available.
- Review and reduce unnecessary user roles, especially contributor-level accounts and other low-privilege public editors.
- Enforce strong passwords and two-factor authentication for editors and administrators.
- Remove unused or unmaintained plugins.
- Ensure your web server enforces execution restrictions for upload directories (for example, verify that
.htaccessprotections are present and effective or configure equivalent server rules on NGINX). - Monitor site activity and logs for unusual file uploads or unexpected requests to the Gravity Forms temporary upload directory.
If you’d like help reviewing your plugins, user roles, or overall WordPress security posture, our team at Freshy is happy to help.