BugShield scanned 100,000 WordPress sites for the Gravity Forms vulnerability

Why we ran a targeted scan

BugShield AI continuously scans the web for WordPress vulnerabilities. When it finds a site that appears to be running vulnerable software, BugShield Bot automatically warns the owner so there is a chance to fix the problem before somebody abuses it.

The process became especially relevant when CVE-2026-84434 was disclosed in Gravity Forms. The flaw can allow an unauthenticated visitor to upload a dangerous file when an affected site has a public form containing a File Upload field whose visibility is set to Hidden. In the wrong server setup, that file could be executed as code.

We had already published a full explanation of how the Gravity Forms vulnerability works. The next question was broader: now that a fixed release existed, how many WordPress sites still appeared to be running a vulnerable version? We ran a dedicated scan across a list of 100,000 WordPress URLs to find out.

4,697 sites matched the affected version range

The scan identified 4,697 sites running a Gravity Forms version up to and including 3.1.0.4. Put another way, 4.697% of the 100,000 URLs we checked matched the vulnerable version range. Rounded for a simpler comparison, that is about 4.7%, or roughly one in every 21 sites in the scanned list.

The denominator matters. We are not saying that 4.7% of all Gravity Forms installations are vulnerable, or that this is a global market-share estimate. It is the result from the specific list of 100,000 WordPress URLs we scanned. Even with that boundary, 4,697 sites is a substantial number of owners left with a known weakness in production.

What the number does and does not prove

A vulnerable plugin version is not the same as a confirmed vulnerable form, and neither is proof of a hacked website. The disclosed attack route also needs a public form with a File Upload field set to Hidden. The server must then be willing to execute the file for the attack to progress to code execution.

Our 4,697 result establishes the part we could identify across the list: those sites appeared to be running Gravity Forms within the affected version range. It does not tell us that each one had the required form configuration, that somebody tried the attack, or that an upload succeeded.

That distinction prevents a useful warning from becoming a frightening but unsupported claim. It should not become an excuse to leave the old plugin installed. Site owners can forget about a form on an old landing page, a draft campaign, or a page built by a previous agency. Updating removes the known weakness without relying on a perfect inventory of every form that has ever been published.

The number of Gravity Forms 2.x sites stood out

A lot of the affected sites were not just one small security release behind. They were still on version 2.x, while Gravity Forms has moved to the 3.x line. Those installations need the same urgent security response, but their owners may face more update work than somebody moving from 3.1.0.4 to a patched 3.1 release.

The official Gravity Forms changelog describes the move from 2.x to 3.x as a major upgrade that may include breaking changes, and recommends testing it in a sandbox. That is sensible advice. A busy site may have custom form code, payment feeds, CRM connections, or styling that needs to be checked before the update reaches live.

Compatibility work explains why an update can be delayed. It does not make the vulnerable version safer. Take a current backup, copy the site to staging, test the newest release there, and set a short deadline for the live upgrade. If a problem appears, fix that problem instead of allowing the old branch to remain indefinitely.

Finding the issue is only half the job

A scan result has little value if it sits in a dashboard nobody checks. BugShield Bot turns the finding into a warning for the site owner. The message can explain which vulnerable software was detected, why it matters, and what the owner can do next.

Careful wording matters here too. The useful message is not that a website has definitely been hacked. It is that the site appears to be running an affected Gravity Forms version and needs an update. If the required form setup was public during that vulnerable period, the owner can then make an informed decision about reviewing the files and logs.

That is the reason we keep the monitoring continuous. New vulnerabilities appear, sites drift out of date, and a clean result from last month cannot describe the software running today. Repeated checks shorten the gap between a problem becoming visible and the person responsible for the site hearing about it.

What Gravity Forms site owners should do now

Start by opening Plugins > Installed Plugins in WordPress and checking the installed Gravity Forms version. Any release up to and including 3.1.0.4 falls inside the affected range. Gravity Forms 3.1.1 contains the first fix, although installing the latest stable release available through the licence is the better target.

Then work through the parts that turn an update into a proper response:

• take a current backup before changing the plugin
• test the upgrade on staging first if the site is moving from Gravity Forms 2.x
• submit every important form after the update, including payments, uploads, notifications, and integrations
• check whether any public form used a hidden File Upload field while the affected version was installed
• review files and server logs if the known vulnerable configuration was publicly reachable

Updating closes the disclosed route, but it cannot remove a malicious file that may have arrived earlier. Where the vulnerable form configuration existed, check Gravity Forms upload storage, the wider wp-content directory, administrator accounts, must-use plugins, scheduled tasks, and requests made during the exposed period.

The patch gap is the bigger lesson

A security fix can be available and still leave thousands of websites behind. Some owners never see the update notice. Some licences have expired. Others are worried about breaking an old integration, or assume that a quiet site is not interesting to an attacker. The result is the same: vulnerable code stays online after the problem and its fix are public.

The 2.x installations make that gap particularly visible. Updating them may need more care, but postponing the work simply transfers the risk from a planned staging test to an unplanned security incident. Monitoring works best when it identifies that drift early and gives the owner a practical route back to a supported release.

A useful scan should end with a safer website

The headline figure from this scan is 4,697, but the goal is not to collect a larger number next time. It is to help those site owners close the gap. That means detecting the issue, communicating it without exaggeration, and making the update achievable even when an old site needs careful testing.

BugShield maintenance plans include ongoing vulnerability monitoring and managed WordPress plugin updates. If a vulnerable form was public, or the site contains files and users nobody recognises, our WordPress malware removal service can investigate the files, database, accounts, scheduled tasks, and likely entry point.

For a single update or investigation, request a one-off WordPress fix. Whether BugShield handles it or an existing developer does, check the installed version today. A known vulnerability becomes far less useful to an attacker once the affected software is no longer there.