Wordfence disclosed an unauthenticated arbitrary file upload flaw in Gravity Forms, tracked as CVE-2026-19513 and rated CVSS 8.1, affecting versions up to and including 3.0.2 and fixed in 3.0.3 on August 20, 2026. The plugin has an estimated million-plus active installations, and the headline everywhere is that this Gravity Forms vulnerability can lead to remote code execution. That is accurate and it is incomplete, because whether it reaches code execution on any given site turns on a detail that most summaries leave out entirely: which web server you run. This piece covers what the flaw actually is, the two preconditions that scope it, why the server matters more than the severity score, the disclosure timeline and what it implies for free Wordfence users, and what to do now.
What the flaw actually is
The mechanism is more interesting than "file upload bug," and it is a good example of a class of defect worth recognizing.
Gravity Forms uses WordPress’s wp_hash() for two unrelated jobs: authenticating public form state, and validating chunked upload continuation requests. Those are different trust domains being protected by the same primitive with no separation between them.
An attacker can craft a URL whose chunk field values they control such that the resulting public form-state hash is simultaneously a valid chunk-continuation hash. Having crossed that boundary, they can manipulate the temporary filename during a multi-file upload, and write a file with an extension of their choosing to a public temporary upload directory.
This is domain confusion rather than a broken hash. wp_hash() did its job. It was asked to guard two different doors with one key, and a key that opens both doors is not a key that distinguishes between them. Any codebase using one hashing helper for several security purposes without binding each use to its own context has the same shape of problem waiting in it.
Two preconditions do a lot of scoping
Neither the vendor advisory nor the summaries circulating make the exposure conditions prominent, and they change how many sites are actually at risk.
First, the site needs a public form that contains a File Upload field with Multiple Files enabled. Not merely Gravity Forms installed, and not merely a form with an upload field. The chunked upload path is what the attack abuses, and multi-file upload is what activates it. A site running Gravity Forms for contact and newsletter forms with no file uploads is not exposed by this.
Second, and this is the one that decides outcomes, the uploaded file has to actually execute.
Why the web server decides the severity
Gravity Forms writes an .htaccess file into its upload root containing directives that disable PHP parsing. On a typical Apache configuration that honors .htaccess, an attacker who successfully writes a .php file into that directory gets a file that does not execute. The upload succeeds, the code does not run.
NGINX does not process .htaccess files at all. That protection is simply absent, and a written .php file is served by whatever PHP handler the stack has configured.
So the same vulnerability, the same plugin version, the same successful upload, produces materially different outcomes depending on the server underneath. On Apache with .htaccess enforced, the realistic worst case is stored cross-site scripting through an uploaded HTML file, which is serious and is not remote code execution. On a stack that ignores .htaccess, code execution is genuinely on the table.
That distinction matters practically because a large share of managed WordPress hosting runs NGINX or NGINX in front of PHP-FPM, and the site owner frequently has no idea which, because they never configured it. If you are not certain what your host runs, that is the single thing to go and find out, and it is worth knowing permanently rather than just today, because this will not be the last flaw whose blast radius depends on it.
The CVSS 8.1 is a single number describing a range of real-world outcomes. Treat it as a reason to patch promptly, not as a description of what would happen to you specifically.
The disclosure timeline, and the gap in it
The sequence Wordfence published is worth laying out, because one date in it is a business-model fact rather than a security fact.
Wordfence Argus, the team’s automated research tooling, found the flaw on August 9, 2026. Wordfence disclosed to the vendor on August 11. Paying Wordfence customers received a firewall rule on August 13. Gravity Forms acknowledged and shipped 3.0.3 on August 20, the same day. Free Wordfence users receive the same firewall rule on September 12, thirty days after the paying tier.
The vendor response deserves the credit it is getting: nine days from private disclosure to a shipped patch is fast, and acknowledging and patching on the same day is faster than most.
The thirty-day delay for free users is a normal commercial arrangement and it is worth understanding rather than being outraged about. It also matters less than it first appears, because the patch landed on August 20, three weeks before free users get the rule. Anyone who updated is not relying on a firewall rule at all. The people in the gap are those running an unpatched install and treating a free security plugin as their control. That combination is the actual exposure, and it is a reason to fix the version rather than to wait for a rule.
The Gravity Forms vulnerability is not the first of its shape
Form plugins that accept file uploads are a recurring source of this exact class of finding, and it is worth seeing the pattern rather than treating each advisory as an isolated event.
Wordfence has published arbitrary file upload advisories this year for Ninja Forms, in an April 2026 disclosure it described as affecting around 50,000 sites, and for Super Forms. Three different vendors, three different codebases, the same category of defect: unauthenticated input reaching a file write with attacker influence over the destination.
The reason is structural rather than a comment on any of these teams. A form plugin that accepts uploads has to take a file from an anonymous visitor, decide what it is, decide where to put it, and give it a name, and every one of those decisions is a place to get it wrong. Chunked and multi-file upload paths add resumability on top, which means state carried between requests, which means something has to authenticate that state. That is exactly where this flaw lives.
It is also a reminder of where WordPress risk actually concentrates. Core has hardened considerably, and the release we covered in what shipped in WordPress 7.1 continued that. The plugin surface is a different population entirely, with different review, different release cadence and different incentives, and it is where the interesting findings keep coming from.
What to do now
Update to Gravity Forms 3.0.3 or later. This is the entire fix and everything else on this list is for sites that cannot update immediately or want to know what happened.
Check whether you were ever exposed. Look for public forms with a File Upload field that has Multiple Files enabled. If you have none, your exposure to this specific flaw was zero regardless of version.
Find out what your web server is. Apache honoring .htaccess, or NGINX. Your host’s documentation or a support ticket will answer it in minutes, and the answer changes how urgently you should treat this class of finding forever after.
Look in the upload directory. Unexpected .php or .html files in the Gravity Forms temporary upload path are the artifact to search for. Our guidance in wp2shell on checking whether a WordPress site was compromised applies here with no changes, because the post-exploitation questions are identical whatever the entry point was.
If you find something, restore rather than clean. A site with an unexplained executable file in a public directory is a site you no longer know the state of, and WordPress backup security covers what a restorable backup needs to look like for that to be an option.
The part worth generalizing
Two lessons here outlast this CVE.
The first is about defensive layering that works by accident. Gravity Forms writes that .htaccess file as belt-and-braces hardening, not because anyone anticipated this specific flaw. It is the reason a serious bug is less serious on many installations. Defense in depth is often criticized as vague, and this is what it looks like when it pays: an unrelated precaution taken years earlier absorbing an attack nobody predicted.
The second is that the precaution silently stops working when the platform changes underneath it. Nobody edited that .htaccess file. Moving from Apache to NGINX removes it from the equation entirely, and nothing warns you. Any security control expressed in a file that only one server reads has this property, which is a good argument for knowing which of your protections are configuration and which are conventions your stack happens to honor. The package registry attack surface piece made a related point about assumptions that hold until the surrounding system changes.
Frequently Asked Questions
What is the Gravity Forms vulnerability?
CVE-2026-19513, an unauthenticated arbitrary file upload rated CVSS 8.1, affecting Gravity Forms up to and including version 3.0.2. It lets an unauthenticated attacker write a file with an attacker-chosen extension to a public temporary upload directory. It was discovered by Wordfence Argus on August 9, 2026 and patched in 3.0.3 on August 20.
How does the attack work?
Gravity Forms uses the same `wp_hash()` function to authenticate public form state and to validate chunked upload continuation requests. An attacker can craft a URL whose chunk field values make the public form-state hash also valid as a chunk-continuation hash, crossing between the two trust domains and allowing manipulation of the temporary filename during a multi-file upload.
Am I affected if I use Gravity Forms?
Only if a public form on your site contains a File Upload field with Multiple Files enabled, and you are running 3.0.2 or earlier. The chunked upload path is what the attack abuses, so sites using Gravity Forms without multi-file upload fields were not exposed to this particular flaw.
Does this really cause remote code execution?
It depends on your web server, which is the detail most summaries omit. Gravity Forms writes an `.htaccess` file in its upload root that disables PHP parsing, so on Apache configurations that honor `.htaccess`, an uploaded `.php` file does not execute and the realistic worst case is stored cross-site scripting via an HTML file. NGINX does not read `.htaccess` at all, so that protection is absent there.
What version fixes it?
Gravity Forms 3.0.3, released August 20, 2026, or any later version. Updating is the complete fix. Firewall rules are mitigation for sites that have not updated, not a substitute for updating.
Why do free Wordfence users wait until September 12?
Thirty-day delayed rule delivery for the free tier is Wordfence’s standard commercial arrangement, with paying customers receiving rules first, in this case on August 13. Because the vendor patch shipped on August 20, anyone who has updated does not depend on the rule at all. The gap only affects sites still running a vulnerable version.
How do I check whether I was compromised?
Look for unexpected `.php` or `.html` files in the Gravity Forms temporary upload directory, then review the site for the usual post-exploitation signs: unfamiliar admin users, modified core files, unexpected scheduled tasks and outbound requests. If you find anything you cannot explain, restore from a known-good backup rather than deleting the file and moving on.
How many sites are actually at risk?
Unknown, and the frequently quoted million-plus installation figure is an estimate rather than a count, since Gravity Forms is a commercial plugin distributed outside the WordPress.org repository. The at-risk population is narrower than the install base in any case, because it requires both a vulnerable version and a public multi-file upload form.
