Two weeks after ServMask shipped version 7.110 of All-in-One WP Migration and Backup, the release that closed an unauthenticated SQL injection tracked as CVE-2026-19949, the WordPress.org version statistics show that only 35 percent of active installations are running the patched release. With the directory listing more than five million active installations, that leaves roughly 3.2 million sites running vulnerable versions. The figure arrives the same week Wordfence published its full technical write-up of the flaw, meaning the complete chain from an unauthenticated trackback to remote code execution is now public.

Key facts as of September 3, 2026

  • Patch uptake: 35.3 percent of active installations run 7.110 per WordPress.org, 6.4 percent run 7.105, and the remaining 58.3 percent run other versions.
  • Exposed population: about 3.2 million sites on the directory’s five-million floor, more if the true install count is higher.
  • Timeline: reported to Wordfence August 14, disclosed to ServMask August 15, acknowledged August 17, fixed in 7.110 on August 20, CVE record published August 25.
  • Ratings: CVSS 8.8 per the CVE record. Patchstack’s entry now lists the issue as medium priority and “expected to become exploited”, up from the low-priority reading it carried at the time of our previous report.
  • Condition: per Wordfence, the injected SQL runs only when an administrator exports and then imports the site after the payload has been planted.

Thirty-Five Percent Have Updated

The version breakdown comes from the plugin’s public statistics on WordPress.org, read on September 3. Version 7.110, the patched release, accounts for 35.3 percent of active installations. Version 7.105 holds 6.4 percent, and all other reported versions make up the remaining 58.3 percent. Since 7.110 is the latest release and every version up to 7.109 is affected, everything outside the 7.110 share is on a vulnerable version. The directory lists the plugin at more than five million active installations, so a straight calculation puts the vulnerable population at about 3.2 million sites, and the directory figure is a floor rather than an exact count. SecurityWeek, which reported the same statistic on September 3, arrived at the same estimate.

When we covered this flaw on September 2, the open question was how much of the installed base had taken an update whose changelog described it as a find-and-replace correction. The statistics answer it.

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

Two Ratings, One Revision

The public severity signals for this flaw have not agreed since the record was published, and one of them has now moved. The CVE record carries a CVSS score of 8.8, with a vector that lists low privileges and no user interaction. Patchstack’s database entry, which at the time of our previous report described the issue as having a low severity impact and being unlikely to be exploited, now lists it as medium priority: the vulnerability “is moderately dangerous and expected to become exploited”, and, it says, issues of this kind are used in mass-exploit campaigns regardless of a site’s size. The entry keeps Patchstack’s standing position that CVSS is not ideal for WordPress. The revision follows the full write-up. The lower operational priority likely reflects the chain’s central constraint: the injected SQL remains dormant until an administrator performs an export followed by an import.

How the Chain Works, Now in Public

Wordfence’s write-up, published this week, describes a second-order injection: the malicious input is stored during one action and executed during another. The attacker submits two trackbacks, both to a public post that accepts pings, each with a blog name ending in a backslash and a URL carrying the payload, and WordPress core stores both as they are. Nothing happens until an administrator exports the site and imports the archive. During the restore the plugin rewrites URLs and table prefixes inside the stored SQL, and per Wordfence the regular expression that marks string literals misreads the boundary the backslash creates, so the attacker’s text becomes executable SQL. The first planted row makes the restore pause and commit partway through; the second copies the plugin’s secret key, which guards its unauthenticated import endpoint, into an approved comment, where the attacker reads it through the public comments REST API. With the key, a crafted .wpress archive carrying a malicious must-use plugin goes through the import and runs on the next page load. Wordfence credits researcher Jack Taylor, who received a bounty of $5,761 through its program. The company stresses that the attacker is unauthenticated throughout but that the stored SQL does not execute until an administrator performs an export followed by an import, a routine action for a backup plugin and still the gate.

Attacks on the Elementor Pro Flaw Began the Day It Was Disclosed

Version Scans, Not Changelogs, Until September 15

For hosting providers the operational picture is a fleet scan for versions at or below 7.109, and the statistics suggest that scan will return hits on most sites carrying the plugin. Wordfence’s paid tiers received a firewall rule for this vulnerability on August 16, and the company says free-version sites get the same rule on September 15, thirty days later, so until then free-version sites have not received the vulnerability-specific rule. The plugin’s changelog for 7.110 still does not label the release as a security fix beyond a thank-you for responsible disclosure, which leaves version scanning, rather than changelog reading, as a reliable way to find exposed sites. The vendor’s part took five days from disclosure to release, which Wordfence calls a prompt response and timely patch. The lag that remains is on the update side.

About the Data

Version shares come from the WordPress.org plugin statistics for All-in-One WP Migration and Backup, read on September 3, 2026, and the active-installation count from the plugin’s directory page the same day; the 3.2 million estimate is ours, calculated on the directory’s five-million floor. The disclosure timeline, the technical chain, the bounty and the firewall dates come from Wordfence’s write-up. Scores and dates come from the CVE record and from Patchstack’s database entry as displayed on September 3; the earlier Patchstack wording is as quoted in our September 2 report. We have not tested the vulnerability.