Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability

1. Executive summary

A high-severity second-order SQL injection vulnerability, CVE-2026-19949 (CVSS 8.8, HIGH; not currently listed in CISA KEV, EPSS ~1%), in the All-in-One WP Migration and Backup WordPress plugin allows an unauthenticated attacker to achieve remote code execution on affected sites. The flaw affects all plugin versions up to and including 7.109 and was patched in version 7.110, released 20 August 2026. As of 3 September 2026, only 35% of the plugin's 5+ million active installations have been updated, leaving roughly 3.2 million sites — including WordPress-based marketing sites, portals and microsites operated by EMEA financial institutions — running a vulnerable version. Successful exploitation yields full site compromise via a malicious must-use plugin, with webshell deployment a realistic follow-on. No exploitation in the wild is reported in the source material, and the vulnerability is not in CISA KEV; exposure should be treated as high-likelihood-of-exploitation rather than confirmed-under-attack.

2. Regulatory framing

No DORA Art. 19 major-incident reporting trigger is evidenced: the source reports no exploitation against any client environment, only vulnerability exposure.

3. Technical analysis & attack chain

Vulnerability mechanism. CVE-2026-19949 is a second-order SQL injection in the archive restore (import) functionality of All-in-One WP Migration and Backup. Root cause: user-supplied input is insufficiently escaped and existing SQL queries are not sufficiently prepared (NVD classifies the flaw as CWE-89, SQL Injection). The plugin packages sites into .wpress archives and allows administrators to restore the archive on any destination server. The import operation is unauthenticated but protected by a secret key that is saved during each database-restore pass. The attack extracts that secret key, defeating the only control on the unauthenticated import.

Confirmed attack chain (per Defiant's disclosure)

1. The unauthenticated attacker submits two trackbacks to a public post on the target site, via WordPress core's trackback functionality. Each trackback carries a trailing backslash and a URL leading to a payload.
2. The input is stored without backslashes being stripped and without the URLs being rejected.
3. An administrator archives the site and then imports it (restore). During import, the plugin rewrites URLs and table prefixes in the stored SQL.
4. The attacker-supplied input is promoted to executable SQL during this rewrite. The injected SQL causes the secret key value to be written to a comment that is approved and becomes publicly visible.
5. The attacker retrieves the secret key from the site's comments REST API endpoint.
6. Using the key, the attacker imports a crafted .wpress archive containing a malicious must-use plugin via the unauthenticated import operation.
7. The must-use plugin executes on the next page load, yielding remote code execution. Defiant notes this can lead to complete site compromise through webshells and other techniques.

Key characteristics for defenders

• Initial access vector: unauthenticated, via WordPress trackbacks (XML-RPC-adjacent core functionality) plus the plugin's import endpoint. No credentials or user session required.
• Exploitation precondition: an administrator must perform an archive-then-import (restore) cycle on content containing the attacker's stored trackback input. This is a second-order flaw — the malicious input lies dormant until a legitimate restore operation executes it. Sites that never run a restore are not directly exploitable through this chain, but the plugin is a backup/restore tool, so restores are its core use case.
• Impact: RCE as the web server user, via a must-use plugin (wp-content/mu-plugins/), which auto-executes and is not listed in the standard plugin admin UI — a persistence location defenders should inspect.
• Affected versions: all versions up to and including 7.109. Fixed in: 7.110, released 20 August 2026.
• Exposure: ~3.2 million of 5+ million active installs remain unpatched as of 3 September 2026 (WordPress.org plugin data, as reported by SecurityWeek).

Confidence caveat. The full technical chain above is single-sourced — it derives from Defiant's disclosure as reported by SecurityWeek. No second vendor, CERT, or exploit write-up corroborating the trackback-to-key-extraction chain is present in the provided material. No exploitation in the wild, no threat-actor attribution, and no IOCs are reported. Treat the mechanism as high-plausibility but single-sourced; verify against Defiant's original advisory before using it to drive enforcement actions (e.g., emergency trackback disablement across estates).

4. Mitigation & containment

P1 — within 24 hours

1. Inventory and patch. Identify all WordPress assets running All-in-One WP Migration and Backup ≤ 7.109 and update to 7.110 (released 20 August 2026). This is the vendor fix. Prioritise internet-facing sites.
2. If patching cannot complete in 24h: disable the trackback functionality on affected WordPress sites (Settings → Discussion → uncheck "Allow link notifications from other blogs (pingbacks and trackbacks)"), or block trackback requests at the WAF. This breaks step 1 of the chain (the injection vector) even on unpatched sites.
3. Freeze restore operations. Do not run archive-then-import restores on any site running ≤ 7.109 until patched. The second-order payload only fires during a restore.

P2 — within 72 hours

4. Hunt for prior compromise on any site that has performed a restore while running a vulnerable version and had trackbacks enabled: - Inspect wp-content/mu-plugins/ for unexpected must-use plugin files (the RCE delivery location in this chain). - Review approved comments for anomalous content, and audit the comments REST API endpoint (/wp-json/wp/v2/comments) access logs for unauthenticated retrieval patterns. - Check for unexpected .wpress archive imports in plugin logs and for webshells in wp-content/.
5. Restrict the import endpoint at the WAF/CDN layer for unauthenticated traffic where the plugin is installed but restores are performed only by internal staff (e.g., IP-allowlist the import path).

P3 — within 7 days

6. Estate-wide version verification. Confirm 100% rollout of 7.110 across all WordPress properties, including those managed by third-party agencies — the 35% patch rate indicates agency-managed estates are the likely laggards.
7. Add the plugin to continuous monitoring so future version drift is detected, and validate that backup/restore tooling on internet-facing CMS assets is covered by patch SLAs.

5. Indicators of compromise

No indicators of compromise available in the source material. No malicious domains, IPs, hashes, or exploit artefacts are reported; the vulnerability disclosure contains no observed-exploitation IOCs.

Behavioural indicators (derived from the disclosed attack chain; no atomic IOCs exist in the source):

6. Detection

The source material provides no file hashes, malware strings, command-line artefacts, or hard-coded values from an actual exploit or malicious payload — the disclosure describes a vulnerability mechanism, not a deployed threat sample. CVE identifiers, the plugin name, and vendor headline phrases are not threat artefacts and cannot support a detection rule. Insufficient indicators to author detection rules.

For behavioural coverage, implement the P2 hunting steps in §4 (mu-plugins directory monitoring, comments REST API access review, trackback request inspection) as custom log analytics.

CVE assessment

1 referenced CVE

7. Sources

• SecurityWeek, "Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability," https://www.securityweek.com/over-3-million-wordpress-sites-affected-by-migration-plugin-vulnerability/, 3 September 2026 (reporting disclosure by Defiant)

8. Adverse Trace position

CVE-2026-19949 is a high-severity (CVSS 8.8, HIGH) unauthenticated RCE path in one of the most widely deployed WordPress plugins, and the 3.2-million-unpatched figure two weeks after the fix makes mass scanning and opportunistic exploitation likely even though the flaw is not yet in CISA KEV and no in-the-wild exploitation is reported. For EMEA financial services, the direct risk is concentrated in WordPress-based marketing sites, customer portals and microsites rather than core banking systems, but RCE on a customer-facing domain supports defacement, malicious script injection against visitors, and phishing infrastructure abuse — reputational and indirect data-exposure consequences that still matter. The full attack chain is single-sourced (Defiant via SecurityWeek); we will monitor for independent corroboration, KEV listing, and first exploitation reports, and will reissue this advisory if exploitation is confirmed or IOCs emerge. Clients should treat patching to 7.110 and the mu-plugins hunt as immediate actions.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.