What has happened
All-in-One WP Migration and Backup is a familiar tool for moving and restoring WordPress sites, with more than five million active installations. On 1st September 2026, Wordfence published details of a security weakness that could put those sites at risk if a particular export and restore sequence takes place.
Researcher Jack Taylor reported the issue to Wordfence on 14th August. The plugin developer, ServMask, then released version 7.110 on 20th August. That update is the important part for site owners because it fixes the problem in every version up to and including 7.109.
The vulnerability is recorded as CVE-2026-19949 and has a High severity score of 8.8 out of 10. Those labels help security teams track the issue, but you do not need to understand them to respond. The official WordPress.org plugin page confirms the change in version 7.110 and credits Taylor for reporting it responsibly.
What SQL injection means in plain English
To understand why the update matters, it helps to know what the flaw does. WordPress keeps posts, settings, users and other important information in a database. SQL is simply the language used to read and change that database. With a SQL injection flaw, information that should remain ordinary text can instead be treated as a command.
In this case, that does not happen straight away. The attacker first sends harmful information through a trackback, an older WordPress feature that notifies a post about an incoming link. The information can remain stored on the site until an administrator exports it and later imports the archive with the vulnerable plugin. During that restore, the plugin can mistake the stored text for a database command and run it.
Security researchers call this a second-order SQL injection because the information is stored first and becomes dangerous during a later action. The useful point for site owners is the order in which it happens: the harmful information is planted first, then a later export and restore can set it off.
Why the restore step matters
That extra restore step changes how this warning should be understood. The vulnerability is unauthenticated, which means an attacker does not need a WordPress account to place the harmful information. Even so, simply having the plugin installed does not give somebody immediate control of the site.
The attack only moves to its next stage when an administrator exports the site and imports the resulting archive. Because those are normal actions for a migration plugin, the condition cannot be ignored, but it does help explain which sites may need a closer review.
If the full sequence succeeds, the attacker may obtain a private key used by the plugin and use it to make the server run code of their choosing. In practical terms, that could give them control of the WordPress site.
Who needs to update
Although the attack relies on that sequence of events, the update advice is straightforward. Any site with All-in-One WP Migration and Backup 7.109 or earlier should move to a fixed release, even if the plugin has not been used recently or there is no migration planned.
Open Plugins > Installed Plugins in WordPress and find All-in-One WP Migration. The installed version appears with the plugin details. If it shows 7.109 or an earlier number, update it to 7.110 or the latest version available.
A firewall may provide another layer of protection, but updating remains the more dependable response because it removes the known weakness from the plugin itself.
What site owners should do now
If version 7.110 or later is already active and the plugin was not used for a recent export and restore, there is unlikely to be anything more to do for this specific issue. Otherwise, work through these steps in order:
- Check the plugin version. Look under Plugins > Installed Plugins for All-in-One WP Migration and Backup.
- Update to version 7.110 or later. Confirm the new version number after the update finishes.
- Update before exporting or restoring. If you cannot update immediately, do not use an older version for another migration or restore.
- Review any recent migration or restore. If an administrator exported and imported the site while version 7.109 or earlier was active, a security review is sensible. This does not mean the site was attacked, only that the sequence needed for the vulnerability took place.
- Remove unused copies. If the site no longer needs the plugin, remove it instead of leaving an old version installed and forgotten.
What to check after a recent restore
A recent restore with an affected version is a reason to check the site, not proof that it was compromised. The review becomes more worthwhile if public posts accepted trackbacks before the archive was created. Updating closes the vulnerable route, while the review checks whether anything happened before that update.
That review should bring the main signs of unexpected access together:
- administrator accounts you do not recognise
- plugins and must-use plugins that nobody on your team installed
- unexpected file changes around the time of the restore
- security and server logs showing unusual activity
- hosting, WordPress and database credentials if there are signs of access
If something unfamiliar appears, avoid deleting it until somebody has checked what it is. Removing the wrong file can break the site or make an investigation harder. A full WordPress malware review can check the files and database together.
How BugShield handles plugin security updates
Keeping plugins current is easier when it is part of the site's regular care. On BugShield maintenance plans, a developer can review the release, apply it and check the site afterwards through our managed plugin updates. This works alongside site monitoring and off-site cloud backups.
If you are not on a maintenance plan and would like help updating or checking a recent restore, you can request a one-off WordPress fix. If there are already signs that somebody gained access, choose WordPress malware removal so the investigation covers more than the plugin version.
For most site owners, this comes back to one practical step: make sure All-in-One WP Migration is on version 7.110 or later before the next export or restore.
Quick answers about the All-in-One WP Migration vulnerability
Which versions of All-in-One WP Migration are affected?
If your site is using All-in-One WP Migration and Backup 7.109 or earlier, it is within the affected range. Updating to version 7.110 or any newer release offered through WordPress will apply the security fix.
Does an attacker need a WordPress account?
An attacker does not need a WordPress account to place the harmful data. However, the disclosed attack only reaches its final stage after a site administrator exports and then imports the site using a vulnerable version of the plugin.
Is my site safe if I have not restored an archive?
Without an export and restore, the harmful database command described by Wordfence is not triggered and this particular attack chain cannot be completed. Updating is still important because it prevents a future migration or restore from activating stored harmful data.
What should I do if I use All-in-One WP Migration?
Start by updating the plugin to version 7.110 or later and checking that the new version is active before creating or restoring another migration archive. If you recently completed a restore with version 7.109 or earlier, a security review is also sensible.
Should I remove the plugin after updating it?
If your site still uses All-in-One WP Migration, you can keep it once the fixed version is active. If the plugin is no longer needed, removing it leaves one less piece of software to maintain and update.