WordPress Backup Plugin Bug Leaves 3.25 Million Sites Open to Takeover, Only 35 Percent Patched

The bug

A high-severity SQL injection vulnerability in All-in-One WP Migration and Backup, a plugin running on more than 5 million WordPress sites according to WordPress.org's own directory stats, can hand an unauthenticated attacker full remote code execution on a target site. The flaw is tracked as CVE-2026-19949.

Security researcher Jack Taylor found it and reported it in mid-August through Wordfence, the threat research arm of Defiant, according to BleepingComputer. Wordfence validated the finding and disclosed it to the plugin's developer, ServMask, on August 15.

How the attack actually works

This isn't a garden-variety injection you catch with a firewall rule. Wordfence describes it as a second-order, or stored, SQL injection. An attacker with zero credentials plants malicious data on a site through WordPress trackbacks, a normal comment-adjacent feature. That payload sits dormant.

It only fires when a site administrator does something completely routine for this plugin: exports or restores a backup archive. At that point, according to Wordfence, incorrect parsing of escaped backslashes and quotation marks lets the planted SQL execute, exposing the plugin's secret import key, ai1wm_secret_key, through what looks like an ordinary public comment. Once an attacker has that key, they can import a malicious .wpress archive containing executable code and take the site over completely.

Tech Times, citing Wordfence's own scoring, put the CVSS severity rating at 8.8 out of 10. Wordfence's language, quoted by BleepingComputer, is blunt about why this matters: "Since backup and restore is the core purpose of this plugin, this is a routine action, but the injected SQL will not execute until it takes place."

Why your firewall won't save you

A standard web application firewall inspects incoming HTTP traffic for injection signatures in real time. That's useless here because the dangerous step isn't the initial request. It's what happens later when the plugin itself processes previously-stored data during a restore. Tech Times flagged this as the single most important operational fact in the whole advisory, and the underlying Wordfence disclosure backs that reading.

One claim worth flagging on its own: Tech Times reported that "a weaponized proof-of-concept exploit" is "circulating in threat-intelligence datasets." That specific detail doesn't appear in Wordfence's disclosure as relayed by BleepingComputer, SecurityWeek, or the other outlets covering this. Treat it as an unconfirmed claim from a single outlet, not as an established fact repeated across the field.

The patch timeline, and a labeling problem

ServMask shipped the fix in version 7.110 on August 20, five days after Wordfence's private disclosure. The public CVE record followed on August 25. Wordfence's full technical writeup went out September 2, and that's when the story became public and 65% of the plugin's install base, roughly 3.25 million sites, was still running a vulnerable version, per Wordfence's own adoption figures.

A separate angle from webhosting.today matters for anyone actually responsible for patching a WordPress fleet. The 7.110 changelog entry that fixed this flaw reads, in full: "Find and replace on values ending in a backslash. Special thanks to Jack Taylor for responsibly disclosing this issue." Nothing in that line flags it as a security fix. Four versions earlier, ServMask labeled a different fix plainly as an "unauthenticated path traversal" vulnerability, crediting the same researcher category of disclosure. So the vendor clearly knows how to communicate severity when it wants to. It just didn't here, on a bug rated 8.8 and capable of full site takeover.

That inconsistency isn't evidence of a coverup. It is evidence that an agency or freelancer triaging which client sites to patch first, working only off ServMask's own release notes, would have had almost no signal that this update mattered more than a routine tweak.

What site owners should actually do

If you're running any version of All-in-One WP Migration and Backup through 7.109, the fix is simple: update to 7.110 or later immediately. No firewall configuration substitutes for that. Given that the exploit chain requires no credentials and rides on an action, exporting or restoring a backup, that plugin exists specifically to encourage, waiting on a vendor changelog to spell out urgency isn't a strategy. It's the same discipline that applies to any small business running its own systems: nobody else is going to patch your server for you, and the plugin maker's silence on severity is not a signal that the risk is low.

The unresolved question is how many of the 3.25 million still-vulnerable sites will get patched before, rather than after, someone runs the exploit for real. Wordfence has not published data on active exploitation in the wild as of its September 2 advisory.