If your WordPress site uses the All-in-One WP Migration and Backup plugin, update it to version 7.110 today. Every version up to and including 7.109 carries a high-severity SQL injection flaw (CVE-2026-19949, CVSS 8.8) that can expose your database and, in the worst case, lead to a full site takeover. The plugin has more than five million active installations.
That does not mean five million sites were hacked. It means five million sites need to check a version number. Here is what the flaw is, in plain language, and exactly what to do about it.
The short version
| Plugin | All-in-One WP Migration and Backup |
| CVE | CVE-2026-19949 |
| Severity | 8.8 — High |
| Type | Second-order SQL injection (CWE-89) |
| Affected versions | 7.109 and every version before it |
| Fixed in | 7.110 |
| Active installations | 5,000,000+ |
| What to do | Update to 7.110 or later, then run a scan |
What is the security problem?
The flaw sits in the plugin’s archive restore feature. A user-supplied value was not escaped properly and the database query around it was not prepared safely. That combination lets an attacker slip extra SQL commands into a query the plugin runs.
What makes this one worth paying attention to is that it is a second-order injection. The attack does not fire the moment the attacker sends it.
- An unauthenticated attacker plants a harmful value on the site. Nothing appears to happen.
- The value sits quietly in the database, looking like ordinary data.
- Later, an administrator exports and restores the site using the plugin.
- During that restore, the planted value is read back and executed as part of a database query.
This is why the flaw is easy to miss. The damage happens during a routine maintenance task — a migration or a restore — which is exactly when an administrator is least likely to suspect anything. The gap between the attack and the effect can be weeks.
Once the injection runs, an attacker can read data they should never see. Security researchers specifically flagged the plugin’s ai1wm_secret_key as a target. With sensitive values like that in hand, and the right follow-up technique, this can escalate to running code on the server — which is another way of saying complete control of the website.
Am I affected?
You are affected if both of these are true:
- All-in-One WP Migration and Backup is installed on your site, and
- the installed version is 7.109 or older.
An important detail: deactivating the plugin is not enough on its own. A harmful value that was already planted stays in your database. If you reactivate the plugin later and run a restore, it can still fire. Update the plugin rather than simply switching it off, and if you no longer need it, delete it properly and then scan the site.
How to update the plugin
- Log in to your WordPress dashboard.
- Go to Plugins → Installed Plugins.
- Find All-in-One WP Migration and Backup and check the version number shown under its name.
- If it reads 7.109 or lower, click Update Now.
- Confirm the version now reads 7.110 or higher.
- While you are there, turn on auto-updates for the plugin so the next fix arrives without you having to watch for it.
If you manage several sites, check every one of them. In my experience the site that gets forgotten is never the main one — it is the old landing page or the staging copy nobody has logged into for a year.
What to check after you update
Updating closes the door. It does not tell you whether anyone already walked through it. Once you are on 7.110, work through this list:
- Run a full malware and security scan of the site files and database.
- Review your administrator accounts. Go to Users and confirm you recognise every account with an admin role. Attackers often add one that looks unremarkable.
- Look for content you did not create — unexpected posts, pages, or redirects that send visitors somewhere else.
- Check for recently modified files, especially anything changed around a date when you were not working on the site.
- Read your access logs if your host provides them, looking for repeated requests to plugin files.
- Change your passwords — WordPress, hosting, database and FTP — if anything at all looks wrong.
A word to healthcare and public-service websites
Hospitals, clinics, diagnostic centres and doctors’ practices should treat this with particular seriousness. These sites carry appointment requests, enquiry forms and personal details that people share expecting them to be handled carefully.
A compromised healthcare website damages more than a server. It damages patient trust, and that is far harder to restore than a database. The same applies to schools, local government pages and any site the public relies on for accurate information.
Please do not wait for something visibly broken before checking. A site can look completely normal and still be compromised — in fact, a careful attacker will make sure it does.
If you think your site was already compromised
Resist the urge to start deleting files or to immediately roll back to an old backup. Both destroy the evidence you need to understand what happened, and an old backup may already contain the planted value.
- Take a complete copy of the site as it currently stands, and keep it aside untouched.
- Preserve your server logs before they rotate and disappear.
- Bring in someone experienced with WordPress incident work to inspect the site, remove anything malicious, close the gap and confirm the site is genuinely clean.
- Only then restore normal operation, and rotate every credential involved.
Common questions
Does this mean my site has been hacked?
No. It means your site may have been exposed if it ran version 7.109 or older. Most sites will be fine. Update, scan, and confirm rather than assume either way.
I have never used the restore feature. Am I safe?
You are at lower risk, because the injected value needs a restore to fire. But a planted value can sit in your database indefinitely, waiting for the day you do run one. Update anyway.
Do attackers need a login to exploit this?
No. The initial injection can be performed without authentication, which is a large part of why the severity is rated 8.8. The execution step, however, depends on an administrator running a restore.
Should I just delete the plugin?
If you no longer use it, yes — every plugin you remove is one less thing to patch. Delete it fully rather than leaving it deactivated, and run a scan afterwards, because removal does not clean data that was already planted.
The wider lesson
Plugins are where most WordPress sites are actually broken into. Not the core software, which is maintained carefully and updated promptly — the add-ons around it.
Three habits prevent most of this. Keep the number of installed plugins as small as you can genuinely justify. Turn on automatic updates for the ones you keep. And remove anything you are not actively using, rather than leaving it deactivated as a just-in-case.
A ten-minute update today is a great deal cheaper than a compromised site next month.
Need help checking your site?
I have spent 24 years building and maintaining websites, applications and servers for businesses in India and internationally. If you are unsure whether your site is affected, or you want someone to review it properly, get in touch — or read more about how I work.