A High-Severity Patch for Five Million WordPress Sites Was Labeled as a Text Fix

Two unauthenticated WordPress plugin vulnerabilities became public in recent days: an SQL injection in All-in-One WP Migration and Backup, installed on five million-plus sites per the WordPress.org directory, and an arbitrary file upload in Gravity Forms, a commercial form plugin. Both fixes shipped on August 20, the same day. What makes the pair worth a closer look is not the bugs themselves but how they were announced: one changelog described a high-severity fix as a text-replacement tweak, the other used a stock phrase it also uses for routine releases. Anyone deciding which client sites to update first had almost nothing to go on.

Key facts

• CVE-2026-19949: unauthenticated second-order SQL injection in All-in-One WP Migration and Backup up to 7.109, CVSS 8.8, fixed in 7.110, released August 20.
• CVE-2026-19513: unauthenticated arbitrary file upload in Gravity Forms up to 3.0.2, CVSS 8.1; the version history and the CVE record’s affected range point to 3.0.3, released August 20, as the fix.
• Disclosure lag: the CVE records went public 5 and 12 days after the patches, on August 25 and September 1.
• The changelogs: the first fix was listed as “Find and replace on values ending in a backslash”, the second as “Added security enhancements”.

An Injection That Waits for the Administrator

The All-in-One WP Migration flaw, credited to researcher Jack Taylor in a CVE record assigned by Wordfence, sits in the plugin’s archive restore functionality. Per the record, insufficient escaping lets unauthenticated attackers append additional SQL queries to existing ones and extract sensitive data. The record describes a chain that goes further: the injected queries can be used to obtain the plugin’s secret key “when a site administrator performs an archive restore”, and the key can then be leveraged into remote code execution. The qualifier matters. This is a second-order attack: the payload is planted without credentials, but the damaging step rides on an administrator’s own restore action.

The timeline favors sites that update quickly. Version 7.110 shipped August 20 and the CVE record followed on August 25. A site on prompt updates was patched before the flaw had a public name. The exposed share is whatever fraction of those five million installations has not yet taken the update, and for hosting providers that fraction is the fleet-scan question.

A High-Severity Fix, Filed Under Text Handling

Here is the release note that carried the fix, in full: “Find and replace on values ending in a backslash. Special thanks to Jack Taylor for responsibly disclosing this issue.” The name is the tell. The researcher thanked in that line is the same one credited in the CVE record for the SQL injection. Nothing else in the 7.110 changelog mentions security, and the WordPress.org directory’s release metadata carries no security classification of its own, so the changelog prose is all a reader gets.

This does not look like systematic concealment, which is what makes it instructive. Four releases earlier, the same vendor named a flaw plainly: version 7.106 lists an “unauthenticated path traversal” fix, with the same courteous thanks to its finder. The vendor evidently can label a security fix as one; it just does not do so consistently. For anyone triaging updates across a fleet, the difference between those two changelog entries is the difference between patching within hours and patching whenever the queue gets there.

One Flaw, Three Numbers That Disagree

How urgent was it? The public signals answer differently because they measure different things, and the CVE record carries a tension of its own.

• CVSS 8.8 out of 10, per the CVE record: the published technical assessment, under which a successful chain yields full compromise of the site. The record’s own scoring vector lists low privileges and no user interaction, while its description calls the attacker unauthenticated and ties the secret-key step to an administrator’s restore.
• Low priority, per Patchstack’s entry, which states the issue “has a low severity impact and is unlikely to be exploited” and adds, as the database does generally, that CVSS is a standardized ranking that is “not ideal for WordPress”: this weighs how exploitable the issue is in practice. The entry does not give its reasoning; the chain’s dependence on an administrator running a restore is the obvious candidate.
• Five million installations, per the WordPress.org directory: this sizes the population running the plugin, not the risk to any one site.

A host that reads only one of the three will either over-alarm clients or under-patch them.

Gravity Forms and the Channel With No Metadata at All

The Gravity Forms flaw, credited in its CVE record to Alex Thomas and to Wordfence Argus, is an arbitrary file upload in the plugin’s multi-file upload handling. Per the record, an unauthenticated attacker can abuse chunked-upload state on any public form that has a File Upload field with Multiple Files enabled, landing a valid PNG or PDF polyglot, a file built to pass image or document checks while carrying other content, under an attacker-chosen .php or .html filename in the plugin’s temporary upload directory. What happens next depends on the server underneath: the record notes the plugin places an .htaccess file in that directory during installation and activation, which blocks PHP execution on servers that respect it; there the residual risk is stored cross-site scripting against visitors who open the uploaded file’s address. On NGINX and other servers that do not read .htaccess, the same upload can lead to remote code execution. Which outcome a site faces depends largely on the web server and its configuration, and in managed hosting those controls usually sit with the provider, not the site owner.

The disclosure channel is the second half of the story. Gravity Forms is commercial, distributed outside the WordPress.org repository, with updates delivered through the vendor’s own channel. Its changelog entry for 3.0.3, the release the version history and the CVE record’s affected range point to as the fix, reads “Added security enhancements” and nothing more, the same phrase the changelog attaches to the 3.0.0 major release. There is no public install count, no repository metadata, and no severity wording to parse. By our count of Patchstack’s public listing, this is also the fourth unauthenticated arbitrary file upload recorded for the plugin since November 2025, a pattern worth knowing for anyone deciding how much slack to give that upload path.

What a Fleet Can Rely On

The pair of disclosures makes an operational point that has nothing to do with either vendor’s code quality. Changelogs, it turns out, are not a severity feed: one of these fixes was described as text handling, the other with a phrase that also decorates feature releases. The reliable signals arrived days later, in the CVE records and vulnerability database entries; the records trailed the patches by 5 and 12 days. That gap is an argument for defaulting managed fleets to staged automatic updates or same-day, tested rollouts, because in both cases the boring policy beat the informed one: there was nothing to be informed by on patch day. Where updates cannot be automatic, the practical fallback is subscribing to vulnerability database feeds rather than release notes, and treating any update that thanks a researcher by name as a security patch until proven otherwise.

About the Data

Both CVE records, assigned by Wordfence and credited to the researchers named above, were read in full at the CVE Program. Plugin versions, release dates, install count and changelog wording for All-in-One WP Migration and Backup come from the WordPress.org plugin directory and its public data; Gravity Forms release dates and changelog wording come from the vendor’s official change log. The Patchstack database entries for both plugins were read directly, including the priority assessment quoted here. The count of prior file upload flaws is ours, from Patchstack’s public listing. We did not attempt to reproduce either vulnerability, and we have seen no data on in-the-wild exploitation.