Vulnerabilities

3.25 Million WordPress Sites Are Still Sitting on a Backup Time Bomb

September 3, 2026September 3, 2026

6 mins

The Mess: A second-order SQL injection in the popular All-in-One WP Migration and Backup plugin can ultimately lead to remote code execution and full WordPress takeover. The vulnerability, tracked as CVE-2026-19949, affects versions through 7.109, while the fixed 7.110 release has reached only a fraction of installations.
The Damage: An attacker can plant malicious data without authentication and wait for an administrator to perform a normal backup restoration before turning that dormant payload into control of the entire website.
The Fix: Update All-in-One WP Migration and Backup to 7.110 or later immediately, then inspect affected sites for suspicious comments, administrator accounts, plugin changes and unexpected .wpress imports.

Your backup plugin is supposed to save the website.

This one can potentially help an attacker take it.

A newly disclosed vulnerability in All-in-One WP Migration and Backup puts millions of WordPress installations at risk. The flaw is tracked as CVE-2026-19949 and was discovered by security researcher Jack Taylor before being investigated and disclosed by Wordfence.

The plugin is enormous.

WordPress.org reports more than five million active installations.

And that creates a particularly ugly patching problem.

According to telemetry cited by Wordfence, only around 35% of installations had moved to the fixed release by September 2. That left approximately 3.25 million websites running a vulnerable version.

The vulnerability is a second-order SQL injection.

That description matters.

This isn’t the usual attack where somebody sends one malicious request and immediately gets a database response.

The attacker plants malicious data first.

The payload waits.

Then a completely legitimate administrative operation eventually triggers it.

In this case, the vulnerable functionality is connected to the plugin’s database restoration process.

The attacker can inject specially crafted data through WordPress trackbacks. That data can remain dormant until an administrator performs an export/import or restoration operation. During that process, the plugin rewrites database content and incorrectly handles escaped backslashes and quotation marks.

That is where the SQL injection fires.

And the attack chain does not stop at the database.

Researchers say the injected SQL can expose the plugin’s secret import key, ai1wm_secret_key.

Once an attacker obtains that key, they can potentially import a malicious .wpress archive.

That archive can contain executable PHP code.

Now the attacker isn’t just reading the database.

They can potentially take over the WordPress site.

Administrator-level control.

Plugins.

Themes.

Database.

Content.

Server-side code.

Everything that comes with owning the application.

The irony is obvious.

The administrator performs a routine recovery or migration operation.

The attacker’s dormant payload wakes up.

The victim effectively presses the button for them.

That requirement does reduce the immediate attack surface.

An attacker cannot necessarily trigger the complete chain whenever they want.

They need the vulnerable plugin and an administrator to perform the relevant import or restoration process.

But backup and restoration are literally what this plugin exists to do.

That makes the prerequisite much less comforting.

Sites migrate.

Backups get restored.

Staging environments get rebuilt.

Hosting providers move customers.

Developers test disaster recovery.

The trigger is not some bizarre administrative action nobody performs.

It is normal WordPress maintenance.

ServMask, the plugin’s developer, was notified on August 15.

The vulnerability was fixed in version 7.110, released on August 20.

The problem is what happened afterward.

Millions of sites did not update.

And WordPress administrators are notoriously good at installing plugins and notoriously bad at remembering that plugins are software.

Every plugin adds code.

Every plugin gets privileges.

Every plugin eventually gets a vulnerability.

Backup plugins are particularly interesting targets because they routinely have access to almost everything that makes a WordPress installation valuable.

The database.

Uploads.

Themes.

Plugins.

Configuration.

Credentials and secrets.

A vulnerability in a contact form plugin may expose a database table.

A vulnerability in a backup plugin can potentially expose the entire site.

That difference should change how administrators prioritize patches.

If your WordPress site is running All-in-One WP Migration and Backup, check the version now.

Anything at 7.109 or earlier should be considered vulnerable.

Update to 7.110 or later.

Then investigate.

A simple version update is appropriate for an unexploited installation.

It is not enough if the site may already have been compromised.

Look for unexpected administrator accounts.

Suspicious trackbacks.

Unknown PHP files.

Unexpected plugin modifications.

Unfamiliar scheduled tasks.

Unusual .wpress imports.

Changes to the plugin’s configuration.

Unexpected requests around import or migration functionality.

And if the site was vulnerable for an extended period and handles sensitive information, don’t assume that the absence of an obvious defacement means nothing happened.

Attackers don’t always replace your homepage.

Sometimes they quietly create another administrator and leave.

Sometimes they install a webshell.

Sometimes they steal credentials and return later.

The second-order nature of CVE-2026-19949 makes this particularly interesting from a detection perspective.

The malicious input may exist before the actual exploitation event.

That means defenders should not only search for the final payload.

They should also investigate the data that could have acted as the trigger.

WordPress trackbacks are another reason to pay attention.

If you don’t use them, disabling them removes one unnecessary input path.

It won’t magically make an old plugin safe.

But reducing attack surface is preferable to leaving obsolete functionality exposed for no reason.

There is also a broader lesson here.

Backup software has become infrastructure.

It is no longer “just a plugin.”

When something has permission to read your entire WordPress installation, write files and restore databases, compromising it can be equivalent to compromising the site itself.

That’s why a backup plugin vulnerability can be more dangerous than a much higher-profile bug in a less privileged component.

The backup is supposed to be your recovery mechanism.

If the attacker controls the recovery mechanism, the emergency exit becomes another entrance.

Bugstoday’s take: Three million-plus vulnerable WordPress sites is the number that should make administrators uncomfortable. CVE-2026-19949 is nasty because the attack doesn’t necessarily look like an attack when it starts. Someone plants the payload, waits for the administrator to perform a perfectly normal restore, and lets the backup machinery finish the job. If you’re running this plugin on 7.109 or earlier, update it. Then ask the more important question: was somebody already waiting inside?

Today’s Bugs. Tomorrow’s Breaches.