· 7 min read

3.25 Million WordPress Sites Are Still Vulnerable to an Unauthenticated SQL Injection in Their Backup Plugin. A Patch Has Existed Since August 20.

CVE-2026-19949 doesn't need a stolen password. It doesn't need a phishing click, a misconfigured permission, or a plugin you forgot to update on purpose because it was working fine. It needs a trackback comment, one of the least-used features on the entire WordPress platform, and an admin who eventually clicks "restore." That's the whole attack chain for a hole in All-in-One WP Migration and Backup, a plugin with more than 5 million active installs, roughly 3.25 million of which are still running the vulnerable version.

I install this exact plugin on client sites. If you've done any WordPress work for anyone in the last several years, there's a decent chance you have too. That's what makes this one worth an actual post instead of a one-line mention in a links roundup.

What the bug actually is

CVE-2026-19949 carries a CVSS score of 8.8, and Wordfence, which disclosed it, describes it as a second-order SQL injection. The malicious payload gets submitted as completely ordinary trackback comment data on a public post, which passes the plugin's existing checks because, on its face, it looks like normal comment content. The payload doesn't do anything at submission time. It sits there. Then, when a site administrator triggers an archive restore, the stored injection runs against the plugin's restore query, insufficiently escaped, and can be used to extract the plugin's ai1wm_secret_key. From there, with a follow-on technique, that key can be leveraged toward unauthenticated remote code execution. It's a chain, not a single step, but every link in that chain requires nothing from the victim beyond eventually running a routine backup restore.

The developer, ServMask, shipped a fix in version 7.110 on August 20, patching versions up to and including 7.109. A weaponized proof-of-concept exploit is already circulating publicly. As of September 2, roughly two weeks after the patch shipped, only about 35% of the plugin's install base had actually updated, leaving an estimated 3.25 million sites still running a vulnerable version.

Why this specific plugin, on this specific attack path, matters

Trackbacks are a relic. They're a mid-2000s WordPress feature for notifying another blog that you linked to it, and almost nobody uses them intentionally anymore. Most sites have them functionally dead but technically still enabled, because disabling them isn't part of anyone's setup checklist and nothing visibly breaks by leaving them on.

That's exactly the profile of vulnerability that survives for years: a code path nobody thinks about, attached to a feature nobody uses, sitting quietly enabled by default on millions of installs. This isn't the first WordPress CVE built on an underused legacy feature, and it won't be the last, but it's a clean example of why "I don't use that feature" isn't the same as "that feature isn't active on my site."

The backup plugin angle makes it worse in a specific way. A plugin whose entire job is disaster recovery becoming a vector for disaster is the kind of irony that would be funny if it weren't still unpatched on millions of sites. And because the payload only fires when a backup runs, a site can carry the infected trackback comment silently for weeks before the actual exploit triggers, which means "I haven't noticed anything wrong" is not evidence you're safe.

What to actually do this week

Check your version. If you're running All-in-One WP Migration below 7.110, update immediately, this isn't a "get to it next sprint" patch given the public proof-of-concept. If you manage client sites, this is worth an explicit pass across every site you're responsible for rather than assuming your normal update cadence caught it, because a 35% patch rate two weeks in tells you plenty of people running this plugin are not on an aggressive update cadence.

Then go further than the patch. Disable trackbacks and pingbacks entirely if you're not using them, which you almost certainly aren't. WordPress lets you do this globally under Settings, Discussion, by unchecking "Allow link notifications from other blogs." For existing content, a plugin like Disable XML-RPC Pingback or a few lines in functions.php closes the same door for good. This single change would have prevented this entire attack class regardless of whether ServMask had shipped a fix yet, because it removes the delivery mechanism, not just this particular payload.

The honest take

This isn't really a story about one plugin having one bug. WordPress plugins get critical CVEs on a near-weekly cadence, and I could write a version of this post about a different plugin next month. The actual lesson is about trackbacks specifically: a feature that's been functionally dead for the better part of two decades, still enabled by default, still a live attack surface, on millions of sites that will never use it for its intended purpose. Patching the specific CVE fixes today's exploit. Turning off trackbacks fixes the entire category of exploit that uses this delivery method, for every plugin, forever.

Where I could be wrong: disabling trackbacks isn't free if you're one of the small number of sites actually relying on them for legitimate cross-blog notification, and there's a nonzero chance some theme or plugin you depend on has an undocumented dependency on the feature staying enabled. Test on staging before you flip it on a production site with real traffic, the same way you'd test any change that touches core WordPress behavior.

What I'd actually do

Patch first, today, no exceptions, especially if you manage sites for clients who aren't going to check this themselves. Then spend the ten minutes disabling trackbacks across every WordPress install you're responsible for. It's the rare security fix that's both nearly free and closes a door that's been open since roughly 2005.

Author

Sources

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts