The All-in-One WP Migration and Backup plugin for WordPress is vulnerable to SQL Injection via archive…

CVE-2026-19949 is a second-order SQL injection in the All-in-One WP Migration and Backup plugin for WordPress, affecting all versions through 7.109 (fixed in 7.110, released August 20, 2026). The flaw lies in incorrect parsing of escaped backslashes and quotation marks during archive restoration. An unauthenticated attacker plants a crafted payload via WordPress trackbacks. That payload sits dormant until an administrator performs an export-then-import cycle — a core function of this migration plugin. When the restore runs, the injected SQL leaks the plugin's ai1wm_secret_key into a public comment. The attacker reads the key, then imports a malicious .wpress archive containing executable PHP, achieving full site takeover. The plugin has over 5 million active installations, and as of early September 2026, only ~35% have updated — leaving an estimated 3.25 million sites still running vulnerable versions.

The vendor score of 8.8 HIGH overstates the real-world risk. The CVSS vector (AV:N/AC:L/PR:L/UI:N) treats this as a straightforward authenticated network attack, but the actual chain is a *second-order* injection that requires (1) trackbacks/pingbacks to be enabled, (2) the admin to perform a migration or backup-restore cycle, and (3) the attacker to monitor public comments for the leaked key and then act on it before it's noticed. Each of these conditions introduces timing friction that CVSS cannot capture. Patchstack independently categorized this as 'low priority, unlikely to be exploited', and the EPSS score of 0.00538 sits well below the 95th percentile. There is no KEV listing and no confirmed in-the-wild exploitation. The 8.8 is a theoretical ceiling; the operational reality is a MEDIUM.

Why this verdict

• Non-deterministic trigger: The entire chain depends on an administrator performing an export+import cycle — a migration event the attacker cannot force. Most WordPress sites perform this operation a handful of times per year at most, creating an exploitation window measured in weeks or months, not hours.
• Compounding prerequisites: Trackbacks must be enabled (many hardened sites disable XML-RPC), comments must be publicly visible (moderation queues break the key leak), and the attacker must be actively monitoring the target — each condition independently narrows the exploitable population.
• No exploitation momentum: Zero KEV listing, no GreyNoise tags, EPSS at 0.00538, and Patchstack independently assessed this as 'low priority, unlikely to be exploited.' The security ecosystem is not treating this as an active threat.
• Role multiplier: WordPress sites are overwhelmingly (b) typical role — public web presence or line-of-business applications. Blast radius of successful exploitation is limited to one site/tenant. WordPress is not canonically a high-value-role component (not an IdP, hypervisor, DC, backup server, or CI/CD system). In rare shared-hosting scenarios, lateral movement to co-hosted sites is possible but requires additional privilege escalation beyond the webshell. No floor override applies.

Why not higher?

Despite 5 million active installations and an RCE end-state, upgrading to HIGH would require either active exploitation evidence, a deterministic trigger the attacker controls, or a high-value deployment role. None of these conditions are met. The second-order nature with an admin-dependent trigger fundamentally limits weaponization at scale — mass exploitation campaigns cannot reliably time the detonation.

Why not lower?

Dropping below MEDIUM would undercount the sheer exposure population (~3.25 million vulnerable sites) and the severity of the end-state (unauthenticated-to-RCE, even if timing-dependent). The full chain IS publicly documented, trackbacks ARE enabled by default in many WordPress installations, and a motivated attacker targeting a specific site could plant the payload and wait patiently. This is not a theoretical-only vulnerability — it is a viable targeted attack vector.

1. Disable XML-RPC and trackbacks — Block or disable /xmlrpc.php entirely via .htaccess, Nginx config, or a security plugin like Wordfence or Disable XML-RPC. This eliminates the unauthenticated injection vector completely. No noisgate mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window, but this control is trivial to deploy immediately.
2. Enable comment moderation for all comments — Set WordPress to hold all comments for manual approval (Settings → Discussion → Comment must be manually approved). This prevents the leaked ai1wm_secret_key from being publicly visible, breaking step 3 of the chain.
3. Update to version 7.110 — The definitive fix. Update via the WordPress plugin repository. Per the noisgate remediation SLA for MEDIUM, complete within 365 days — but given the trivial update mechanism, there's no reason not to do it within your next maintenance window.
4. Restrict plugin import endpoint access — If you don't actively use the migration/import feature, consider deactivating the plugin entirely on production sites. If needed only during migrations, activate it only for the migration window and deactivate afterward.

Run this on each WordPress host (or via SSH across your fleet). Requires read access to the WordPress plugin directory. Example: bash check_cve_2026_19949.sh /var/www/html/wordpress

#!/bin/bash
# CVE-2026-19949 Checker — All-in-One WP Migration and Backup
# Usage: bash check_cve_2026_19949.sh <wordpress_root>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

WP_ROOT="${1:-/var/www/html}"
PLUGIN_FILE="${WP_ROOT}/wp-content/plugins/all-in-one-wp-migration/all-in-one-wp-migration.php"

if [ ! -f "$PLUGIN_FILE" ]; then
  echo "UNKNOWN — All-in-One WP Migration plugin not found at ${PLUGIN_FILE}"
  exit 2
fi

# Extract version from plugin header
VERSION=$(grep -i '^[[:space:]]*\*[[:space:]]*Version:' "$PLUGIN_FILE" | head -1 | sed 's/.*Version:[[:space:]]*//' | tr -d '[:space:]')

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Could not parse plugin version from ${PLUGIN_FILE}"
  exit 2
fi

echo "Detected All-in-One WP Migration version: ${VERSION}"

# Compare versions — vulnerable if <= 7.109
# Split version into major.minor components
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)

if [ "$MAJOR" -lt 7 ] 2>/dev/null; then
  echo "VULNERABLE — Version ${VERSION} is affected by CVE-2026-19949 (fixed in 7.110)"
  exit 1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -le 109 ] 2>/dev/null; then
  echo "VULNERABLE — Version ${VERSION} is affected by CVE-2026-19949 (fixed in 7.110)"
  exit 1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -ge 110 ] 2>/dev/null; then
  echo "PATCHED — Version ${VERSION} is not affected"
  exit 0
elif [ "$MAJOR" -gt 7 ] 2>/dev/null; then
  echo "PATCHED — Version ${VERSION} is not affected"
  exit 0
else
  echo "UNKNOWN — Could not compare version ${VERSION}"
  exit 2
fi

Sources

1. BleepingComputer — WordPress backup plugin flaw exposes millions of sites
2. Patchstack — All-in-One WP Migration SQLi to RCE
3. FreshySites — CVE-2026-19949 Security Bulletin
4. SentinelOne Vulnerability Database — CVE-2026-19949
5. SOCRadar — CVE-2026-19949
6. WPScan — All-in-One WP Migration Plugin Security History
7. WordPress.org — All-in-One WP Migration Plugin Page