Imagine an attacker leaves two odd little packages on your WordPress site today. Nothing dramatic happens. The shop keeps taking orders, the contact form works, and nobody gets an alert.
Weeks later an administrator exports that site’s data into a .wpress archive. Later still, someone imports that archive to restore a site using the same vulnerable plugin. That restore is the moment the planted data can turn dangerous.
This delayed trigger is what makes CVE-2026-19949 different from the usual “visit this URL and the site is hacked” story. The flaw affects All-in-One WP Migration and Backup 7.109 and older. It carries a CVSS score of 8.8, yet the practical path is indirect and needs several pieces to line up.
Still, if this plugin is on your site, update it before the next export, import, or restore. Not after. Before.
The dangerous action may happen later
An attacker doesn’t need a WordPress account for the first step. They need a public post that accepts pings, then they can submit two specially crafted trackbacks. Those trackbacks plant malicious values in the database.
Next, an administrator exports the poisoned site’s data into a .wpress archive. Export alone transports the stored values. It does not trigger the SQL injection.
The trigger comes later if an administrator imports or restores that archive with All-in-One WP Migration 7.109 or older. During the restore, the plugin’s find-and-replace processing handles the planted values and can turn them into a second-order SQL injection.
“Second-order” sounds academic. The plain-English version is nastier: hostile data enters in one place, rides inside an archive, then becomes dangerous when a trusted restore process reads it.
That matters for a small business because restores often happen during an already stressful moment. A broken update. A failed server move. A staging copy that needs to go live by Monday morning. You’re focused on getting the site back, not on two trackbacks received weeks ago.
How SQL injection could become code execution
The SQL injection may reveal the plugin’s ai1wm_secret_key. The CVE says access to that key can enable remote code execution through All-in-One WP Migration’s unauthenticated import controller.
Detailed reporting describes a possible route involving a crafted .wpress import containing a malicious must-use plugin. A must-use plugin is PHP code that WordPress loads automatically from wp-content/mu-plugins/. If hostile code lands there and runs, an attacker may be able to execute commands on the server.
That description explains the potential RCE impact. It should not be read as independent confirmation that a separate malicious import happened in a real attack. As of September 2, no such in-the-wild exploitation has been confirmed.
This is a chain, not a magic button. The site must accept the two crafted trackbacks, an administrator must export the poisoned data, and that archive must later be imported or restored using version 7.109 or older. Multiple conditions make exploitation less direct.
That explains the odd-looking risk picture. CVSS gives CVE-2026-19949 an 8.8, while Patchstack rates the practical priority low and exploitation unlikely. Both can be true. A successful chain has a severe result, but reaching that result is awkward.
The Wordfence vulnerability record lists the affected versions and the 7.110 fix for anyone who wants the technical reference.
Five million installations does not mean five million vulnerable sites
All-in-One WP Migration and Backup has more than 5 million active installations across all versions. That’s the plugin’s total active-install count, not a claim that 5 million sites are vulnerable today.
Only sites still running version 7.109 or older are affected. Version 7.110 fixed the flaw on August 20, before public disclosure on August 24 and 25. Sites that updated promptly already closed this path.
As of September 2, there are no confirmed reports of exploitation in the wild, no reliable public proof of concept, and no CISA Known Exploited Vulnerabilities listing. Good news. It means owners have room to act calmly instead of treating every .wpress archive as a bomb.
And no, you shouldn’t assume every backup archive is malicious. Most aren’t. The sensible response is to patch the software that creates and processes them, then look more closely only where the full sequence may have occurred.
A managed WordPress vulnerability scanner can flag an old plugin version. It can’t prove whether crafted data entered a site, travelled through an export, and was later processed during a vulnerable restore. Version checks and incident evidence answer different questions.
What to do before your next restore
- Update to All-in-One WP Migration 7.110 or newer. Do this before running an export, import, migration, or restore.
- Remove the plugin if you don’t use it. A forgotten migration tool shouldn’t stay active all year just because it might be handy someday.
- Keep your backup, but know what it can and can’t do. A clean recovery process matters more than collecting archives. Our guide explains why a backup is not the same as a recovery plan.
- Record restore activity. Note when the export and restore happened, which archive was used, and which plugin version processed it.
For sites covered by regular WordPress maintenance, the patch should go ahead of any planned migration work. Updating closes the vulnerable route. Simple.
But it doesn’t travel backwards in time. Installing 7.110 proves the current code is patched; it does not prove that an attacker failed to reach RCE before the update.
If you restored on 7.109 or older
Don’t start deleting files based on a scary headline. First ask whether the same sequence is plausible: did a public post accept pings, could two crafted trackbacks have arrived, was the poisoned site’s data then exported into a .wpress archive, and did an administrator later import or restore that archive using version 7.109 or older?
If the answer might be yes, take a snapshot before cleanup and triage the site. Preserve the suspect archive too. Don’t test it on production; inspect it, or restore it only in an isolated environment using patched software.
Inspect WordPress users, the mu-plugins directory, recently changed PHP files, database records, and web-server logs. Preserve timestamps and suspicious files. They may be the only clues left.
The first response should be methodical. Our walkthrough of the first 24 hours after a WordPress hack explains why evidence comes before enthusiastic deleting.
If triage confirms compromise, a proper WordPress site cleaning needs to check the wider installation, not just remove All-in-One WP Migration and hope. After evidence capture and cleanup, rotate relevant credentials and invalidate active sessions.
The useful takeaway
This flaw waits. An unauthenticated attacker can plant two trackbacks now. An administrator may later export those poisoned values into an archive, then trigger the dangerous processing by importing or restoring that archive with version 7.109 or older.
Update All-in-One WP Migration and Backup to 7.110 or newer before any export, import, or restore. Remove it if it’s unused. If the full sequence may already have happened, snapshot first, preserve the archive, and investigate before cleaning.
No panic. No archive bonfire. Just patch before a vulnerable restore can pull the trigger.