Second-Order SQL Injection in WordPress Backup Plugin: 3.25M Sites Still Exposed

As reported by BleepingComputer, a high-severity second-order SQL injection vulnerability (CVE-2026-19949) in the All-in-One WP Migration and Backup plugin exposes over three million WordPress sites to potential remote code execution and complete takeover. The flaw, discovered by researcher Jack Taylor and disclosed through Wordfence, affects plugin versions through 7.109 and has been patched by vendor ServMask — yet approximately 65% of the plugin's five-million-plus user base remains unpatched as of this writing.

Why Second-Order SQL Injection Demands Attention

This vulnerability class is particularly insidious because it defeats conventional detection logic. The attacker's payload isn't executed at injection time — it's stored benignly in the database and only triggers when a downstream operation processes it incorrectly. In this case, the malformed data is planted via WordPress trackbacks and only executes when an administrator performs an export/import cycle, which is the core function of the plugin.

Second-order injection exploits the trust boundary between data storage and data consumption. WAF rules and input validation at the entry point often miss it entirely because the initial payload may look innocuous.

Defenders should understand that this means traditional perimeter controls — including many WordPress firewalls — would not have blocked the initial planting of the payload. The attack surface is the WordPress trackback endpoint, which is enabled by default on many installations and accessible to unauthenticated users.

Vulnerability Details

Who Is Most at Risk

Immediate Actions

1. Update the plugin immediately to the latest version from WordPress.org or your plugin management dashboard. This is the single most effective mitigation.
2. Disable trackbacks and pingbacks in WordPress Settings → Discussion. This closes the injection vector even if you cannot patch right away.
3. Audit recent trackbacks/pingbacks in your database. Look for entries in the wp_comments table with comment_type of trackback or pingback containing unusual SQL syntax, backslash sequences, or references to ai1wm_secret_key.
4. Rotate the plugin's import secret key if you suspect any prior exposure. The key is stored in the WordPress options table.
5. Avoid import operations from untrusted or unverified .wpress archives until patched.

Shield53 Recommendations

• Treat plugin updates as critical infrastructure maintenance, not optional housekeeping. The 65% unpatched rate here reflects a systemic WordPress ecosystem problem — establish automated update pipelines or managed patching services for essential plugins.
• Implement file integrity monitoring on WordPress core, plugin, and theme files. RCE via plugin compromise often results in webshell deployment that FIM can catch quickly.
• Restrict write permissions on the web root where feasible. If the web server process cannot write to plugin directories, post-exploitation persistence becomes significantly harder.
• Deploy WAF rules with WordPress-specific signatures — while WAFs may not catch the initial second-order injection, they can detect the exfiltration of the secret key via comment output and block malicious archive import attempts.
• For enterprise WordPress deployments, consider migrating to managed hosting platforms that enforce plugin version compliance and provide virtual patching at the edge.

The broader lesson here extends beyond a single plugin. The WordPress ecosystem's reliance on millions of independently maintained plugins — many from small vendors — creates an attack surface that no single security control can fully address. Organizations running WordPress at scale need inventory discipline, automated patching, and defense-in-depth controls that assume any given plugin may eventually disclose a critical flaw. The three million unpatched installations are not a statistic; they are a countdown timer.