WordPress: RCE Vulnerability in All-in-One WP Migration Exposes Approximately 3.2 Million Sites

A high-severity vulnerability in the All-in-One WP Migration and Backup plugin can be exploited to achieve remote code execution on a WordPress site. Tracked as CVE-2026-19949, the issue affects all plugin versions through and including 7.109.

The vulnerability was fixed in version 7.110, released on August 20. However, as of September 3, 2026, only 35% of more than 5 million active installations had been updated. An estimated 3.2 million sites therefore remained exposed.

The flaw affects the restoration process for .wpress archives and stems from a second-order SQL injection. Exploitation combines data stored in the database, WordPress trackbacks, comments accessible through the REST API, and a backup archive crafted to install malicious code.

Vulnerable Versions and Severity of CVE-2026-19949

The scope of affected installations is clearly defined:

• Product: All-in-One WP Migration and Backup for WordPress;
• Vulnerable versions: through and including 7.109;
• Fixed version: 7.110;
• Affected component: the .wpress archive import and restoration functionality.

The NIST NVD entry assigns the vulnerability a CVSS v3 score of 8.8, with the following vector:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

The issue is classified as CWE-89, which covers the improper neutralization of special elements used in an SQL command. The flaw allows additional SQL queries to be appended to operations prepared by the plugin and can expose sensitive information stored in the database.

The CVSS metrics indicate a high impact on confidentiality, integrity, and availability. The attack can be carried out over the network, has low complexity, and does not require user interaction during execution.

However, there is an inconsistency in the classification. The vulnerability description and the analysis by Defiant, the company that reported the issue, describe a scenario accessible to an unauthenticated attacker. The CVSS vector instead includes PR:L, indicating that low-level privileges are required. No definitive clarification of this discrepancy is currently available.

Why This Is a “Second-Order” SQL Injection

In a traditional SQL injection, malicious input reaches a vulnerable query directly and is executed within the same request flow. In this case, the attack path is more complex.

The attacker initially submits manipulated data that WordPress stores without immediately turning it into a dangerous query. The input remains in the database and becomes executable only later, when the plugin processes the data while creating and restoring an archive.

This is why the flaw is described as a second-order SQL injection: the payload is stored during an initial stage and activated later within a separate application process.

All-in-One WP Migration compresses a site's content, configuration, and database into files with the .wpress extension. During import, the plugin must adapt URLs and table prefixes to the destination server. This rewriting of stored SQL code is what turns attacker-controlled input into executable statements.

The issue results from insufficient escaping of an externally controllable parameter and inadequate preparation of an existing SQL query. The attack therefore does not simply involve uploading a backup; it exploits the way the plugin reconstructs the database.

From Trackbacks to the Plugin’s Secret Key

The chain described by Defiant begins with the submission of two trackbacks to a public WordPress post. Each trackback contains a trailing backslash and a URL associated with the payload.

These values are stored without removing the backslashes or blocking the URLs. The code initially remains inactive. To complete the SQL injection stage, an administrator must create an archive and subsequently import it.

During restoration, the plugin modifies the URLs and table prefixes contained in the SQL dump. This operation also processes the content inserted into the trackbacks, turning it into valid SQL.

The resulting query copies the value of ai1wm_secret_key into a comment. This key is used to protect the various stages of the import process. The comment is then approved and becomes publicly visible.

The attacker can then retrieve the key without authentication through the comments REST API endpoint. The stolen secret allows the attacker to bypass the check performed by the import process, which does not rely on WordPress’s standard administrative authentication.

The vulnerability therefore depends on the interaction between multiple components: core trackbacks, the database, the plugin’s restoration process, and the comments REST API.

The .wpress Archive Leads to Code Execution

After obtaining the key, the attacker can import a specially crafted .wpress archive. The file contains a malicious must-use plugin, meaning PHP code that WordPress loads automatically without requiring the standard plugin activation process.

When a page is loaded, the component is executed and the attacker achieves remote code execution. The result can be a complete compromise of the WordPress installation.

Depending on the privileges of the web process, RCE can allow an attacker to install webshells, maintain access to the server, and modify files or configuration settings. It can also expose data stored in the database, enable content tampering, and turn the compromised site into a staging point for further activity.

The attack chain requires multiple steps and includes an administrative backup and restoration operation. This does not eliminate the risk: the payload can remain stored until an administrator performs those specific operations.

Urgent Updates and Installation Checks

The documented remediation is to update to All-in-One WP Migration and Backup 7.110. Any installation running version 7.109 or earlier should be considered vulnerable.

No official temporary mitigation has been documented. In particular, there are no published instructions for neutralizing the flaw solely by modifying trackbacks, the comments REST API endpoint, or .wpress file imports. These changes should therefore not be treated as substitutes for applying the patch.

In addition to checking the installed version, administrators should look for signs consistent with the attack chain described above:

• unusual trackbacks containing unexpected URLs or trailing backslashes;
• comments published or approved without a legitimate operational explanation;
• potential exposure of the ai1wm_secret_key value;
• unrecognized .wpress imports;
• unknown must-use plugins;
• PHP files, webshells, or persistent modifications that cannot be attributed to administrators.

No file names, IP addresses, hashes, or other specific indicators of compromise have been disclosed. Investigations should therefore focus on import history, HTTP logs, comment content, and the directory reserved for must-use plugins.

No Information on CISA KEV Listing or Previous Vendor Issues

There has been no report that CVE-2026-19949 was added to CISA’s Known Exploited Vulnerabilities catalog. As a result, no federal deadline associated with the vulnerability is currently known.

The absence of a reported KEV listing does not prove that the flaw has not been exploited in the wild; it only means that this specific operational confirmation is not available. No information has been provided about active campaigns or large-scale attacks either.

The vendor’s name is not explicitly identified beyond the product name. It is therefore not possible to reliably link this incident to any other recent vendor issues in the KEV catalog.

The most immediate concern remains the scale of exposure: approximately 3.2 million installations were still vulnerable as of September 3. Organizations managing a WordPress site with this plugin should prioritize checking the installed version and deploying 7.110.