The redesign kicks off in February. The new agency does what every agency does on day one: exports the current site to an archive so they have something to work from. The export runs, the import runs, and somewhere in that process a line of SQL that a stranger left in your database last September finally executes.
Nobody attacked you in February. You were attacked in September, and February is only when it went off.
Where this comes from. Everything below is from the Wordfence vulnerability entry for CVE-2026-19949, read directly, and from the reporting at BleepingComputer and SecurityWeek. Where the sources disagree with each other, or with the louder coverage, we say which one we are following and why.
What Was Found
Jack Taylor reported a second-order SQL injection in All-in-One WP Migration and Backup, the most widely installed migration plugin in the WordPress ecosystem. ServMask patched it in version 7.110 on August 20, 2026, five days after the report. Wordfence scores it 8.8, high rather than critical, and tracks it as CVE-2026-19949. Everything up to and including 7.109 is affected.
The number that makes this worth your time. Wordfence puts the plugin above five million active installations and estimates roughly 3.25 million sites were still running a vulnerable version at the point the reporting picked it up. That is about sixty-five percent of the install base, two weeks after a patch existed.
One detail worth reading carefully. The published vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Wordfence titles the entry unauthenticated, and the first step genuinely is. But the vector says PR:L, privileges required low, because the chain does not complete on its own. Somebody with access to your site has to run a migration. A stranger arms it. Your own administrator, or your own agency, fires it.
The Chain, in Order
The mechanism matters here more than the score, because it determines what you should check and when:
- Someone submits a trackback to a public post. No login, no interaction from you. The payload uses trailing backslashes and sits in the comments table looking like ordinary spam.
- It waits. It is inert. There is nothing to notice, no error, no alert, no change to any file on the server.
- An administrator exports the site and imports the archive. The plugin rewrites SQL during the restore without sanitizing what it finds, which promotes the attacker's text from data into an instruction.
- The injected SQL writes the plugin's secret import key, ai1wm_secret_key, into a public comment. It is published where anyone can read it.
- The attacker collects the key through the REST API and imports their own archive. With the key, the import endpoint accepts a crafted archive containing a must-use plugin, and that is remote code execution on your site.
Read that sequence and the timing problem falls out of it. Every published account of the chain agrees on those five steps. What none of them show is anyone actually running it.
What Is Actually Known About Exploitation
This needs saying plainly, because the coverage split and one outlet went further than its own sources. BleepingComputer reports a proof of concept and no evidence of exploitation in the wild. SecurityWeek reports no active exploitation. A September 3 headline elsewhere asserted that exploit code is active, which is a stronger claim than anything underneath it supports.
Here is the check that settles it. The Wordfence entry for this vulnerability carries no blocked-attack counter at all. Their pages show one when attempts are being seen. Compare the Gravity Forms flaw we wrote about last week, where the same kind of page reported six blocked attempts inside twenty-four hours. Here there is nothing, which is the strongest available evidence that nobody is running this yet.
That is genuinely reassuring about today and says nothing about February. Nobody is running it yet is not the same as nobody has planted it. Planting is cheap, silent, and indistinguishable from comment spam. The detonation is what is missing, and detonation is scheduled by you.
Why Updating Is Not the Whole Job
Updating to 7.110 closes the door. It does not remove anything that already walked through it, because the payload lives in your database rather than in the plugin's files. A site that has never been migrated is still carrying whatever was planted, and will carry it until either the row is removed or the site is migrated by a patched version of the plugin.
This is the same shape as the supply chain compromise we covered in August, where the files on disk were untouched and the problem was elsewhere. Version checks answer the question of whether you can be poisoned again. They do not answer whether you already were.
The sixty-five percent is worth sitting with. Sixty-five percent of installs still unpatched two weeks after a fix exists is not carelessness. It is what happens to a category of plugin that gets installed to do one job and then left where it landed. Nobody thinks of a migration tool as running software, because it only runs when somebody asks it to. It sits there, dormant, invisible in exactly the way the plugin that renders your homepage is not.
That is also why the exposure lasts. A plugin nobody looks at does not get updated on the day the advisory lands, and does not get removed when the migration it was installed for finished three years ago. The most common version of this on an association site is not a vulnerable plugin in active use. It is a vulnerable plugin nobody remembers installing.
What to Check
Three checks, in order of how long they take:
- The plugin version. If it is 7.109 or below, that is the priority for the day. If the plugin is installed but unused, and many sites have it sitting there from a migration years ago, deactivating and deleting it is a better answer than updating it.
- Whether trackbacks and pingbacks are enabled. Most association sites have no reason to accept them, and turning them off removes the delivery mechanism for this and for a long tail of other things. This is a two-minute setting in Discussion options.
- What is actually in wp_comments. You are looking for comment rows that are not comments. If your site ran a vulnerable version and accepted trackbacks, this is the check that tells you whether you are carrying something, and it is the one that needs someone who can read the database rather than the dashboard.
- Whether anyone has exported and imported this site since August. If the answer is yes and the site was on 7.109 or earlier at the time, the migration already happened and the key may already be public. That moves this from housekeeping to incident response.
The Part That Belongs in Your Next Redesign Contract
Re-platforming is the largest engagement most associations buy from an agency, and the agency is the party who runs the export. That makes your vendor the trigger, whether or not either of you knows it.
It is reasonable to ask, in writing, what a prospective agency does about the database before they migrate it. Not the files, which everyone checks, and not the SEO redirects, which everyone sells. The database. If the answer is a blank look, that is useful information about how the rest of the project will go, and it costs nothing to ask during procurement rather than during an incident.
Have Us Look Before Anyone Migrates It
Ten minutes of database work costs less than a compromised redesign, and it has to happen before the export rather than after it. Tell us which migration plugin is on the site and we will run the four checks above: the installed version and whether it falls in the affected range, whether trackbacks and pingbacks are still open, whether anything is sitting in the comments table that is not a comment, and whether the site has been exported or imported since August. A clean result is worth having on file before a redesign starts. A dirty one is worth having before somebody else finds it.