WordPress backup plugin flaw exposes millions of sites to takeover attacks

# The Plugin That Was Supposed to Save You Is Now Your Biggest Risk

Backup software occupies a strange position in the security hierarchy. It's the last line of defense, the thing you reach for when everything else has gone wrong. Which makes it a particularly savage irony when the backup plugin itself becomes the door your attacker walks through.

A critical SQL injection vulnerability in All-in-One WP Migration and Backup — a WordPress plugin installed on more than five million sites — allows unauthenticated attackers to chain that flaw into remote code execution and full site takeover. No login required. No credentials to phish, no admin panel to brute-force. Just a malicious HTTP request, and the keys are yours.

## How the Chain Works

SQL injection vulnerabilities are not exotic. They've been in the OWASP Top 10 for two decades and remain stubbornly common because they're easy to miss during development and easy to exploit when missed. The dangerous part of this particular flaw isn't the injection itself — it's what comes after.

The plugin's vulnerable parameter accepts unsanitized user input that gets executed against the WordPress database. From there, an attacker can read database contents (which includes user credentials, session tokens, configuration data), write to the filesystem through SQL's file-write capabilities on misconfigured servers, and ultimately plant a web shell or modify core files to achieve persistent code execution. The jump from SQLi to RCE isn't guaranteed on every server configuration, but on a significant percentage of shared hosting environments — which is where most of these five million sites live — the conditions exist.

Unauthenticated access is what elevates this from serious to critical. Authenticated vulnerabilities require an attacker to already hold some foothold: a compromised user account, a phished credential, a prior breach. Unauthenticated flaws let anyone on the internet run the exploit. That's not a nuance — it's the difference between a targeted attack and a mass-scanning campaign that sweeps every vulnerable site indiscriminately.

## Five Million Is Not a Random Number

All-in-One WP Migration has been around since 2013. It's one of the most-downloaded backup plugins in the WordPress ecosystem precisely because it works and it's free at the basic tier. That longevity is a feature for users and a gift for attackers: a single vulnerability in a widely-trusted, rarely-questioned plugin creates an attack surface measured in the millions.

WordPress plugin vulnerabilities follow a recognizable pattern. A plugin achieves broad adoption. It gets embedded into managed hosting platforms, one-click installers, and agency boilerplate stacks. Updates slow down as the plugin matures. Security audits are rare. Then someone finds a flaw, and the race begins between the plugin maintainer pushing a patch and attackers scanning for unpatched installations.

The timeline here matters. Mass scanning campaigns for WordPress plugin vulnerabilities typically spin up within 24 to 48 hours of public disclosure. Threat actors don't need to understand the vulnerability deeply — they pull working proof-of-concept code from GitHub or exploit frameworks and point it at bulk site lists. If you're running a vulnerable version and haven't patched within that window, assume you've been scanned. Assume you may have been compromised.

## Who Gets Hurt

The stereotype of a hacked website is a defacement — a government flag replacing a homepage, a hacker group's calling card. That's the rare outcome. The far more common scenario is quiet compromise: a web shell planted in a legitimate-looking directory, the site enrolled in a botnet for spam distribution or credential stuffing, or — increasingly common — the site's hosting environment used as a staging platform for attacks on other targets.

Small businesses are disproportionately exposed here. The vast majority of All-in-One WP Migration installations are on sites maintained by people who don't have a dedicated security function. They installed the plugin because it was the top result when they searched "WordPress backup," and they haven't thought about it since. Auto-updates, if enabled, may not have triggered yet. Managed WordPress hosts may or may not have pushed emergency updates.

Agencies that manage WordPress sites on behalf of clients face a different version of the same problem: they may have the plugin deployed across dozens or hundreds of client sites, and the blast radius of a missed patch is correspondingly larger.

## What to Do Right Now

The fix is straightforward: update to the patched version. Open your WordPress dashboard, go to Plugins, find All-in-One WP Migration and Backup, update immediately.

If you're managing sites at scale:

The backup irony cuts deep here: if your only backup mechanism is the compromised plugin, and the backup files live on the same server, an attacker who's achieved file-write access has potentially also tampered with your recovery path.

---

## HackWire Analysis

This vulnerability lands in a broader pattern that defenders keep relearning the hard way: security and backup plugins are among the highest-value targets in the WordPress ecosystem, precisely because of the elevated privileges they require to function. A backup plugin needs read access to your entire filesystem, your database credentials, and often the ability to write files anywhere on the server. That capability set makes a vulnerability in such a plugin dramatically more dangerous than a flaw in, say, a contact form widget.

What other coverage is missing from this story: the supply-chain dimension. Backup plugins are frequently bundled by managed WordPress hosts as part of their platform offering. When a host auto-installs All-in-One WP Migration for tens of thousands of customers, a single plugin vulnerability becomes a platform-level exposure. Hosts that haven't pushed an emergency update are operating with millions of customer sites sitting on a known-vulnerable plugin right now.

The broader trend here is the commoditization of WordPress exploitation. Attack toolkits targeting WordPress plugins are widely available, constantly updated, and require minimal technical skill to operate. The barrier to running a mass-scanning campaign against a newly-disclosed plugin vulnerability is low enough that you should assume automated exploitation begins within hours, not days, of disclosure. The calculus for defenders has to shift accordingly: plugin updates are no longer something you schedule for the next maintenance window. Critical CVEs in widely-deployed plugins require same-day response.

There's also a question worth asking about the plugin audit process more broadly. All-in-One WP Migration has five million active installations and has been in the repository since 2013. How many security researchers have reviewed it? The WordPress plugin repository does not require security audits for listing. Popular plugins exist in a strange trust equilibrium — their popularity is taken as evidence of safety, even as their popularity makes them the most attractive targets.

For defenders right now: patch, audit your logs, verify your backups are stored somewhere an attacker with file-write on your server can't reach, and treat your backup plugin like the privileged access tool it actually is.

— HackWire Editorial

---

## Related Coverage