Wordfence says its Argus research system uncovered a high-severity unauthenticated arbitrary file upload flaw in the popular Gravity Forms WordPress plugin, affecting versions 3.0.2 and earlier and potentially allowing remote code execution on some server setups. The company disclosed the issue to the vendor, which released Gravity Forms 3.0.3 with a fix on August 20, 2026.
What Wordfence found in Gravity Forms
The vulnerability sits in Gravity Forms’ chunked, multi-file upload flow. According to Wordfence, an attacker with no login could abuse weak validation in the upload continuation process to write a file with an attacker-chosen extension into the plugin’s public temporary upload directory.
Wordfence assigned the issue CVE-2026-19513 and rated it 8.1, or High. The flaw affects Gravity Forms through version 3.0.2 and is tied to a “state/chunk hash confusion” problem in the plugin’s handling of upload session data.
Why the bug is serious
The core issue is that the plugin used the same hashing approach for two different purposes: one for public form state and another for upload chunk continuation. Wordfence said that because the public page URL can be influenced by an attacker, the resulting hash could be reused to satisfy the upload continuation check without breaking the underlying secret.
That mistake was compounded by how the plugin handled temporary filenames. In the vulnerable version, the upload handler validated the hash against a raw filename supplied by the attacker, then sanitized it afterward. That left room for a temporary file name to be steered toward a dangerous extension such as .php or .html.
How exploitation could play out
- A public form must contain a File Upload field with Multiple Files enabled.
- The attacker can use normal allowed content such as PNG or PDF, which Gravity Forms permits by default.
- A valid PNG/PDF polyglot file can pass content checks while also carrying embedded PHP code.
- If the target server executes PHP in the temporary upload directory, the result can be remote code execution.
- On servers where PHP execution is blocked but HTML is reachable, the impact can instead become stored same-origin cross-site scripting.
What made the weakness possible
Wordfence’s technical write-up says the plugin accepted continuation requests for chunked uploads without enough separation between the data used to authenticate a session and the data used to name the destination file. Because the same general hashing function was reused in both places, a legitimate public form hash could be mistaken for valid upload state.
The report also notes that the first chunk was not required to come from a server-created session. For later chunks, the handler would append to a selected .part file, and if the upload was considered complete, it would remove the suffix and leave the final file in place.
Disclosure, patching, and timeline
Wordfence said it discovered the issue on August 9, 2026, through Wordfence Argus, and sent full disclosure to the Gravity Forms team via its Vulnerability Management Portal on August 11. The vendor acknowledged the report on August 20 and released Gravity Forms 3.0.3 the same day.
Wordfence Premium, Wordfence Care, and Wordfence Response customers received firewall protection on August 13, 2026. Free users are scheduled to receive the same rule 30 days later, on September 12, 2026.
Key dates
- 2026-08-09: Wordfence Argus discovered the vulnerability.
- 2026-08-11: Wordfence disclosed the issue to the vendor.
- 2026-08-13: Firewall protection reached Premium, Care, and Response users.
- 2026-08-20: Gravity Forms 3.0.3 was released.
- 2026-09-12: Free Wordfence users are set to receive the rule.
What changed in Gravity Forms 3.0.3
Wordfence says the patched version changes the upload flow in several important ways. Temporary upload names are now server-generated, chunk continuation uses a structured token instead of the ambiguous older hash, and the plugin checks that a continuation request matches an upload session that actually exists.
The update also rejects non-canonical temporary filenames and filenames with disallowed extensions. In short, the new code removes attacker control over the destination basename and separates public form state from upload-authentication data.
Why the patch matters for site owners
Even though Gravity Forms creates an .htaccess file to block PHP execution in its upload directory on typical Apache setups, Wordfence notes that this protection does not apply everywhere. Servers running NGINX or other configurations that do not respect .htaccess remain at greater risk if the vulnerable version is installed.
That is why the advice is straightforward: update to Gravity Forms 3.0.3 or newer as soon as possible, even if the site appears to be protected by server-side upload restrictions.
What WordPress admins should do now
- Check whether Gravity Forms is installed and confirm the version.
- Upgrade to Gravity Forms 3.0.3 or later immediately.
- Review whether any public forms use multi-file upload fields.
- Make sure Wordfence firewall updates are enabled on the site.
- Monitor upload directories and logs for unusual activity.
The incident is another reminder that security bugs can emerge not just from missing authentication, but from subtle confusion between two code paths that were never meant to trust the same token. In this case, Wordfence says Argus found the flaw before it was widely exploited, and the vendor responded with a same-day patch once it acknowledged the report.
Source: Original report
Was this helpful?
Explore more: WordPress Troubleshooting More WordPress & CMS Tech News
Last Modified: September 5, 2026 at 1:53 am
4 views
