Skip to main contentSkip to footer
Security News

CVE-2026-19949: Hive Blocks the All-in-One WP Migration SQLi by Default

Updated Patrick Schlesinger
Security advisory card for CVE-2026-19949 showing the trackback attack chain of the All-in-One WP Migration SQL injection and the ReportedIP Hive firewall defence that blocks it by default

ReportedIP Hive blocks exploitation attempts against CVE-2026-19949 by default: the firewall ships enabled on every plan including Free and inspects the trackback requests this attack rides in on. The vulnerability is an unauthenticated second-order SQL injection in All-in-One WP Migration and Backup up to version 7.109, fixed in 7.110.

If you run the plugin, update to All-in-One WP Migration 7.110 or newer now. The firewall buys you time; the update closes the hole.

How the CVE-2026-19949 attack works

  1. The attacker sends a crafted trackback to the site, no login required. WordPress stores the payload, laced with backslash and quote sequences, as an ordinary comment.
  2. Nothing happens yet. The injection sits dormant in the database, which is why scanners that only watch for immediate errors miss it.
  3. When an administrator later restores a backup, All-in-One WP Migration mishandles the stored data and the SQL injection executes.
  4. The injected SQL can read ai1wm_secret_key (the token that guards the plugin’s import endpoint) and expose it, opening the door to a full site takeover.

Security researcher Jack Taylor reported the flaw through the Wordfence bug bounty programme on August 14, 2026; ServMask shipped the 7.110 patch on August 20, and the advisory went public on September 1. Our sister company has published a German-language breakdown: CVE-2026-19949 at CMS ADMINS.

What Hive blocks out of the box

The Hive Web Application Firewall is enabled by default on every plan, runs in blocking mode (not report-only), and hooks the request pipeline at init priority 1, before WordPress processes a trackback. It inspects the URI, the full POST body and the user-agent of every request, wp-trackback.php included. Sites running the Extended Protection drop-in inspect the request before WordPress even boots.

At the default paranoia level 1, two SQL-injection signatures (waf_sqli_union and waf_sqli_bool) stop the classic payload shapes: UNION-based extraction and boolean logic with comment terminators. Both fire on every plan, including Local Shield installs that never talk to our servers.

A targeted trackback rule, synced today

Second-order injections can be built without the keywords the generic signatures look for. So on September 3 we pushed waf_sqli_trackback_2nd to the synced ruleset. It is scoped to the trackback endpoints (wp-trackback.php and /trackback/ permalinks) and flags both SELECT … FROM fragments and the backslash-quote escape primitive this attack class depends on. Legitimate trackbacks carry neither, so the false-positive surface is close to zero.

The rule is live as free ruleset v6 and professional ruleset v7, Ed25519-signed like every ruleset we publish. Community Network sites pick it up on their next rule sync; Local Shield installs receive it bundled with the next plugin release. One honest limitation: the second stage of this attack, the restore, runs inside PHP with no HTTP request involved, so no firewall can see it. Blocking the ingress vector is containment; the update to 7.110 is the fix.

Harden your site in five minutes

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed