The WordPress break-in that hides its own admin account

If you take orders through WooCommerce, or you collect enquiries through a contact form, there is a fair chance that one of the two plugins in this story is installed on your site right now. Over the first weekend of October, attackers began using both of them to do something more patient than a defacement. They add an administrator account to your site, and then they teach WordPress not to show it to you.

Both holes were already fixed before the attacks started. That is the good news. The bad news is that updating today does not undo anything that happened yesterday. So this is a two part job: patch, then check.

What was attacked, and when

Security firm Patchstack published its analysis on 8 October 2026, covering attacks against two plugins:

• Ninja Forms, all versions up to and including 3.15.3, with more than 500,000 active installations. Fixed in 3.15.4, released on 21 September 2026 (see the plugin changelog). Tracked as CVE-2026-94504. The current release is 3.15.5.
• WPC Product Bundles for WooCommerce, all versions up to and including 8.6.6, with more than 30,000 active installations. Fixed in 8.6.7, whose changelog entry reads simply “Fixed: Vulnerability reported by lhking from Wordfence”. Tracked as CVE-2026-93836. The current release is 8.7.4.

A CVE is just a public reference number for one specific flaw, so that everybody is talking about the same thing. Both of these were published on 22 September 2026 by Wordfence, and both are rated 7.2 out of 10 for severity.

Both are stored cross-site scripting flaws. Cross-site scripting, usually shortened to XSS, means an attacker can save a snippet of JavaScript into your site through a form field or an order, and that snippet later runs inside somebody else's browser. In this campaign the somebody else is you, the logged in administrator, at the moment you open the order or the form submission to read it.

The timeline is ordinary and worth noticing. The fixes shipped on 21 and 22 September. The attacker registered the domain used to serve the payload, imgcdn1.com, on 1 October. The first attempt against WPC Product Bundles was seen on 4 October, and the same payload arrived through Ninja Forms on 5 October. The patch is the map. Two weeks is a normal head start.

Nothing is stolen, which is the clever part

Most WordPress attacks you read about involve a stolen password or a forged login. This one does not bother. The script runs in your browser, inside your already logged in admin session, so every request it makes to your own site is authenticated before it starts. It does not need your password, and the protections that stop a password being read, such as HttpOnly cookies, do not help, because nothing is being read.

What it does instead is drive the dashboard the way a person would. It collects the security tokens WordPress uses to confirm that an action was genuinely requested from inside the admin area, then uses WordPress's own plugin installer to install a plugin called “WP Smart Thumbnails”, version 1.2.4, attributed to a vendor called “MediaPress Labs”. From the server's point of view, an administrator installed a plugin. That is all the logs will say.

Four ways back in

Patchstack's title is the point. The attacker does not leave one door open. They leave four:

1. A visible administrator account, created normally, with credentials handed over by the attacker's control server. You would spot this one.
2. A hidden administrator account, created separately, named from a short list of innocent sounding words such as support, updater, maintenance or backup, and given an @wordpress.org email address so it reads as official at a glance.
3. A magic login link. A request to wp-login.php carrying a _wplogin parameter and the right token signs the visitor straight in as the site's oldest administrator account, which on most sites is the owner.
4. An unauthenticated file manager inside the fake plugin, able to upload, edit and delete files with no login at all.

Remove one and the other three still work. The files dropped on disk are also backdated: the script finds the oldest modification date anywhere in your WordPress folder and stamps it onto its own files, so sorting by date will not make them stand out.

Why your Users screen will not help

The hidden account is the part worth understanding, because it defeats the check most owners would think to do.

WordPress has a folder called mu-plugins, short for must-use plugins. Code placed there loads automatically on every request. It has no activate or deactivate switch, and it does not appear in your normal Plugins list. This campaign writes files into that folder which do three things: they edit the database query behind the user list so the hidden account is left out, they exclude it again from the admin user table, and they reduce the administrator count shown above the list so the numbers still add up.

The result is that the account does not appear under Users, does not appear when you filter by Administrator, and is not counted in the totals. Your dashboard is not broken. It is being told what to say.

How to check your own site

The first item you can do yourself in two minutes. The rest is a short job for whoever maintains the site.

1. Check your versions. In Plugins, confirm Ninja Forms is 3.15.4 or newer and WPC Product Bundles is 8.6.7 or newer. Update anything older today.
2. Look for the fake plugin. Anything called WP Smart Thumbnails, or a folder named wp-smart-thumbnails, should not be there.
3. Count your administrators in the database, not in the dashboard. The two numbers should match. If the database shows an administrator that the Users screen does not, you have your answer. Patchstack publishes the query to run.
4. Look inside wp-content/mu-plugins. Files named like class-wp-query- followed by eight random characters, or class-wp-token-validate.php, are not standard WordPress. Ignore the dates on them.
5. Search the options table for entries named fz_emer_done_v1 or fz_emer_login_tokens.
6. Ask your host for server logs mentioning imgcdn1.com, the paths /fz/x.js or /fz/c.php, or any request carrying a _wplogin parameter.

If any of those turn something up, the honest answer is that deleting a file or two is not enough. The site needs the accounts removed, the plugin and the mu-plugin files removed, every password changed, and the WordPress security salts rotated, which signs out every existing session including the attacker's.

What is not settled yet

A few things are worth stating plainly rather than guessing at.

Patchstack describes the volume of exploitation as currently limited, and has not published a number of compromised sites. It has also been clear that two affected plugins is what it has confirmed so far, not what it expects the final count to be, so more plugins may be named in the coming weeks.

There is also a contradiction in the reporting. BleepingComputer's write up states that exploitation requires an authenticated session, while the CVE records for both flaws are scored as requiring no privileges at all, and Patchstack treats them as unauthenticated. That difference matters for how exposed a public shop front really is, and at the time of writing it is unresolved.

This week

Update the two plugins if you have them. Then open Users and actually read the list rather than glancing at it, and ask whoever looks after your site to run the database side of the check above. If nobody looks after your site, that is the real finding.

Keeping plugins current and watching for this sort of thing is the dull half of running a website, and it is the half that decides whether a bad weekend turns into a bad quarter. If you would rather it was somebody else's job, it is ours.