- Patchstack found one script delivered through stored XSS flaws in Ninja Forms and WPC Product Bundles. It installs several backdoors, including an administrator hidden from the Users screen.
- Updating the plugin stops new attacks through that flaw. It does not remove backdoors already placed on a site where an administrator triggered the script.
- Update to Ninja Forms 3.15.4 or later, then check the database, not the dashboard, for unknown administrators and for files in the mu-plugins folder.
A security patch closes a door. It does not search the house. Patchstack's analysis of a live WordPress campaign shows why that difference matters on any WordPress site where an administrator may have opened a poisoned form submission or order.
What Patchstack found
Patchstack, a WordPress security firm, saw exploitation attempts against two unrelated plugins. Both involve stored cross-site scripting (XSS). That means an attacker plants a script in data the site saves, and the script runs later in someone's browser. Every attempt pulled the same JavaScript from one domain, imgcdn1.com.
Patchstack's telemetry first caught the payload on October 4, 2026. It was aimed at WPC Product Bundles for WooCommerce, through a flaw tracked as CVE-2026-93836 that affects release 8.6.6 and earlier. On October 5 the identical script showed up through CVE-2026-94504, which affects Ninja Forms 3.15.3 and earlier. BleepingComputer reported on the campaign on October 6.
Patchstack describes exploitation volume as limited so far. It also says two plugins is what it has confirmed, not what it expects the final count to be.
How the attack works
The attacker needs no password. In Ninja Forms, the attacker submits a form through the site's normal public endpoint. The flaw is in the legacy administrative submission editor, which can show the stored text without safe encoding. In WPC Product Bundles, the script sits in WooCommerce order data.
Nothing happens until an administrator opens that submission or order. That is an ordinary part of the job. The script then runs inside the administrator's own logged-in session.
The script does not steal the login cookie. It loads admin pages, copies the security tokens those pages require, and submits the same requests a person would. Patchstack notes that HttpOnly cookies, which block scripts from reading the cookie, do not help. The script never needs to read it.
Through those requests it uploads a plugin disguised as "WP Smart Thumbnails" 1.2.4 from "MediaPress Labs". It also creates an administrator account and reports back to the attacker's server.
Four ways back in
Patchstack lists four independent routes the attacker keeps. The first is a visible administrator account with credentials supplied by the attacker. The second is a hidden administrator, concealed by a must-use plugin. Must-use plugins load on every request. They cannot be switched off in wp-admin and do not appear on the Plugins screen.
The third is a secret login URL. It signs the holder in as the site's oldest administrator, so the visit looks like the real owner. The fourth is a file manager inside the fake plugin. It has no password. It cannot run commands, but it can write files, which is enough to add more access. BleepingComputer, citing the researchers, makes the same point.
Patchstack also found the implant hides well. The hidden files are dated to match the oldest file on the site, so a search for recently changed files finds nothing. Each site gets a different obfuscation key, so no two infected sites share a file hash.
Why the patch is not the finish
The lesson here is that the vulnerability is only the delivery route. The damage is built to outlive it. Removing the vulnerable plugin, or even the fake one, closes none of the last three routes, according to Patchstack.
The attackers also do not appear tied to one plugin. Patchstack says the second stage is the same whatever plugin supplies the XSS, so these attackers collect such flaws and reuse one implant.
Timing matters too. Both flaws were publicly disclosed on September 22. The attack domain was registered on October 1, about ten days later. Patchstack says this fits infrastructure built for the campaign. Its first sighting of the payload came three days after registration.
Note the scope. This applies to a site where the script actually ran in an administrator's browser. Patchstack advises treating such a site as potentially compromised. Updating alone does not clean it, a point BleepingComputer also makes.
Questions to put to your team
First, are Ninja Forms at 3.15.4 or later and WPC Product Bundles at 8.6.7 or later? Second, did any administrator open form submissions or orders on an unpatched version since late September?
Third, has anyone compared the administrators in the database with those shown in the dashboard? Patchstack says an account that appears in one but not the other is hidden. It also flags @wordpress.org emails on local accounts and names like support, updater or maintenance.
Fourth, has anyone inspected the mu-plugins folder and searched logs for the _wplogin parameter? Patchstack advises sorting files by content, not by date. On a site where the script did run, Patchstack's cleanup list starts with deleting unauthorized accounts, plugins and dropped files. It then clears two database options, fz_emer_done_v1 and fz_emer_login_tokens. After that, rotate privileged credentials and WordPress salts. The oldest administrator's password should be treated as compromised.
A patch tells you the hole is closed. Only a search of the site tells you whether anyone is already inside.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Patchstack.
