Second-order injection lives in the gap between two code paths. The write path escapes the value and stores it whole, which is correct for that one query. A later read path pulls the row back and composes a fresh statement around it, and the escaping that was valid the first time means nothing the second. Here the composing step is the plugin's own rewrite of URLs and table prefixes during an archive operation [4]. The stored bytes stay identical throughout. What changes is the context that surrounds them when they are read back.
Migration code is structurally prone to this shape. A restore has to walk the whole content set and substitute old domains and table prefixes, so by design it reads attacker-supplied text out of the database and puts it back into SQL [4]. Trackbacks make a convenient delivery channel for the same reason they are a nuisance: they accept text from strangers and store it [3].
The writeup lists four conditions for the chain to complete: a 7.109-or-earlier install still active, a public input path that stores the payload, an administrator archive operation over that data, and reachability of the import endpoint with the leaked key [12]. Three of those conditions sit outside the defender's control. The fourth is the one action the site's own team performs [16]. This entire sequence completes without needing any further contact with the target [7].
BleepingComputer's headline puts the population at millions of sites [15]. The material I have carries no install count, so that is their estimate of the affected population rather than a measurement of yours [19]. For it to describe your site, the plugin has to be active at 7.109 or earlier, a public field has to still write unfiltered text into the database, and someone with admin rights has to run an export, import, or restore over it [12]. The remediation is the immediate next patch release, 7.110 [17], which is about as cheap as fixes get. The harder line in the same advice is removing unused old or disabled copies, because deactivating a plugin leaves its files where they are [2].
The detection chain has three stages and only the middle one is loud: abnormal SQL queries during restore, with ai1wm_secret_key surfacing in public comments [10], followed by a .wpress import from an unknown source and then new PHP files and child processes spawned by the web process [11]. The writeup also names a triage state worth borrowing, where crafted public inputs are confirmed but no restore has yet run and success is unconfirmed [18]. That is the state where cleanup is still cheap. It exists only in the window before the archive operation runs. After that, the stated impact list runs through database reads, key leakage, arbitrary code execution, and onward attacks on visitors [14].
