All-in-One WP Migration RCE Flaw Hits 3M Sites (Patch)

One of the most widely installed WordPress plugins has a flaw that can hand an attacker full control of a site. A vulnerability tracked as CVE-2026-19949 in All-in-One WP Migration and Backup — a plugin used to move, copy, and back up WordPress sites — exposes more than 3 million installations to remote code execution, according to researchers who disclosed the issue. The bug is an unauthenticated SQL injection that, through a multi-step chain, can be escalated into a complete site takeover. A fixed version, 7.110, is available, and administrators are urged to update immediately.

The plugin’s ubiquity is what makes this dangerous. Migration and backup tooling is exactly the kind of software that gets installed once and left running, often on sites whose owners have long since stopped paying attention to plugin updates. A vulnerability that requires no authentication and reaches a plugin this common is a broad, attractive target.

What the flaw is

CVE-2026-19949 is a second-order SQL injection in the plugin’s archive restore functionality. It affects all versions up to and including 7.109. The root cause is familiar: user-supplied input is insufficiently escaped, and the underlying SQL query is not properly prepared, so attacker-controlled data ends up interpreted as part of the query rather than treated as inert text.

What makes this variant more interesting than a garden-variety injection is the word second-order. In a classic first-order SQL injection, the malicious input is used the moment it arrives. In a second-order attack, the payload is stored first and detonated later, when the application reads that stored data back in a sensitive context. That indirection is what makes second-order bugs easy to miss in code review — the dangerous input and the dangerous query live in completely different parts of the codebase.

How the attack chain works

The exploit unfolds in stages, and the mechanics are worth understanding because they explain why an “unauthenticated” bug in a backup plugin can end in remote code execution.

Step one: plant the payload. An attacker submits a specially crafted trackback to a public post. Trackbacks are a legacy WordPress commenting mechanism — a way for one blog to notify another that it has linked to it — and crucially, they can be sent by anyone, with no login required. That is the source of the “unauthenticated” classification: the attacker never needs credentials, only the ability to hit a public endpoint that WordPress exposes by default. The malicious data lands in the database and sits there, harmlessly, doing nothing.

Step two: wait for a restore. The payload stays dormant until a site administrator uses the plugin to export and then import (restore) the site. During that archive-restore operation, the plugin reads the stored data back and processes it through the vulnerable, unprepared query. This is the “second-order” trigger: the injection fires not when the attacker acts, but when a legitimate admin performs a routine backup-and-restore.

Step three: escalate to code execution. Through the injection, an attacker can extract the secret key used during the archive-restore process. Armed with that key, the attacker can then deploy a malicious plugin — and a plugin is just executable PHP. Installing one is equivalent to running arbitrary code on the server. From there, the outcome is the standard endgame of any RCE: webshells, persistence, data theft, and full server compromise.

The chain is a clean illustration of how a “bounded” database bug becomes total compromise. On its own, reading a value out of a query is a data problem. But when that value is the secret that authorizes plugin installation, the data problem becomes a code-execution problem.

Who is affected

Any WordPress site running All-in-One WP Migration and Backup at version 7.109 or earlier is exposed. The plugin is one of the most popular migration tools in the WordPress ecosystem, with the flaw reaching more than 3 million active installations by the researchers’ count; some reporting puts the exposed population higher still. Either way, the affected base is measured in the millions.

There is one mitigating wrinkle worth being precise about: the injection detonates during an admin-initiated restore, not on the attacker’s schedule. That means exploitation depends on a site owner performing an import while a planted payload is present. But planting the payload is trivial and unauthenticated, the data persists indefinitely, and backup-and-restore is exactly what this plugin exists to do. On a site that migrates, restores from backup, or is cloned to staging, the trigger is a matter of when, not if. Treating the requirement as meaningful protection would be a mistake.

What to do now

The remediation is straightforward, and there is no reason to delay:

• Update to version 7.110 or later immediately. This is the version that fixes CVE-2026-19949, and updating is the only complete fix.
• If you cannot patch right away, deactivate the plugin until you can. A dormant migration plugin is a smaller attack surface than a vulnerable active one.
• Consider disabling trackbacks and pingbacks on public posts. They are a legacy feature that many sites do not need, and they are the delivery vehicle for the payload in this chain.
• Audit for signs of compromise on any site that has run a restore recently — in particular, unexpected or unfamiliar plugins, since malicious-plugin installation is the RCE step. Unknown administrative users and unexplained files are the other classic indicators.

Because the payload is stored and the trigger is delayed, patching alone closes future exploitation but does not undo a compromise that may already have occurred. Sites that perform frequent imports or run automated restore pipelines should treat an audit as part of the response, not an optional extra.

The broader pattern

This is the second high-profile WordPress remote-code-execution story of the season, after the wp2shell chain in core forced an emergency release earlier in the summer. The two share a shape: a SQL injection that is serious but bounded on its own, chained with a second weakness that supplies the leverage to reach code execution. In wp2shell it was a REST batch route; here it is the secret key that authorizes plugin installation.

The recurring lesson is that plugins are the WordPress attack surface. Core has hardened considerably over the years, but the ecosystem’s strength — a vast library of third-party plugins for every conceivable task — is also its structural weakness. A single popular plugin with a subtle bug can expose millions of sites at once, and migration and backup tools are especially sensitive because they operate on the entire site, hold secrets, and run with high privilege by design.

What it means

CVE-2026-19949 is a reminder that the most dangerous vulnerabilities are often not the flashiest. There is no zero-day novelty here — just an unprepared SQL query, a legacy trackback feature, and a secret key that turns data access into code execution. The danger comes from scale and ubiquity: a common plugin, millions of installs, and no authentication required to plant the payload.

The immediate winners and losers are the usual ones. Attackers and commodity botnet operators get a broad, easily discoverable target against sites that are slow to patch — and WordPress sites are notoriously slow to patch. Site owners who update promptly lose nothing; those who leave the plugin unattended, as backup tools so often are, carry real risk until they act.

The structural takeaway is the one worth internalizing. As long as WordPress powers a large share of the web through a sprawling plugin ecosystem, the security of millions of sites will keep hinging on how fast a fix propagates from a plugin author to the long tail of installations that never check for updates. The patch exists and it works. Whether it reaches the 3 million sites that need it, before attackers do, is the part no advisory can control.

What to watch next: whether active exploitation is reported in the wild, how quickly the update propagates across the installed base, and whether the disclosure prompts a broader look at secret-key handling in other migration and backup plugins that operate with the same broad privileges.