All-in-One WP Migration SQL injection flaw puts millions of WordPress sites at takeover risk

A second-order SQL injection in the All-in-One WP Migration and Backup plugin can be escalated into full takeover of a WordPress site, according to BleepingComputer. The flaw, tracked as CVE-2026-19949 and rated high severity, affects version 7.109 and earlier. WordPress.org lists more than 5 million active installations of the plugin, and BleepingComputer reports that only about 35 percent had been updated when the story ran, leaving millions of installs exposed.

How the attack chain unfolds

The vulnerability is second-order because the payload is stored in the database first and only executed later, when a trusted operation touches it. Wordfence's technical analysis, referenced in the report, describes a chain with distinct stages:

• An unauthenticated attacker plants specially crafted data through public input channels such as trackbacks. At this point nothing runs; the payload simply sits in the database, often looking like odd quotes or backslashes.
• An administrator later exports, imports, or restores a backup. The plugin rewrites URLs and table prefixes inside the archive, and during that rewrite the planted data is executed as SQL.
• The injection writes the plugin's ai1wm_secret_key to a publicly readable location such as a comment.
• Armed with the secret key, the attacker authenticates to the plugin's import endpoint without credentials and uploads a malicious .wpress archive containing executable code.
• The archive is unpacked on the server, the code runs, and the attacker controls the site.

The trigger is what makes the bug practical: the attacker never needs to trick or contact the administrator directly. Routine backup and migration work — the exact task this plugin exists to do — detonates the payload.

What compromise looks like

To ordinary visitors the site keeps working normally, so defacements, redirects, or malware aimed at visitors can go unnoticed for a long time. The report lists warning signs administrators can hunt for:

• Trackbacks or comments stuffed with unusual quotes and backslashes that probe SQL escape boundaries.
• Strange SQL queries during restore operations, or the secret key surfacing in public comment content.
• Imports of .wpress archives from unknown sources, immediately followed by new PHP files and child processes spawned by the web server.

Because the hostile input and its execution can be separated by days, the report stresses that web access logs alone are not enough. Restore jobs, database activity, and public input bodies need to be correlated across a long time window to connect the stages.

Fixes and hardening

Version 7.110, released on August 20, 2026, patches the issue. The recommended actions:

• Update to 7.110 or later and delete any unused old or disabled copies of the plugin.
• Disable or strictly validate public inputs such as trackbacks if they are not needed.
• Restrict restore and import functions to administrative networks, and rotate the secret key along with database and hosting credentials.
• For sites that ran older versions, review the plugin's entire active period for planted payloads, unexpected restores, unknown archives, and modified PHP files.

Why it matters

Backup and migration plugins are unusually dangerous places for a flaw: they read the entire database, write files to the server, and are trusted with credentials. A single injection in that context escalates naturally to remote code execution and full site takeover, which is precisely what this chain demonstrates.

The scale also matters. With more than five million installs and only about a third patched at the time of reporting, the vulnerable population is in the millions, and exploitation requires nothing beyond ordinary administrative activity on the target site. BleepingComputer had no confirmation of large-scale exploitation in the wild at publication time, but the number of compromised, unpatched sites is unknown.

Finally, the bug is a useful reminder that second-order injection defeats naive monitoring. The hostile input and the resulting execution happen in different requests, on different days, in different logs, and detection has to join them together — a standard defenders face on every platform, not just WordPress.