What Patchstack has reported about the WordPress XSS campaign
Patchstack says it first observed the campaign on 4 October 2026, when attackers exploited CVE-2026-93836 in WPC Product Bundles for WooCommerce. On 5 October, the same JavaScript payload was seen exploiting CVE-2026-94504 in Ninja Forms.
The important point is that the malicious JavaScript runs when affected stored content is opened by a logged-in WordPress administrator. It then uses that administrator's existing authenticated session to perform actions available through WordPress. According to Patchstack, it does not need to steal the administrator's login cookie.
The payload can install a malicious plugin, create administrator accounts and establish several separate ways for an attacker to regain access. One administrator account can be concealed from the normal Users screen. The campaign can also create a special login URL connected to an existing administrator account and install an unauthenticated file manager inside the malicious plugin.
This makes simply deleting an unfamiliar user or removing one suspicious plugin an incomplete response. Patchstack found multiple persistence mechanisms that can remain after the original route into the site has been removed.
How the WordPress XSS attack gets in and which sites are affected
The two confirmed entry points are separate stored XSS vulnerabilities. WPC Product Bundles for WooCommerce is affected through version 8.6.6 by CVE-2026-93836. Patchstack reports that attacker-controlled markup can be retained in WooCommerce order metadata and later rendered when an administrator views it.
Ninja Forms is affected through version 3.15.3 by CVE-2026-94504. In this case, malicious content can be stored through form submissions and execute when an affected submission is opened in the legacy administrative submission editor. Patchstack states that version 3.15.4 strengthened output escaping on that screen.
Once the stored JavaScript executes inside the WordPress administrative origin, it can make authenticated requests using the administrator's existing session. It obtains the security nonces needed for legitimate WordPress administrative actions and uses them to install its additional components.
The campaign should therefore be treated as more than a suspicious JavaScript injection. A site on an affected plugin version may require investigation for persistence even after the vulnerable plugin has been updated or removed, particularly if an administrator has already viewed potentially malicious stored content.
Signs of infection and how to check your WordPress site
Patchstack identified several useful indicators. One is a plugin installed under the slug wp-smart-thumbnails, posing as WP Smart Thumbnails 1.2.4 by MediaPress Labs. Its files may appear older than the compromise because the campaign deliberately changes file timestamps.
Administrators should not rely solely on the WordPress Users screen. Patchstack found that a malicious must-use plugin can hide an administrator from the normal user list, the Administrator filter and the displayed role totals. Must-use plugins also do not appear in the standard Plugins screen, so checks should include the wp-content/mu-plugins directory as well as ordinary plugins.
Other indicators described by Patchstack include files named in the pattern class-wp-query-<8 hex>.php, a must-use plugin named class-wp-token-validate.php, the WordPress option fz_emer_login_tokens and browser Local Storage entries beginning __xp_v9_. The campaign also communicates with imgcdn1.com.
You can use our free WordPress security scanner as an initial check, alongside a proper review of the site's files, plugins, users and must-use plugins. See our WordPress website security guidance for further help. A clean-looking WordPress dashboard alone is not enough to rule out this campaign.
How to clean the WordPress infection and prevent reinfection
Before changing or deleting anything, take a backup and preserve a separate copy of the affected files and relevant evidence. This gives you something to examine if you need to establish how access was gained and avoids destroying useful indicators during the initial clean-up.
Next, identify and close the original entry point. Sites using the affected plugins should check the installed versions and update or remove the vulnerable plugin as appropriate. Cleaning the malicious plugin without dealing with the vulnerable stored content or the original XSS route can leave the site exposed.
The clean-up should also account for every persistence method described by Patchstack. Check ordinary and must-use plugins, investigate administrator accounts independently of the Users screen, review the reported login-token mechanism and remove malicious files only after you have established what they do. Because the campaign deliberately backdates files, do not assume that recently modified files are the only ones worth investigating.
After removing the compromise, change all WordPress administrator passwords and other relevant credentials, and replace the WordPress authentication salts so existing sessions are invalidated. Then verify that the vulnerable component has been patched or removed and investigate how the malicious stored content entered the site before returning it to normal use.
If you need hands-on recovery, our Hacked Site Rescue is £249 fixed price and covers malware removal, a clean restore and help clearing browser and Google warnings. For ongoing maintenance, care plans start from £59 a month and include weekly updates, daily off-server backups, 24/7 uptime monitoring and security scanning.