WordPress Stored-XSS Admin Takeover: Fake "WP Smart Thumbnails" Plugin, Hidden Administrator and Backdoor Login

Two unrelated WordPress plugins, WPC Product Bundles for WooCommerce (CVE-2026-93836, versions up to 8.6.6) and Ninja Forms (CVE-2026-94504, versions up to 3.15.3), carry stored cross-site scripting flaws that are being exploited to deliver one shared JavaScript implant from imgcdn1[.]com. Patchstack first saw it on 2026-10-04 against WPC Product Bundles and on 2026-10-05 through Ninja Forms, and reported it on 2026-10-06. The XSS is only the front door: the payload runs inside a logged-in administrator's browser, rides that authenticated session, scrapes the nonces WordPress requires, and then uses WordPress's own plugin installer to drop a fake plugin.

One successful execution leaves the attacker with four independent ways back in: a visible administrator account, an administrator hidden from the Users screen by a must-use plugin, a magic login URL that authenticates as the site's oldest administrator, and an unauthenticated file manager inside the fake plugin. Removing the vulnerable plugin, or even the fake one, closes none of the last three. Patchstack also notes that the installer backdates the files it writes, so a search for recently changed files misses them.

Honest endpoint scope. The exploit, nonce theft, plugin upload, administrator creation and database option writes all happen inside the browser, WordPress and PHP. Falcon endpoint telemetry cannot see them. What Falcon can see is narrower: the administrator workstation looking up the C2 domain, file-integrity events for the dropped PHP files if a FIM policy covers wp-content, shells spawned by the web or PHP worker, and command lines that name the campaign's artifacts. Everything else needs WordPress audit logs, database queries, web server logs, a WAF or a file-integrity tool, and Section 7 and Section 15 say so plainly.

Defender priority: update both plugins, then treat any site where an administrator opened a WooCommerce order or Ninja Forms submission since 2026-10-04 as potentially compromised. Updating stops new injections but does not clean an existing infection. Enumerate administrators directly in the database, inspect the mu-plugins directory by content rather than date, and rotate credentials and salts.

Decision log

• CVE numbers. CVE-2026-93836 and CVE-2026-94504 are the only CVE identifiers shipped. Both appear in the Patchstack article, BleepingComputer, ReconBee and the SecurityOnline panel. Other Ninja Forms CVE identifiers circulate in low-quality aggregator posts and search snippets; none of them appears in any saved snapshot, and one that surfaced in a search snippet described a different, earlier Ninja Forms version range, so none is shipped.
• CVSS discrepancy. Patchstack lists CVSS 7.1 for both flaws; SecurityOnline lists 7.2. The pack reports "7.1 to 7.2, high" rather than choosing one.
• "Authenticated" wording. BleepingComputer and ReconBee say the flaws "require an authenticated session to exploit". Patchstack calls both unauthenticated stored XSS. These reconcile: the attacker injects the payload without logging in, but the script only does damage when an authenticated administrator views the stored content. The pack follows Patchstack.
• WPC Product Bundles fix version. Patchstack and BleepingComputer name 8.6.7. The vendor changelog lists a vulnerability fix in 8.6.7 and a separate stored-XSS sanitization fix in 8.7.3. The pack recommends moving to the current release, not stopping at 8.6.7.
• Single-source indicators ship as detect. Every hash, the domain and the plugin artifacts originate in the Patchstack analysis. BleepingComputer and ReconBee repeat the domain but do not independently verify it. Under the two-source rule nothing ships at prevent, and no row in the Falcon import CSV is prevent.
• Hashes that cannot exist. Patchstack states the two must-use plugins are obfuscated with a fresh key per site, so no fixed hash is published and none is invented here. They are listed by path and detected by behavior.
• No coined name. The sources give the campaign no label. The pack uses descriptive wording and the fake plugin identity "WP Smart Thumbnails" exactly as the sources name it.
• Fetched-content check. No fetched page contained instructions directed at an automated reader. Pages carried only ordinary site navigation, ads and unrelated headlines, which were ignored.

Hypotheses

Attack chain

Patchstack states these indicators describe the campaign observed in its telemetry and should not be read as exhaustive indicators for exploitation of either CVE.

Most of this campaign is invisible to the Falcon sensor. These checks run on the WordPress host, the database and the web server, and are the primary hunt for the application-layer steps. Commands come from the Patchstack detection section unless marked as derived guidance.

1. Enumerate administrators in the database, not in wp-admin

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 to Users, All Users. Any account present in SQL but absent in the interface is hidden by a dropped must-use plugin. An @wordpress.org address on a local account, or a routine word such as support, updater, maintenance or backup, is a further signal. Adjust the wp_ prefix to your table prefix. Use raw SQL: WP-CLI loads must-use plugins, so wp user list can be filtered by the same hooks.

2. Check the campaign's own options

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

fz_emer_login_tokens present means at least one backdoor login token is live. Deleting the options alone is not enough while the must-use plugins remain.

3. Inspect the mu-plugins directory and the fake plugin

ls -la wp-content/mu-plugins/
ls -la wp-content/plugins/wp-smart-thumbnails/ 2>/dev/null
find wp-content/mu-plugins -type f -name 'class-wp-query-*.php' -o -name 'class-wp-token-validate.php'
grep -rl "dyiv://" wp-content/plugins 2>/dev/null

File modification times are not reliable here, because the installer backdates what it writes. Sort by content and by whether the file belongs to your known-good baseline. The mu-plugins directory should normally be empty or hold only files your host or team placed there. Both campaign must-use plugins are obfuscated, so a plain-text grep for hook names will not find them.

4. Search web server logs

grep -E "imgcdn1|/fz/x\.js|/fz/c\.php" /var/log/apache2/*access* /var/log/nginx/*access*
grep -E "_wplogin=" /var/log/apache2/*access* /var/log/nginx/*access*
grep -E "wp-smart-thumbnails" /var/log/apache2/*access* /var/log/nginx/*access*
grep -E "woosb_ids|nf_ajax_submit" /var/log/apache2/*access* /var/log/nginx/*access*

Requests carrying _wplogin to wp-login.php and direct requests to wp-smart-thumbnails.php outside the plugin screens are usable signals (Patchstack). The last pattern is broad: nf_ajax_submit is a normal Ninja Forms action, so triage hits by looking for markup in the submitted values. POST bodies are usually not in access logs, so a WAF or audit log is needed to see the payload itself.

5. Find stored payloads before an administrator opens them (derived guidance)

wp db query "SELECT meta_id, post_id FROM wp_postmeta WHERE meta_value LIKE '%imgcdn1%'"
wp db query "SELECT meta_id, order_item_id FROM wp_woocommerce_order_itemmeta WHERE meta_value LIKE '%imgcdn1%'"

This searches the places the sources say the payload is stored (order metadata and form submissions). Table names vary with prefix and WooCommerce storage mode; treat it as a starting point. Remove matching rows without opening them in wp-admin.

6. Review administrator-created accounts and plugin installs around order or submission views

Patchstack advises investigating any administrator account created around the time an administrator viewed WooCommerce orders or Ninja Forms submissions. This needs a WordPress audit-log plugin or equivalent; the stock log does not record it.

7. Administrator workstation (browser)

Search proxy and DNS logs for imgcdn1[.]com. On a workstation known to have opened affected content, check browser Local Storage for keys beginning __xp_v9_ (Patchstack). Treat the administrator's WordPress session as compromised.

Seven endpoint queries cover only the endpoint-visible slice. Q5 and Q6 depend on a Falcon FIM or critical-file policy that includes wp-content, which is not on by default (marked "validate in tenant"). Q7 depends on inbound-accept telemetry. XSS execution, nonce theft, hidden-administrator creation and the database option rows have no Falcon query; see Section 7 and Section 15.

// HUNT: DNS lookup of imgcdn1[.]com, the host serving the stored-XSS implant and its C2
// MITRE: T1071.001, T1105, T1059.007
// CONF: high
// FP: low
// COST: low
// REQUIRES: DnsRequest on admin workstations (Windows, macOS) and on web servers (Windows, Linux)
// FALSE POSITIVES: threat-intel sandboxes or DNS-sinkhole testing that deliberately resolves the domain
// NOTE: the implant runs in the ADMINISTRATOR'S BROWSER, so the lookup normally comes from an admin workstation, not the web server
#event_simpleName=DnsRequest
| DomainName=/(^|\.)imgcdn1\.com$/i
| groupBy([aid, ComputerName, ContextBaseFileName, DomainName], function=[count(as=Lookups), min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)], limit=20000)
| sort(FirstSeen, order=asc)
| table([aid, ComputerName, ContextBaseFileName, DomainName, Lookups, FirstSeen, LastSeen])

// HUNT: Web-server or PHP worker making outbound web connections to rare external addresses
// MITRE: T1105, T1071.001
// CONF: low
// FP: high
// COST: medium
// REQUIRES: NetworkConnectIP4 from Linux (httpd, apache2, nginx, php-fpm) and Windows (w3wp.exe) web servers
// FALSE POSITIVES: WordPress core and plugin update checks, payment gateway and shipping APIs, license servers, CDN and font fetches, outbound mail APIs
// TUNING: baseline for 14 days in investigate mode, then exclude every destination the site legitimately calls, for example by adding: | !in(RemoteAddressIP4, values=["REPLACE_WITH_BASELINED_API_IP"]) and keep only the rare tail (Conns <= 5)
// NOTE: Patchstack describes the fetches as browser-side, so this is a second-stage and follow-on hunt, not a primary detection
#event_simpleName=NetworkConnectIP4
| ContextBaseFileName=/^(httpd|apache2|nginx|php-fpm[0-9.]*|php-cgi[0-9.]*|lsphp[0-9]*|w3wp\.exe)$/i
| in(RemotePort, values=[80, 443])
| !cidr(RemoteAddressIP4, subnet="10.0.0.0/8")
| !cidr(RemoteAddressIP4, subnet="172.16.0.0/12")
| !cidr(RemoteAddressIP4, subnet="192.168.0.0/16")
| !cidr(RemoteAddressIP4, subnet="127.0.0.0/8")
| groupBy([aid, ComputerName, ContextBaseFileName, RemoteAddressIP4], function=[count(as=Conns), min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)], limit=20000)
| Conns <= 5
| sort(Conns, order=asc)
| table([aid, ComputerName, ContextBaseFileName, RemoteAddressIP4, Conns, FirstSeen, LastSeen])

// HUNT: Shell, downloader or recon utility spawned by a web-server or PHP worker process
// MITRE: T1505.003, T1059
// CONF: medium
// FP: medium
// COST: low
// REQUIRES: ProcessRollup2 on Linux (apache2, httpd, nginx, php-fpm) and Windows (w3wp.exe) web servers
// FALSE POSITIVES: image and PDF plugins that shell out to convert, gs or wkhtmltopdf; backup and cache plugins; hosting-panel helpers
// TUNING: after a baseline, exclude known plugin helper commands, for example: | !(FileName=/^(sh|bash)$/i CommandLine=/convert|gs |wkhtmltopdf|ffmpeg/i) ; escalate when the parent is a PHP worker and the child is a downloader (curl, wget) or an interactive shell with no helper pattern
// NOTE: the fake plugin's file manager has no command-execution primitive (Patchstack), so this catches the SECOND shell an attacker drops through it, not the file manager itself
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(httpd|apache2|nginx|php-fpm[0-9.]*|php-cgi[0-9.]*|lsphp[0-9]*|w3wp\.exe)$/i
| FileName=/^(sh|bash|dash|zsh|ash|nc|ncat|netcat|socat|curl|wget|python[0-9.]*|perl|ruby|whoami|id|uname|cmd\.exe|powershell\.exe|pwsh\.exe|certutil\.exe|bitsadmin\.exe|whoami\.exe|curl\.exe|mshta\.exe)$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])

// HUNT: Process command line referencing the campaign's plugin, installer, must-use plugin, option or login-token names
// MITRE: T1505.003, T1136.001, T1078
// CONF: high
// FP: medium
// COST: low
// REQUIRES: ProcessRollup2 on Linux and Windows web servers
// FALSE POSITIVES: your own incident-response triage (grep, find, ls, rm, wp db query) and file-integrity or backup tooling that names these paths while cleaning up
// TUNING: exclude your IR toolkit and approved admin sessions, for example: | !(ParentBaseFileName=/^(REPLACE_WITH_IR_WRAPPER)$/i) ; treat any hit whose parent is a web or PHP worker, or whose command line does not come from a known responder, as hostile
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| CommandLine=/(wp-smart-thumbnails|emer-run\.php|class-wp-token-validate|class-wp-query-[0-9a-f]{8}\.php|fz_emer_(done_v1|login_tokens)|_wplogin=)/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine])

// HUNT: Campaign-named PHP files written to a WordPress host (dropper, installer, token-validate and query must-use plugins)
// MITRE: T1505.003, T1564, T1070.006
// CONF: high
// FP: low
// COST: low
// REQUIRES: CriticalFileModified (Falcon File Integrity Monitoring / critical-file policy covering wp-content) -- ⚠ validate in tenant: wp-content is NOT monitored by default and the policy must be scoped to plugins and mu-plugins
// FALSE POSITIVES: none expected; these filenames are not part of WordPress core or any legitimate plugin Patchstack describes
// NOTE: the event time is the write time as the sensor saw it, so the installer's file-timestamp backdating does not hide it here
#event_simpleName=CriticalFileModified
| FileName=/^(class-wp-token-validate\.php|class-wp-query-[0-9a-f]{8}\.php|emer-run\.php|wp-smart-thumbnails\.php)$/i
| table([@timestamp, aid, ComputerName, FileName, FilePath, ContextBaseFileName, ContextProcessId, UserName])

// HUNT: Any PHP file created or changed in a WordPress mu-plugins directory
// MITRE: T1505.003, T1564
// CONF: medium
// FP: medium
// COST: low
// REQUIRES: CriticalFileModified scoped to wp-content/mu-plugins -- ⚠ validate in tenant: add the mu-plugins path to your FIM policy first
// FALSE POSITIVES: managed WordPress hosts and caching or security suites that ship their own mu-plugins, and deliberate deploys from CI
// TUNING: exclude the filenames your host or deploy pipeline legitimately writes, for example: | !FileName=/^(REPLACE_WITH_HOST_MU_PLUGIN)\.php$/i ; keep every other write, especially one made by a web or PHP worker process (ContextBaseFileName) with no matching change ticket
// NOTE: both campaign must-use plugins are obfuscated per site with a fresh key, so no fixed hash exists; the directory itself is the signal
#event_simpleName=CriticalFileModified
| FilePath=/mu-plugins/i
| FileName=/\.php$/i
| table([@timestamp, aid, ComputerName, FileName, FilePath, ContextBaseFileName, ContextProcessId, UserName])

// HUNT: Inbound web connections from the five source IPs Patchstack observed delivering the payload
// MITRE: T1190
// CONF: low
// FP: low
// COST: low
// REQUIRES: NetworkReceiveAcceptIP4 on web servers -- ⚠ validate in tenant: inbound-accept telemetry coverage differs by sensor version and OS
// FALSE POSITIVES: four of the five addresses are Tor exit nodes (Patchstack) shared with unrelated traffic, so a hit shows contact, not compromise
// NOTE: hunt and enrich only, the addresses are not durable and the list is not exhaustive (Patchstack)
#event_simpleName=NetworkReceiveAcceptIP4
| in(RemoteAddressIP4, values=["204.8.96.109", "147.90.235.22", "90.184.10.74", "94.16.115.121", "43.250.53.42"])
| in(LocalPort, values=[80, 443, 8080, 8443])
| table([@timestamp, aid, ComputerName, RemoteAddressIP4, LocalPort, ContextBaseFileName])

File-based Q5 and Q6 are FIM-dependent and not IOA candidates. IOA rule-type support differs between Windows and Linux sensors, so confirm each rule type exists for your sensor version before building.

Authorities: MITRE ATT&CK mitigations (the why), the WordPress.org Hardening WordPress and wp-config documentation (snapshots 07, 08), and the CIS Apache HTTP Server and NGINX Benchmarks for the web tier. No formal CIS WordPress benchmark was consulted for this pack, so WordPress controls cite the WordPress.org documentation and are marked where they are best practice only.

Linux examples use Apache or NGINX with a Debian-style layout. Replace /var/www/html, www-data, deploy and 192.0.2.0/24 with your own values. Test each change on a staging copy first.

Step 1: Compromise triage (read-only)

Prerequisites: Shell access and WP-CLI on the WordPress host; database credentials from wp-config.php
Reboot required: No

cd /var/www/html
# 1. administrators straight from the database (not filtered by mu-plugins)
wp db query "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%'"
# 2. campaign options
wp db query "SELECT option_name FROM wp_options WHERE option_name IN ('fz_emer_done_v1','fz_emer_login_tokens')"
# 3. must-use and fake plugin
ls -la wp-content/mu-plugins/ wp-content/plugins/wp-smart-thumbnails/ 2>/dev/null
# 4. take evidence before changing anything
tar -czf /root/wp-evidence-$(date +%F).tgz wp-content/mu-plugins wp-content/plugins/wp-smart-thumbnails 2>/dev/null

Rollback:

none required: every command in this step only reads state, except the evidence archive, which can be deleted with rm /root/wp-evidence-*.tgz

Step 2: Lock down wp-config.php

Prerequisites: Staging validated; an alternative update path (WP-CLI, Composer or CI) exists because dashboard installs stop working
Reboot required: No (PHP-FPM reload not needed; the constant is read per request)

cd /var/www/html
cp wp-config.php wp-config.php.bak-$(date +%F)
# add above the "That's all, stop editing" line
sed -i "/stop editing/i define( 'DISALLOW_FILE_MODS', true );\ndefine( 'DISALLOW_FILE_EDIT', true );\ndefine( 'FORCE_SSL_ADMIN', true );" wp-config.php
wp config get DISALLOW_FILE_MODS

Rollback:

# restore the previous file
cp wp-config.php.bak-YYYY-MM-DD wp-config.php

Step 3: Block the backdoor login, the fake plugin and (optionally) restrict admin access at the web server

Prerequisites: Apache 2.4 with mod_rewrite, or NGINX; an admin network range to allow
Reboot required: No (graceful reload of the web server)

# --- Apache 2.4 (vhost or .htaccess, outside the WordPress BEGIN/END block) ---
RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)_wplogin= [NC]
RewriteRule ^ - [F,L]
RewriteRule ^wp-content/plugins/wp-smart-thumbnails/ - [F,L]
<Files "wp-login.php">
    Require ip 192.0.2.0/24
</Files>

# --- NGINX ---
location ~* ^/wp-content/plugins/wp-smart-thumbnails/ { return 403; }
location = /wp-login.php {
    if ($arg__wplogin) { return 403; }
    allow 192.0.2.0/24;
    deny all;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}
# check config, then reload
# apachectl configtest && systemctl reload apache2
# nginx -t && systemctl reload nginx

Rollback:

# remove the added lines (or restore your backup of the vhost/.htaccess/server block), then:
# apachectl configtest && systemctl reload apache2
# nginx -t && systemctl reload nginx

Step 4: Make plugin and must-use directories read-only to PHP

Prerequisites: Root or deploy-account access; a deployment path that does not depend on PHP writing to these directories; staging pilot
Reboot required: No

cd /var/www/html
chown -R deploy:deploy wp-content/plugins wp-content/mu-plugins
find wp-content/plugins wp-content/mu-plugins -type d -exec chmod 755 {} \;
find wp-content/plugins wp-content/mu-plugins -type f -exec chmod 644 {} \;
# keep uploads writable, but never executable PHP
# verify: this must FAIL
sudo -u www-data touch wp-content/mu-plugins/.write-test

Rollback:

# restore the previous ownership recorded before the change (example)
chown -R www-data:www-data wp-content/plugins wp-content/mu-plugins

Step 5: File-integrity watches and DNS sinkhole

Prerequisites: auditd installed; dnsmasq or your resolver supports local overrides; Falcon FIM policy configured separately in the console for Q5 and Q6
Reboot required: No

# /etc/audit/rules.d/wordpress-persistence.rules
-w /var/www/html/wp-content/mu-plugins -p wa -k wp_mu_plugins
-w /var/www/html/wp-content/plugins -p wa -k wp_plugins
# load: augenrules --load   verify: auditctl -l | grep wp_

# /etc/dnsmasq.d/sinkhole-imgcdn1.conf   (the domain is the Patchstack-published payload and C2 host)
address=/imgcdn1.com/0.0.0.0
# reload: systemctl restart dnsmasq   verify: dig +short imgcdn1.com @127.0.0.1  returns 0.0.0.0

Rollback:

# remove the rule files, then reload:
# rm /etc/audit/rules.d/wordpress-persistence.rules && augenrules --load
# rm /etc/dnsmasq.d/sinkhole-imgcdn1.conf && systemctl restart dnsmasq

Step 6: ModSecurity detection-only rules for the two delivery fields

Prerequisites: ModSecurity v2 or v3 with the OWASP Core Rule Set already in DetectionOnly; unique rule ids from your local range
Reboot required: No (web server reload)

# DetectionOnly first. Promote to deny only after reviewing a week of audit logs.
SecRule ARGS_NAMES "@rx ^woosb_ids" \
  "id:9100101,phase:2,t:none,log,auditlog,pass,chain,msg:'Markup in WPC Product Bundles quantity'"
  SecRule ARGS "@rx (?i)<\s*(script|img|svg)|onerror\s*=" "t:none"

SecRule REQUEST_URI "@contains admin-ajax.php" \
  "id:9100102,phase:2,t:none,log,auditlog,pass,chain,msg:'Markup in Ninja Forms AJAX submission'"
  SecRule ARGS:action "@streq nf_ajax_submit" "chain"
  SecRule ARGS "@rx (?i)</textarea>|<\s*(script|img|svg)|onerror\s*=" "t:none"

Rollback:

# delete the two SecRule blocks above and reload the web server

This pack is intentionally candid: more of the attack chain is outside Falcon endpoint visibility than inside it. The endpoint adds value on the administrator workstation and, with FIM enabled, on the web server file system.

Validation gates (Section 11): sensor and FIM coverage must be confirmed before Q5 and Q6 are trusted; run Q2, Q3, Q4 and Q6 for at least 14 days in investigate mode before enforcement; promote only after a clean baseline.