Your WordPress Backup Could Be Waiting to Betray You
A flaw affecting more than five million WordPress sites does not need to strike immediately. It can wait inside the database until an administrator performs the very task meant to protect the site: restoring a backup.
The All-in-One WP Migration vulnerability, CVE-2026-19949, is a second-order SQL injection in the widely used All-in-One WP Migration and Backup plugin. An unauthenticated attacker can plant a malicious payload through WordPress trackbacks. The code stays dormant until a privileged user exports and later imports or restores the affected site.
That delayed trigger changes the security model. A backup is normally treated as a trusted recovery asset. Here, it can preserve the attacker’s input and carry it across a migration, disaster-recovery exercise or incident response.
The attack waits for an administrator
According to Wordfence’s technical analysis, published on 1 September 2026, the vulnerable code handles database content during an export and import sequence. The attacker first submits a crafted trackback that WordPress stores in the database. Nothing obvious has to happen at that point.
The payload becomes active when an administrator uses the plugin to move or restore the site. A successful exploit can expose the plugin’s secret key through a public comment. That key can then be used to drive an unauthenticated import of a malicious .wpress archive.
The archive can include a must-use plugin. WordPress loads those plugins automatically, which turns the database injection into remote code execution and potentially a complete site takeover.
Why the backup is the real trust boundary
This is more serious than a conventional injection flaw because the malicious input crosses time and operational boundaries. It may survive routine reviews, enter an offline archive and return months later during restoration. Security teams could clean the live site and still preserve the seed of reinfection in older backups.
The vulnerability also creates an awkward incident-response problem. If a site has received untrusted trackbacks while running a vulnerable version, updating the plugin protects future operations but does not prove that existing database contents and backup files are clean.
That means defenders should treat recent migration archives as potentially affected evidence, not automatically trusted recovery media.
Who is affected and what fixes it
All-in-One WP Migration and Backup versions up to and including 7.109 are affected. Version 7.110, released on 20 August 2026, contains the fix. The vulnerability carries a CVSS score of 8.8, which is rated High.
The official CVE record was published on 25 August 2026 at 11:27:11 UTC and updated on 27 August at 15:06:46 UTC. BleepingComputer reported the broader takeover path on 2 September at 15:28.
Administrators should update to version 7.110 or later before performing another export, import or restore. They should also review stored trackbacks, public comments, unexpected import activity and the wp-content/mu-plugins directory for unfamiliar files.
Do not restore first and investigate later
If compromise is suspected, preserve a copy for forensic analysis but do not use it as the first recovery source. Build a clean WordPress environment, install current plugin versions and validate database content before importing it.
Rotate WordPress administrator credentials, hosting credentials, database passwords and any application secrets that may have been available to the compromised site. Review web logs for trackback submissions and unexpected plugin import requests.
The uncomfortable lesson is simple: backups inherit the trust problems of the systems that create them. Recovery media is not clean merely because it is old, offline or labelled as a backup. For millions of WordPress sites, the safest restore now begins with verifying what the archive is carrying.
