A vulnerability disclosed in one of WordPress’s most widely used backup tools shows how a routine, everyday admin task — restoring a site from a backup archive — can become the final step in a remote takeover, if the plugin handling it isn’t careful about what data it trusts.

The Plugin and the Flaw

The affected software is All-in-One WP Migration and Backup, installed on more than five million active WordPress sites according to the plugin’s own listing. Security researcher Jack Taylor discovered a high-severity, unauthenticated SQL injection vulnerability, now tracked as CVE-2026-19949 with a CVSS score of 8.8, and reported it through the Wordfence Bug Bounty Program on August 14. Taylor received a $5,761 bounty for the find, and the plugin’s developers shipped a fix in version 7.110 on August 20. Any site still running version 7.109 or earlier remains exposed.

A Two-Stage Attack Hidden in a Backup Restore

What makes this flaw notable isn’t just its severity score but its delivery mechanism. Wordfence classified it as a “second-order” SQL injection, meaning the malicious payload isn’t submitted and executed in a single step. Instead, the attack unfolds in stages that quietly wait for a site administrator to take an ordinary action.

First, an attacker submits data through WordPress’s built-in trackback feature — a legacy mechanism that lets one site notify another when it links to it, and one that doesn’t require authentication if a post is configured to accept pings. The attacker embeds specially crafted SQL payloads inside fields like the blog name and URL that get stored as part of the trackback data.

That payload then sits dormant until an administrator exports the site and later restores it — a routine maintenance task, migration, or disaster-recovery step. During the restore process, a defect in how the plugin’s regular expressions handle backslashes and quoted strings allows the previously stored payload to break out of its intended SQL string boundary. As Wordfence explained it, “a flaw in the plugin’s regular expression handling of backslashes and quoted strings can cause the stored payload to escape its intended SQL string boundary.”

From Injection to Full Site Compromise

Once the injected SQL executes during restoration, it can retrieve the plugin’s ai1wm_secret_key — a value the plugin relies on to authorize backup and restore operations. From there, the attack chain gets more creative: the attacker leaks the retrieved key through an approved comment on the site, then pulls it back out via the WordPress REST API. Armed with the secret key, they can upload a malicious .wpress archive file, which the plugin will process as a legitimate backup — handing the attacker a path to arbitrary code execution on the server.

The chain is a useful reminder that “unauthenticated” doesn’t mean “requires no administrator action at all.” Here, the dangerous payload is planted by the attacker but detonated by the site owner’s own routine backup workflow, which is part of what makes it easy to miss during a quick security review.

Why Backup Plugins Deserve Extra Scrutiny

Backup and migration plugins occupy a uniquely privileged position in the WordPress ecosystem: they need broad access to a site’s database and file system to do their job, which also makes any flaw in their handling of untrusted input especially consequential. A plugin installed on five million sites represents an enormous, homogeneous attack surface — exactly the kind of target that draws automated scanning once a proof-of-concept or technical writeup becomes public.

What Site Owners Should Do

• Update All-in-One WP Migration and Backup to version 7.110 or later immediately.
• Review trackback and pingback settings, and consider disabling them on posts that don’t need them, reducing the exposed surface for similar second-order attacks.
• Audit recent comments for unusual or encoded content that could indicate an attempt to exfiltrate a secret key.
• Check for unexpected .wpress files or unfamiliar admin accounts following any recent backup restore operation.
• Apply the general principle of treating any user-supplied or externally submitted data — including trackbacks — as untrusted until it’s been through proper validation, not just at the point of entry but at every point it’s later reused.

Given the plugin’s install base, even a modest percentage of unpatched sites still represents a substantial pool of exploitable targets, making prompt updating the single most effective defense available to site owners right now.