Critical WordPress vulnerability exposes 3.2 million sites to remote code execution via All-in-One WP Migration

A high-severity second-order SQL injection flaw (CVE-2026-19949) allows unauthenticated attackers to bypass import security and deploy malicious payloads.

ServMask’s All-in-One WP Migration and Backup is a staple in the WordPress ecosystem, with over 5 million active installations. A critical vulnerability tracked as CVE-2026-19949 has left approximately 3.2 million sites exposed to unauthenticated remote code execution (RCE). The flaw, which carries a CVSS score of 8.8, exploits a second-order SQL injection in the plugin’s archive restore functionality.

The plugin’s developers released a patch in version 7.110 on August 20, 2026, but adoption remains dangerously low. As of early September 2026, WordPress telemetry shows only 35% of installations have updated, leaving millions of production sites, e-commerce stores, and enterprise portals open to full server compromise.

What is a second-order SQL injection?

Most SQL injection (SQLi) attacks are “first-order”: malicious input is submitted and immediately executed by the database. CVE-2026-19949 is a second-order SQL injection, where the payload is written to the database and sits there harmlessly as ordinary data. It only triggers later, during a separate process entirely, in this case when a site administrator runs a backup restore or site migration.

That delay is what makes the flaw so dangerous. An attacker can plant the payload weeks or months before the site is migrated, which makes the eventual compromise nearly impossible to trace back to the original entry point using standard access logs.

The exploit chain

To understand how an unauthenticated attacker gets full server control, you have to look at how WordPress core and the plugin’s internal database-rewriting logic interact. The exploit chain runs in four stages.

weaponizing WordPress trackbacks

The initial entry point isn’t the plugin at all. Instead, the attacker submits two separate trackbacks to a public post on the target site, using WordPress core’s trackback functionality, which is unauthenticated by default.

In these trackbacks, the “blog name” field is deliberately terminated with a trailing backslash (\), and the URL field carries a carefully crafted payload. WordPress core accepts this input and stores it in the wp_comments table as the comment author and author URL, without stripping the backslash or rejecting the malformed URL. At this stage, the payload is completely inert.

the regex flaw and string boundary confusion

The vulnerability activates when a site administrator uses the plugin to export the site and later imports (restores) that .wpress archive. During import, the plugin has to rewrite URLs and database table prefixes to match the new environment, which it does with the replace_table_values() function in the Ai1wm_Database class.

That function relies on a regular expression to find and replace quoted string literals in the SQL dump. The bug is in the negative lookbehind assertion used to detect an unescaped closing single quote: it only checks the single byte immediately before the quote. If an attacker sets up a closing quote preceded by an even number of backslashes (e.g., \\'), the regex misreads the boundary.

Because the exporter correctly doubles the attacker’s trailing backslash during the backup phase, the regex treats the sequence as an escaped quote and keeps matching into the next literal. That boundary confusion breaks the unescape-replace-re-escape cycle and produces an unbalanced sequence of backslashes, promoting the attacker-controlled data from a harmless string literal in the SQL dump into executable SQL code during the restore.

extracting the secret key

A dynamically generated secret key (ai1wm_secret_key), saved to the WordPress options table during each database restore pass, protects the plugin’s unauthenticated import feature. The attacker’s payload is built specifically to steal it.

The two planted trackbacks work together to manipulate the database transaction state. The first payload is computationally heavy enough to exceed the import pipeline’s time budget, which forces the restore process to pause, commit its current transaction, and record its position for the next pass. Because the plugin refreshes the destination site’s ai1wm_secret_key at each pass boundary, the real key is now sitting in the database. The second payload runs an SQL query that reads that key from the options table and writes it into a new, approved comment.

Because the comment is marked as approved, the attacker can retrieve the leaked secret key through the standard, unauthenticated WordPress REST API (/wp-json/wp/v2/comments).

deploying the must-use (MU) plugin

With the secret key in hand, the attacker bypasses the import authentication gate and forces the plugin to import a custom-crafted .wpress archive of their own design.

This malicious archive contains a must-use plugin (mu-plugin). Unlike standard WordPress plugins, which live in /wp-content/plugins/ and can be deactivated from the dashboard, mu-plugins live in /wp-content/mu-plugins/ and are loaded automatically by WordPress core on every page request. They can’t be disabled through the admin interface. Once the malicious mu-plugin is extracted during the fake import, it runs on the next page load and gives the attacker full remote code execution (RCE) and complete control of the server.

The danger of dormant backups

This vulnerability points to a severe risk built into backup and migration tools: they operate with the highest level of database privileges. A flaw in the restoration logic gives an attacker a backdoor to overwrite the entire application state.

Security researchers at Defiant and Wordfence say RCE vulnerabilities of this severity inevitably lead to webshells, ransomware, or the compromised server being folded into a larger botnet. Because the initial trackback injection needs no authentication and leaves virtually no footprint in standard access logs, site administrators are unlikely to notice the breach until the site is actively migrated or restored.

Remediation and mitigation

If your site uses All-in-One WP Migration and Backup, you need to act now to secure your environment.

1. Update immediately: Update the plugin to version 7.110 or higher. The developers patched the regex boundary flaw and improved input sanitization in the restore sequence.
2. Audit existing .wpress files: If you have offline .wpress backups created before August 20, 2026, treat them as potentially compromised. Don’t import these archives into a production environment without first scanning the extracted database dump for anomalous entries in the wp_comments table.
3. Disable trackbacks and pingbacks: Trackbacks are a legacy WordPress feature, rarely used in modern web publishing but frequently abused as a spam and injection vector. Go to Settings > Discussion in your WordPress dashboard and uncheck “Attempt to notify any blogs linked to from the article” and “Allow link notifications from other blogs (pingbacks and trackbacks).”
4. Implement WAF rules: If you use a Web Application Firewall (WAF) like Cloudflare, Wordfence, or Sucuri, make sure your ruleset is up to date. Most enterprise WAFs have already deployed virtual patches to block malicious trackback payloads targeting CVE-2026-19949.
5. Audit user roles and files: As a general precaution after an incident, review your /wp-content/mu-plugins/ directory. If you find unrecognized PHP files there, assume the site is compromised and start a full forensic cleanup.

Final thoughts

CVE-2026-19949 shows how a minor logic error, in this case a poorly constructed regular expression, can cascade into a catastrophic, unauthenticated server takeover. Backup plugins are essential for disaster recovery, but they also significantly expand a WordPress site’s attack surface. Patch management and disabling legacy features like trackbacks remain the most effective defenses against second-order injection attacks like this one.