--- title: "All-in-One WP Migration: A SQL Injection That Waits" slug: "all-in-one-wp-migration-sql-injection-cve-2026-19949" description: "The All-in-One WP Migration vulnerability plants SQL through trackbacks and detonates when an admin restores a backup. Patch to 7.110 now." date: 2026-09-14 author: "WP Vanguard Team" category: "Research" tags: ["all-in-one-wp-migration-vulnerability", "cve-2026-19949", "second-order-sql-injection", "sql-injection", "backup-plugin"] featured_image: "/images/blog/all-in-one-wp-migration-sql-injection-cve-2026-19949.jpg" --- An attacker can plant a SQL payload on your WordPress site today and have it fire weeks later, the next time an admin restores a backup with the plugin. That is the shape of the All-in-One WP Migration vulnerability tracked as CVE-2026-19949, and it is why this one is worth understanding even if you already updated the plugin. The plugin has more than 5 million active installations. It is patched in version 7.110, shipped August 20, 2026. As of September 2, roughly 3.25 million installs, about 65 percent of the base, were still running a vulnerable build. CVSS score: 8.8. ## The All-in-One WP Migration Vulnerability, by the Numbers Wordfence's own record describes it plainly: All-in-One WP Migration and Backup up to and including version 7.109 has insufficient escaping and an insufficiently prepared existing SQL query in its archive restore functionality. That gap lets an unauthenticated attacker append extra SQL to a query the plugin already runs, extract data from the database, and, when a site administrator performs an archive restore, obtain the plugin's `ai1wm_secret_key`. With that key in hand, the attacker can reach remote code execution. Researcher Jack Taylor reported the flaw to Wordfence's Bug Bounty Program on August 14, 2026, and earned a $5,761 bounty for it. Wordfence validated the report and notified ServMask, the plugin's developer, the next day. ServMask shipped the fix in 7.110 on August 20. The CVE went public on August 25. Wordfence's full technical write-up followed on September 2, by which point the patch had been available for thirteen days and still reached barely a third of installs. No source describes exactly what changed inside 7.110's code. Wordfence's own advisory doesn't publish a diff, and neither does ServMask's changelog entry beyond noting the fix. What's confirmed is the effect: sites running 7.110 or later are not exploitable through this chain. Sites on 7.109 and earlier are. ## What Second-Order SQL Injection Actually Is Most SQL injection writeups describe a single request: an attacker sends a malicious string, an application drops it straight into a query, and the database executes it on the spot. That's first-order injection, and it's the version most WAF rules are tuned to catch. Second-order injection splits that into two separate events. The attacker's input gets stored first, through some ordinary-looking channel, and passes any validation checks in place at that moment. It sits in the database as data. Later, a completely different part of the application reads that stored value back and uses it to build a new query, without re-checking or re-escaping it. The string that looked harmless on the way in becomes executable SQL on the way out. That gap between planting and detonation is what makes second-order injection hard to catch. A web application firewall inspects requests as they arrive. If the payload does nothing at arrival time, there's nothing to flag. The dangerous part happens later, inside an operation that has nothing to do with the original request, which is exactly the pattern CVE-2026-19949 follows. ## Plant, Wait, Detonate: How the Chain Plays Out The attack runs in five stages, and only the first one requires reaching the target site at all. **Plant.** WordPress core's trackback functionality accepts pings from anywhere on the internet without authentication. An attacker submits a crafted trackback to a public post, containing backslash and quote sequences designed to break out of a string later. WordPress stores it in the comments table like any other trackback. Nothing executes. It looks like routine comment traffic, and most sites accumulate exactly that kind of traffic constantly. **Wait.** The payload does nothing until a specific, unrelated action happens: a site administrator uses All-in-One WP Migration to export or restore a backup. That's not a rare event. For a plugin whose entire purpose is moving WordPress sites around, it's the most normal thing an admin does with it. **Detonate.** During restore, the plugin rewrites URLs and database table prefixes throughout the site's stored content, and that rewrite process runs through SQL queries against strings already sitting in the database, including the planted trackback. Because those queries don't handle the backslash and quote sequences correctly, the stored text escapes its intended string boundary and runs as part of the query instead of as a value inside it. **Leak the key.** The injected SQL reads `ai1wm_secret_key`, the plugin's own import-authentication token, and writes it somewhere publicly retrievable: an approved comment, exposed through the site's REST API. An attacker watching the target site pulls it with a plain unauthenticated GET request. **Take over.** With the secret key, the attacker authenticates to the plugin's import endpoint directly and uploads a crafted `.wpress` archive. A `.wpress` archive can contain a must-use plugin, and files placed in `wp-content/mu-plugins/` load automatically on every page request, no activation required. The moment the archive unpacks, the attacker's PHP runs at the web server's privilege level. There's no confirmed case of this chain being used in an active attack yet. There doesn't need to be for the exposure to matter: SOCRadar's threat-intelligence feed already lists a weaponized proof-of-concept for this CVE, meaning someone has built working exploit code, whether or not it has been deployed against a real site yet. That distinction between "no known live attacks" and "no working exploit exists" is not the same thing, and it's worth holding onto when you decide how urgently to patch. ## How to Check and Patch Update the plugin first. Nothing else in this list substitutes for it. ```bash wp plugin update all-in-one-wp-migration wp plugin get all-in-one-wp-migration --field=version ``` Confirm the reported version is 7.110 or later. If you can't update immediately, deactivating the plugin removes the reachable restore code path without touching your existing backup files. ```bash wp plugin deactivate all-in-one-wp-migration ``` Check for trackback-planted rows that predate your update. A malicious trackback sitting in your database from before you patched is inert against 7.110, but it's still worth knowing it's there. ```bash wp comment list --comment_type=trackback --status=all --format=table ``` Look for trackbacks with unusual backslash or quote patterns in the content or author URL fields. Anything that doesn't read like a normal pingback is worth a closer look. Audit `wp-content/mu-plugins/` for anything you don't recognize: ```bash ls -la wp-content/mu-plugins/ ``` A must-use plugin file you didn't put there is a serious finding on its own, regardless of how it got there. Our [signs your WordPress site has been hacked](/blog/signs-wordpress-site-hacked) checklist covers the broader set of indicators worth checking alongside this one. If you don't use trackbacks or pingbacks, turning them off closes the unauthenticated planting step entirely. In wp-admin, go to Settings, then Discussion, and uncheck "Allow link notifications from other blogs (pingbacks and trackbacks) on new posts." It's a standard WordPress setting, and it removes this particular door without touching anything else on the site. If you find evidence that a restore ran while a malicious trackback was present and unpatched, don't stop at deleting the offending row. Our [WordPress malware removal guide](/blog/wordpress-malware-removal-guide) walks through what a real cleanup looks like once code may have already run on the server. Backup and migration plugins carry more trust than almost anything else in a WordPress install, because they're built to touch every table and every file on purpose. CVE-2026-19949 didn't need to find a weak login form or an unlocked upload folder. It needed the plugin to do the one thing it's designed to do. [Run a free scan with WP Vanguard](/#scanner) to check your plugin versions and look for the file-level indicators this kind of exploit chain leaves behind. ## References - [SecurityWeek: Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability](https://www.securityweek.com/over-3-million-wordpress-sites-affected-by-migration-plugin-vulnerability/) - [TechTimes: WordPress Backup Plugin Flaw: 3.25 Million Sites Exposed, Exploit Code Active](https://www.techtimes.com/articles/326402/20260903/wordpress-backup-plugin-flaw-325-million-sites-exposed-exploit-code-active.htm) - [Wordfence: 5 Million WordPress Sites Affected by SQL Injection Vulnerability in All-in-One WP Migration and Backup WordPress Plugin](https://www.wordfence.com/blog/2026/09/5-million-wordpress-sites-affected-by-sql-injection-vulnerability-in-all-in-one-wp-migration-and-backup-wordpress-plugin/) - [SentinelOne Vulnerability Database: CVE-2026-19949](https://www.sentinelone.com/vulnerability-database/cve-2026-19949/) - [DEV Community: All-in-One WP Migration CVE-2026-19949, From Second-Order SQL Injection on Restore to Site Takeover](https://dev.to/anoymask/all-in-one-wp-migration-cve-2026-19949-from-second-order-sql-injection-on-restore-to-site-takeover-21be)