Gravity Forms vulnerability puts hidden upload fields at risk

Gravity Forms vulnerability at a glance

The issue is tracked as CVE-2026-84434. Wordfence, which assigned the CVE, gives it a CVSS score of 9.8 out of 10. That Critical rating reflects a difficult combination for site owners: an attacker does not need a WordPress account, does not need an administrator to click anything, and may be able to place executable code on the server.

Why a hidden upload field became dangerous

A File Upload field normally checks what a visitor is trying to send before Gravity Forms keeps it. If the file type is not allowed, the submission should stop there. The official CVE record describes a gap between that validation step and the part of the plugin that finally saves the upload.

When the upload field's Visibility setting is Hidden, a rejected file can keep enough of its upload state to reach the saving process without being checked again. A visitor can therefore submit a file that the form was supposed to refuse. If the server will execute that file as code, the attacker may be able to take control of the website.

Hidden does not mean the field has disappeared from the form configuration. It means the field is not shown to an ordinary visitor. The server still receives the form submission, which is why hiding a field is never a replacement for checking what reaches the server.

Which Gravity Forms sites are exposed?

The plugin version matters, but it is not the whole picture. The disclosed route needs an affected version and a form that an unauthenticated visitor can reach. That form must also contain a File Upload field whose Visibility setting is Hidden.

A private form limited to logged-in users does not offer the same unauthenticated route. Nor does a form that has no hidden upload field. Even so, checking every old landing page before deciding not to update is the wrong trade-off. A forgotten form, shortcode, or embedded page is easy to miss, while installing the fixed version removes the known weakness from the plugin.

There is another reason not to wait. Patchstack marks the vulnerability as known to be exploited. That does not mean every exposed site has been attacked, but it does turn the update from routine housekeeping into work that should be handled now.

Update to Gravity Forms 3.1.1 or later

Gravity Forms 3.1.1 is the first patched release. The vendor's official changelog lists security enhancements in 3.1.1, followed by another security-enhancement release, 3.1.2, on 17th September. At the time this article was published, 3.1.2 was the current version, so there is little reason to stop at the minimum fixed release.

Open Plugins > Installed Plugins, find Gravity Forms, and note the version before making a change. Take a current backup, install the latest update available through your Gravity Forms licence, and check the version again when WordPress says the update has finished. Then submit a test entry through each important form, especially forms that accept files or feed a payment, CRM, email, or automation service.

Gravity Forms describes version 3 as a major release and recommends sandbox testing when moving from version 2. If a site is still on the older branch, use a staging copy to catch compatibility problems, but do not let that turn into an open-ended delay. Ask the plugin vendor, your host, or a WordPress developer to help plan the move.

What to do if you cannot update immediately

The update is the proper fix. If it genuinely cannot happen today, reduce the exposed surface while somebody resolves the blocker. Take public forms containing hidden File Upload fields offline, or remove those fields from the published form. Restricting the whole page to authenticated users can also close the unauthenticated route described in the advisory.

A web application firewall may block a known malicious request, and Patchstack says it has issued a mitigation rule. Treat that as a temporary layer rather than evidence that the vulnerable code can remain. Rules differ between providers, plans, and configurations, while an installed update is much simpler to verify.

Updating closes the flaw, but it does not rewind the site

Once the update is installed, new attempts through this route should fail. What the update cannot do is remove a file that arrived beforehand. That distinction matters because the vulnerability may lead to remote code execution, giving an attacker room to add a backdoor somewhere else and return later.

The Gravity Forms file-upload documentation explains that uploads normally sit beneath a dedicated wp-content/uploads/gravity_forms/ area. It also describes an Apache configuration file intended to stop PHP running there. That is useful defence in depth, but server setups vary, upload paths can be changed, and the CVE still carries a Critical rating. It should not be used as a reason to skip the update or review.

If an affected version and the required form setup were public, the review should include:

• unexpected executable files in Gravity Forms upload storage
• recently added or changed PHP files elsewhere under wp-content
• administrator accounts, plugins, themes, and must-use plugins nobody recognises
• server access logs around unusual form submissions and direct requests to uploaded files
• scheduled tasks, WordPress configuration, and credentials if compromise is confirmed

Do not delete the first unfamiliar file and assume the job is finished. Preserve enough evidence to understand when it appeared and what it did, then check the wider site. If you are not comfortable doing that yourself, ask your host or a security specialist to review it before logs rotate and useful evidence disappears.

A sensible response without the panic

CVE-2026-84434 deserves a prompt response, but a vulnerable version is not proof of a hacked website. Start with what you can establish: the installed version, whether a public form had a hidden upload field, and how long that combination was online. Update first, test the forms, and use that exposure to decide how urgently the site needs a deeper review.

BugShield can handle the update and form checks through our managed WordPress plugin updates. If the affected configuration was public, or the site already contains files and users you do not recognise, our WordPress malware removal service can investigate the files, database, users, and likely route into the site.

For a one-off job, request a WordPress fix. The important part is not whether you use BugShield or handle it with your existing developer. It is making sure Gravity Forms is genuinely beyond 3.1.0.4 and that an exposed site is not declared clean simply because the update button has been pressed.