Back to Security Notices
Security Notices

Is your All-in-One WP Migration plugin patched against CVE-2026-19949?

It's on more than five million WordPress sites and most of them aren't using it today. A flaw fixed in August, on software that does nothing visible and is easy to forget is even installed.

6 min read
Share

All-in-One WP Migration and Backup is installed on more than five million WordPress sites. Most of the people who have it aren't using it today, and a fair number couldn't tell you it's there at all.

That's the problem in one sentence. It's a migration tool. You use it once, when a site moves, and then it sits there doing nothing for years. It has a serious vulnerability, fixed in August, and it's the clearest example I know of a kind of risk that hides in plain sight: software doing nothing, on a site nobody is watching.

Start here

First, does this apply to you?

This is a WordPress plugin. If your site isn't WordPress, this one isn't yours.

If it's WordPress, the question is whether All-in-One WP Migration and Backup is installed. Not whether you use it, and not whether you remember installing it. Whoever built or moved your site may well have installed it to do the move and left it in place afterwards, which is the normal outcome rather than the careless one.

In plain terms

What the flaw lets someone do

The plugin's job is to pack a whole website into one file and unpack it somewhere else. The flaw is in the unpacking side.

Security researchers at Wordfence, who disclosed it, describe a two-step problem. An attacker with no account on the site can first extract a secret key the plugin uses to authorise an import, and then use that key to make the site import an archive of the attacker's choosing. An archive is an entire website, so the second step is close to handing over the site.

It's rated 8.8 out of 10, and it affects every version up to and including 7.109. It was found by a researcher called Jack Taylor and reported through Wordfence's bug bounty programme.

One honest note on the detail. The national vulnerability database describes it as reachable by an attacker with no account, but its own scoring line says some level of access is needed. Those two readings sit oddly together, and the chain above is what the disclosing researchers actually describe. It changes nothing about what to do, and you should know the record isn't perfectly tidy.

The awkward case

Why a dormant plugin is the hard one to catch

Most security advice assumes you interact with the thing you're being asked to check. You use your shop software. You log into your CMS. You see your page builder every time you edit a page.

A migration plugin isn't like that. You use it once when the site moves, and then it sits there, invisible, sometimes for years. Nothing about your day tells you it's installed. It doesn't appear on the front of your site, it doesn't email you, and it isn't in the list of things you think of as "my website".

It's still code that runs on your server, and it still needs updating. The whole reason this particular flaw matters is that the plugin is on millions of sites where nobody has thought about it since the day it was used.

One screen

How to check

Log in and go to Plugins. Look for All-in-One WP Migration and Backup in the list, and if it's there, look at its version number.

Anything up to and including 7.109 is affected. The fix landed in 7.110 on 20 August 2026, and the current version is 7.111. That release tightened permissions again: export and import now require administrator permission, closing a missing-authorisation issue where logged-in users who were not administrators could run a migration.

So 7.111 or later is where you want to be, not just 7.110.

Then sort yourself into one of these.

  • The plugin isn't in your list at all.

    Nothing to do here, and that's the most common answer.

  • It's there and on 7.111 or later.

    You're current. Something is updating it, which is worth knowing in itself.

  • It's there and on an older version.

    That's the one to raise today with whoever maintains the site.

  • You can't log in, or you don't know who can.

    That's the finding, and it's a bigger one than this flaw.

The better question

What else is installed that you never look at?

Whatever the answer, the more useful question is the one underneath it: what else is installed that you never look at?

A typical WordPress site carries somewhere between fifteen and forty plugins, and the ones that cause this kind of problem are rarely the ones you use daily. They're the ones installed for a job that finished. A form plugin from a campaign that ended. A gallery plugin from a redesign. A migration tool from a move.

The Plugins screen is the whole inventory, and reading it once a year is a genuinely useful half hour. Anything on it you can't explain the purpose of is worth a question rather than a decision: what is this for, and is anything relying on it?

Whatever you find, the answer isn't to start removing things. A plugin that looks dormant can be quietly holding up a contact form, a booking system, a payment integration or the backup routine itself, and finding that out after the fact is how a quiet afternoon becomes a bad one. The inventory is the useful part. What comes off, and when, is a conversation with whoever maintains the site.

The uncomfortable part

Updating closes the hole. It doesn't tell you who came through first.

Installing the update stops the flaw being used from that point on. It doesn't undo anything that happened before, and it doesn't tell you whether anything did.

If your site was running an affected version, that's a reasonable thing to raise with your host. Ask them to cover the whole period the old version was installed rather than just the date the flaw became public, because exploitation can predate disclosure, and ask for whatever their retention actually allows. The things to look for are unfamiliar administrator accounts and files that changed when nobody was working on the site. Ask sooner rather than later, because logs get discarded after a set period.

If anything does turn up, don't clean it up before someone has looked at it properly.

The real question

Who's actually watching the version numbers?

What carries a site through a week like this generally isn't vigilance. It's a routine that runs on a schedule whether or not anyone is thinking about it, and picks something up in August that nobody was watching for.

That's what makes the difference on a WordPress site, and it's worth being able to name who does it. It can be you with a reminder in the calendar, your host if their plan covers plugin updates and you've confirmed it does, an agency you already work with, or a care plan like the one I run. Disclosure, since I've just named my own: that last one is a service I sell.

What matters isn't which. It's that somebody could tell you, today, what's installed on your site and when it was last updated.

What to keep

The routine worth keeping

Know what's installed, know when it was last updated, and know whose job that is. The plugin you forgot about is the one that gets you.

About this notice

Published 2026-09-26 and accurate to the sources linked above as at that date. Security situations move, so check the vendor's own advisory before you act on anything here.

This is general information about a published vulnerability. It's not advice about your site, which nobody can give without looking at it, and nothing here should be treated as a substitute for your own provider or a security professional.

Questions

Questions local business owners usually ask next

Next step

Could you say what is installed on your site right now?

Most owners can't, and that's the gap this kind of flaw lives in. Send me the address and I'll tell you what I can see from the outside.