On this page
Ninja Forms (CVE-2026-94504) and WPC Product Bundles for WooCommerce (CVE-2026-93836) had stored XSS bugs that Patchstack saw used from 4 and 5 October 2026 to install a rogue plugin and a hidden administrator. Update to Ninja Forms 3.15.4 or later and WPC Product Bundles 8.6.7 or later. Then check for leftovers, because the update alone does not remove them.
| Fact | Detail | Source |
|---|---|---|
| CVE ids | CVE-2026-94504 (Ninja Forms), CVE-2026-93836 (WPC Product Bundles), both unauthenticated stored XSS | Patchstack |
| Affected versions | Ninja Forms through 3.15.3; WPC Product Bundles through 8.6.6 | Patchstack |
| Fixed versions | Ninja Forms 3.15.4 or later; WPC Product Bundles 8.6.7 | Patchstack; changelogs for Ninja Forms and WPC Product Bundles |
| Severity | Listed CVSS 7.1 for both | Patchstack |
| Install base | More than 500,000 (Ninja Forms), more than 30,000 (WPC Product Bundles) | Patchstack |
| Disclosed | 22 September 2026 | Patchstack |
| First seen exploited | 4 October 2026 (WPC Product Bundles), 5 October 2026 (Ninja Forms) | Patchstack |
| Exploitation status | Active exploitation observed; volume limited in Patchstack's telemetry (vendor-claimed) | Patchstack |
| Later fixes | Ninja Forms 3.15.5 (28 September) and 3.15.6 (15 October) harden stored XSS further. WPC Product Bundles 8.7.3 lists a further stored XSS fix. Install the current release of each, not only the minimum | Ninja Forms changelog, WPC changelog |
| Checked | At our check on 28 October 2026 we read the Patchstack article and both plugin changelogs | this page |
Who is affected?
You are in scope if the site ran Ninja Forms 3.15.3 or older, or WPC Product Bundles 8.6.6 or older, at any point from the 22 September disclosure. Both are WordPress plugins, so sites on other platforms are not affected by these two bugs.
The attack needs a person. Per Patchstack, the stored script only runs when a logged-in administrator opens the affected data: a Ninja Forms submission in the legacy submission editor, or a WooCommerce order that holds the stored value. The attacker does not need an account to put the data there.
Updating is the first step, but it is not the end. The Ninja Forms 3.15.4 changelog lists stronger output escaping on the admin submission edit screen. That does not remove anything an earlier administrator visit already installed, and Patchstack says removing the injected JavaScript alone is not sufficient.
Patchstack also says the implant is plugin-agnostic, so a different stored XSS that reaches an administrator could deliver the same implant. A site that never ran these two plugins should still check for the signs below.
Why is updating not the end of it?
Patchstack's headline finding is that one successful run can leave four separate ways back in:
| Route | What it is | Does removing the plugins close it? |
|---|---|---|
| Visible administrator | A new admin created through the normal user screen | You can see it and delete it |
| Hidden administrator | A second admin, concealed from the Users screen by a must-use plugin | No, per Patchstack |
| Backdoor login URL | A login parameter that signs the holder in as the site's oldest administrator | No, per Patchstack |
| File manager | A file manager that Patchstack says has no authentication of any kind | No, per Patchstack |
Patchstack writes that removing the vulnerable plugin, or even the malicious one, closes none of the last three. Its article also places the file manager in the rogue plugin's own code without reconciling that with this sentence, so we repeat the sentence and give no advice on which files to delete. This is why the plugin changelogs are not the whole story. Both changelogs record a fix without naming the CVE (Ninja Forms 3.15.4 lists output escaping on the admin submission edit screen; WPC Product Bundles 8.6.7 says "Fixed: Vulnerability reported by lhking from Wordfence"). The CVE ids and affected ranges come from Patchstack, so keep its page open when you talk to a developer.
How do I fix it?
If a host or agency manages the site
Send them this exact question and keep the reply:
For [your domain], which versions of Ninja Forms and WPC Product Bundles are installed, and when were they updated to 3.15.4 and 8.6.7 or later? Please also list every user with the administrator role straight from the database, and tell me whether the mu-plugins folder contains any file you did not install.
- Get the installed plugin versions in writing, with the date of the update.
- Get the database list of administrators, not the wp-admin list. How to find and remove a hidden admin has the detail.
- Ask whether the logs show a login using the
_wploginparameter. - Ask that the person doing the work follows the order in the next section.
If you manage the site yourself
Patchstack's response order is to patch first, then investigate, then remove. Treat any site where an administrator opened an affected submission or order as potentially compromised.
- Update Ninja Forms and WPC Product Bundles to their current releases. 3.15.4 and 8.6.7 are the minimum Patchstack names, and both plugins have shipped further XSS fixes since. Take a backup first.
- Search web and access logs for the delivery domain
imgcdn1.comand for requests carrying the_wploginparameter onwp-login.php(Patchstack's indicators). - Look for a
wp-smart-thumbnailsfolder inwp-content/plugins/. Patchstack lists it as the rogue plugin, shown as version 1.2.4 by "MediaPress Labs". - List administrators in the database and compare with the dashboard. Patchstack says to review suspicious names and
@wordpress.orgemail addresses. - Read the files in
wp-content/mu-plugins/by content. Patchstack warns that timestamps were altered, so sorting by date is not enough. - Check the options table for the campaign's state entries named in the Patchstack indicator list.
- Remove unauthorised accounts, plugins and must-use files, then delete the campaign options, as Patchstack's remediation steps describe.
- Rotate privileged credentials and authentication salts. Patchstack says to treat the oldest administrator's password as compromised.
- Review the filesystem and database for other changes. Patchstack says its indicator list is not exhaustive.
Am I affected? A three-state self-test
Am I affected? Where you stand right now
A passive check from outside can read a plugin version when the site exposes one. It cannot see the database, the mu-plugins folder or whether an administrator ever opened a stored submission.
- Detected The site exposes Ninja Forms 3.15.3 or older, or WPC Product Bundles 8.6.6 or older. Update today, then run the checks above. Treat the site as exposed until you have done both.
- Unknown The plugin version is hidden, or the plugins are installed but the version does not show. This is the common case. Look in the plugin list in wp-admin or ask your host. A version at or above the fix does not tell you whether an earlier administrator visit already installed something.
- Confirmed by owner evidence You have the plugin versions from wp-admin or the server, the database list of administrators, and a look inside mu-plugins. That is the evidence to hand your host or developer. It shows which versions are installed and whether the known signs are present, but it does not by itself show that the fix was applied or that nothing else was planted.
No scan, ours included, moves you from "unknown" to "confirmed". A passive result is not proof that nothing was planted.
Was anything exploited, and what should I look for?
Yes, in the sense that Patchstack observed it. It reports first sightings on 4 October (WPC Product Bundles) and 5 October 2026 (Ninja Forms), and says exploitation volume was limited in its own telemetry. It also says that count is not a ceiling. BleepingComputer's report of 6 October summarises the same findings. We found no other primary source naming a compromised site, and we name none. The signs Patchstack lists are:
- an administrator in the database that the Users screen does not show;
- a
wp-smart-thumbnailsplugin you did not install; - unfamiliar files in
wp-content/mu-plugins/; - logins to
wp-login.phpusing the_wploginparameter; - requests to or from
imgcdn1.com.
Patchstack lists more indicators, including source IPs. It says most are Tor exit nodes, so blocking them is not a durable mitigation.
What is the bug, without the exploit?
Per Patchstack, both are stored cross-site scripting. In WPC Product Bundles, an unauthenticated visitor can submit a value in a quantity field that is stored with extra markup and later rendered unsafely when an administrator views the order. In Ninja Forms, an unauthenticated form submission is stored and shown without safe encoding in the legacy administrative submission editor. In both cases, browser script then runs with the administrator's session.
We do not reproduce the script or the steps. You do not need them to fix a site, and Patchstack's article already carries the indicators defenders need.
If the site was already infected, why WordPress malware keeps coming back and how to pick a clean restore point cover the cleanup. Other form plugins have had similar problems, tracked in the form plugin risk list, and more fixes are in the other WordPress guides.
For the wider picture of this month, see the October 2026 security tracker, the small business summary and who is responsible for patching a site.
Questions people ask
Is the Ninja Forms vulnerability being exploited?
Yes, Patchstack reported active exploitation of both plugins in early October 2026, first seen on 4 October (WPC Product Bundles) and 5 October (Ninja Forms). It also said volume was limited in its own telemetry and that its count is not a ceiling. Update the plugins, then check for the signs below.
I updated Ninja Forms. Am I fine now?
The Ninja Forms 3.15.4 changelog lists stronger output escaping on the admin submission edit screen, and the update is the first step. It does not remove anything an earlier administrator visit already installed. Patchstack says removing the plugins closes none of the later access routes, so you still need to check the administrator list in the database and the mu-plugins folder.
How do I find a hidden administrator in WordPress?
The Users screen cannot show it, because the campaign hides the account there. Patchstack says to list administrators straight from the database and compare them with the wp-admin list. Your host or developer can run that query.
Do I need Ninja Forms or WPC Product Bundles installed to be affected by the hidden admin?
Possibly. Patchstack says the post-exploitation stage is plugin-agnostic, so any stored XSS that puts JavaScript in front of a WordPress administrator is a candidate vector for the same implant. The two confirmed entry points are these plugins, but Patchstack says two is what it has confirmed, not what it expects the final count to be. Check for the signs below even if neither plugin was installed.
Should I change passwords after cleaning up?
Patchstack lists rotating privileged credentials and authentication salts in its remediation steps. It also says the oldest administrator's password should be treated as compromised, because the backdoor login URL signs in as that account.
Sources
- Patchstack: Four ways back in, the WordPress XSS campaign that hides its own admin account (6 October 2026)The primary analysis: CVE ids, affected and fixed versions, first-seen dates, indicators and the response order. Patchstack describes exploitation volume as limited in its telemetry.
- Ninja Forms changelog (wordpress.org)3.15.4 entry dated 21 September 2026 lists stronger output escaping on the admin submission edit screen. It names no CVE. Later entries add more stored XSS hardening: 3.15.5 (28 September) and 3.15.6 (15 October). Checked 28 October 2026.
- WPC Product Bundles for WooCommerce changelog (wordpress.org)8.6.7 entry says only 'Fixed: Vulnerability reported by lhking from Wordfence'. It names no CVE. A later entry, 8.7.3, lists a further stored XSS fix (the changelog gives no dates). Checked 28 October 2026.
- BleepingComputer: Ninja Forms plugin flaw exploited to hack WordPress sites (6 October 2026)Secondary coverage of the Patchstack findings. Its wording on whether an attacker needs an account differs from Patchstack's; this page follows Patchstack.
Facts on this page are dated and point at the primary source next to them. If a vendor status changes after the date shown, the vendor's page wins; tell us at support@run.cloud and we will update it.