A high-severity vulnerability in the widely used All-in-One WP Migration and Backup plugin demonstrates how software intended to protect and recover websites can itself become a path to complete compromise. 

The vulnerability, tracked as CVE-2026-19949, affects All-in-One WP Migration and Backup versions up to and including 7.109. The plugin has more than five million active installations, making the potential exposure substantial. The flaw was reported by researcher Jack Taylor through Wordfence and was fixed by ServMask in version 7.110.

The vulnerability is particularly interesting because it is a second-order SQL injection.

Unlike a conventional SQL injection where malicious input is submitted and immediately executed by the database, second-order injection allows attacker-controlled data to be stored first and processed later by another application function.

In this case, an unauthenticated attacker can introduce specially crafted data through WordPress trackbacks. The malicious content may initially remain harmless inside the database.

The vulnerability is triggered later when an administrator performs a normal backup restoration or migration operation using the plugin. During that process, the plugin rewrites database content and incorrectly handles escaped backslashes and quotation marks, allowing previously stored attacker-controlled data to cross SQL string boundaries and execute as part of a database query.

This delayed execution makes the vulnerability more difficult to understand and potentially more difficult to detect.

The attacker does not necessarily need to be present when exploitation occurs.

They can plant the payload and wait.

The administrator eventually performs what appears to be a legitimate maintenance operation, and that trusted administrative activity becomes the trigger for the attack.

That is an important distinction for defenders because conventional monitoring may focus heavily on suspicious requests immediately preceding an intrusion. In a second-order injection scenario, the initial malicious request and the eventual compromise may be separated by hours, days or potentially much longer.

The attack also demonstrates how one vulnerability can be transformed into a much more serious exploit chain.

According to the reported research, SQL injection can be used to expose the plugin's secret import key, `ai1wm_secret_key`. The attacker can cause that secret to become available through publicly accessible WordPress content and then use the recovered key to import a malicious `.wpress` archive.

That archive can contain executable content.

The result is a progression from unauthenticated input injection to database manipulation, secret disclosure, malicious backup import and eventually remote code execution.

At that point, the attacker may be able to take complete control of the affected WordPress website.

This is why vulnerabilities should not always be evaluated solely according to the first primitive they provide.

Calling CVE-2026-19949 an "SQL injection vulnerability" is technically correct, but it does not fully describe the operational impact.

The real attack path is closer to:

Unauthenticated input → stored malicious data → administrator-triggered SQL injection → secret disclosure → malicious archive import → remote code execution → website takeover.

Seen in that context, the risk becomes substantially clearer.

The role of the vulnerable plugin also makes this incident especially important.

Backup and migration plugins frequently have extremely powerful access to a WordPress installation.

They may interact with the entire database, filesystem, themes, plugins, media directories and configuration data. They also need functionality capable of restoring or replacing large portions of the application.

These capabilities are necessary for backup and recovery, but they also mean that compromise of the backup mechanism can effectively provide compromise of the entire site.

Backup software should therefore be regarded as privileged security infrastructure rather than a routine WordPress utility.

The same principle applies beyond WordPress.

Enterprise backup servers, hypervisor backup systems, database recovery tools, cloud backup platforms and disaster-recovery infrastructure routinely possess privileged access to extremely large portions of an organization's environment.

Attackers understand this.

Compromising the system responsible for recovering everything can sometimes be considerably more valuable than attacking individual systems one at a time.

There is another unusual aspect of CVE-2026-19949: successful exploitation depends on an administrator performing a backup restore or migration.

At first glance, this might appear to reduce the severity considerably.

But backup restoration and migration are precisely what the plugin is designed to perform. These are not obscure administrative functions that may never be used.

The vulnerability essentially converts a normal administrator action into the final stage of the exploit.

That makes it a useful example of why "user interaction required" or "administrator action required" should not automatically be interpreted as low risk.

The relevant question is whether the required action is unusual.

If exploitation requires an administrator to execute an unknown binary received through email, the likelihood may be relatively low.

If exploitation requires an administrator to perform the normal function for which the product exists, the situation is very different.

The scale of exposure also deserves attention.

At the time of reporting, only approximately 35% of users had upgraded to the fixed release, leaving roughly 3.25 million WordPress installations potentially running vulnerable versions.

That number illustrates one of the persistent security problems in the WordPress ecosystem.

A vulnerability does not necessarily require exotic exploitation techniques to become attractive to attackers. A sufficiently large installed base can make automated scanning and exploitation economically worthwhile.

Attackers can scan enormous portions of the internet looking for vulnerable WordPress installations and selectively exploit those meeting the required conditions.

Organizations running the All-in-One WP Migration and Backup plugin should therefore upgrade to version 7.110 or later immediately.

But patching alone should not be the entire response.

Administrators should determine whether the site was running an affected version and whether trackbacks or other externally supplied data were received while the system was vulnerable.

They should also review WordPress access logs, application logs and database activity for suspicious requests or unexpected comment and trackback activity.

Any unexplained exposure or modification of the `ai1wm_secret_key` should receive immediate investigation.

Administrators should additionally inspect the site for recently introduced PHP files, unfamiliar plugins, modified themes, unexpected administrator accounts, new scheduled tasks and other persistence mechanisms commonly associated with WordPress compromise.

Backup archives themselves should also be reviewed.

An unexpected `.wpress` archive or an import that cannot be associated with a legitimate administrator action should be considered suspicious.

Organizations should also avoid treating backups stored on the same web server as a complete recovery strategy.

If an attacker achieves remote code execution on the site, locally accessible backup archives may also be modified, deleted or replaced.

A stronger architecture maintains separate, protected backup copies outside the security boundary of the production WordPress server.

This vulnerability also provides another argument for reducing unnecessary WordPress functionality.

If a migration or backup plugin is only required occasionally, organizations should consider whether it needs to remain active continuously on an internet-facing production site.

Disabling unused plugins reduces attack surface, although administrators should remember that an outdated plugin can become vulnerable again if it is later reactivated without first being updated.

Removing software that is no longer required is generally preferable to simply leaving it disabled indefinitely.

For larger organizations running many WordPress installations, plugin inventory becomes particularly important.

Security teams should be able to answer basic questions quickly:

Which sites are using All-in-One WP Migration?

Which versions are installed?

Which installations are internet-facing?

Which systems were vulnerable during the exposure period?

Without centralized asset and software inventory, answering these questions during a vulnerability disclosure becomes unnecessarily difficult.

CVE-2026-19949 ultimately demonstrates a broader security lesson.

Backup systems deserve the same, and sometimes greater, security scrutiny as the systems they protect.

A backup plugin capable of restoring an entire website necessarily possesses capabilities powerful enough to modify that website extensively.

When attackers find a way to abuse those capabilities, the recovery mechanism itself becomes the intrusion mechanism.

The uncomfortable irony is that the tool administrators rely on when a website is compromised can, in this case, become the reason the website gets compromised in the first place.

An SQL injection vulnerability in the All-in-One WP Migration and Backup plugin for WordPress could allow unauthenticated attackers to execute remote code and take control of affected websites. [...]

Source: WordPress backup plugin flaw exposes millions of sites to takeover attacks via Bleeping Computer — published 02 Sep 2026.