Critical XSS in “Maximum Products per User for WooCommerce” (≤ 4.3.6) — What WordPress Site Owners Must Do Right Now

Date: 22 Apr, 2026

CVE: CVE-2025-47504

Affected versions: ≤ 4.3.6

Patched in: 4.3.7

CVSS: 6.5 (Medium)

Required privilege: Contributor (authenticated)

Exploit complexity: User interaction required (a privileged user must open a crafted link / page / form)

Summary

A cross-site scripting (XSS) vulnerability has been disclosed in the WordPress plugin “Maximum Products per User for WooCommerce” affecting versions up to and including 4.3.6.
An authenticated user with the Contributor role can supply crafted input which, when acted on or viewed by a privileged user (administrator/shop manager), may execute attacker-supplied JavaScript in the privileged user’s browser.
The plugin author released version 4.3.7 to address the issue. If your site runs this plugin, you should prioritise remediation and containment immediately.

Why this matters (short version)

• XSS in admin-facing components enables execution of JavaScript in the context of a privileged user. That script can steal session cookies, perform administrative actions, or install persistent backdoors.
• Although exploitation requires interaction, admin interfaces are frequently visited by staff — making exploitation realistic in many workflows.
• Sites running WooCommerce and using this plugin are the most directly impacted; stores with multiple contributors are higher risk.

What type of XSS is this, and how might an attacker exploit it?

This is an authenticated XSS where a Contributor can supply content that becomes dangerous if a privileged user triggers rendering of that content. Common exploitation scenarios include:

• A contributor adds or edits a product description, product meta, note, or plugin-managed setting with a crafted payload. When an admin visits the plugin settings, product edit page, or review screen that renders that content unescaped, the malicious JavaScript executes.
• A contributor submits a form or link containing a payload that, when previewed or clicked by a privileged user, executes.
• Social engineering to lure a shop manager or admin to view “orders”, “product limits”, or internal reports that trigger the payload.

Impact examples

• Steal authentication cookies or session tokens and use them to log in as an admin.
• Create new admin users or elevate privileges.
• Exfiltrate sensitive data (orders, customer metadata).
• Inject persistent backdoors (malicious plugin/theme files or injected PHP).
• Trigger configuration changes in payment or shipping settings.

Even if publicly labelled “low”, admin-facing XSS should be treated seriously — a successful exploit can lead to full site compromise.

Quick checklist — Immediate actions (ordered)

1. Update the plugin to version 4.3.7 (or later) immediately if you can.
2. If you cannot update immediately:
   • Deactivate the plugin until you can update, or
   • Apply virtual patching with your Web Application Firewall (WAF) — see mitigation rules below.
3. Audit contributor accounts and remove or temporarily downgrade any accounts you do not absolutely trust.
4. Require privileged users (admins/shop managers) to re-authenticate for sensitive admin screens where possible.
5. Enable two-factor authentication (2FA) for all administrative accounts and users with elevated roles.
6. Inspect your site for indicators of compromise (see detection section below).
7. Ensure you have a recent off-site backup before making changes.

If you manage multiple client sites, prioritise stores with high transaction volume and sites that allow many contributors.

Detection — How to tell if you’re already affected

• Search database tables (postmeta, options, usermeta) for instances of
• Check product descriptions, product meta, and plugin-specific settings pages where untrusted content may be rendered.
• Review recent admin activity logs for unexpected logins, creation of new admin accounts, or plugin/theme changes.
• Inspect wp-content for newly modified files, unknown PHP files, or PHP files in uploads directories.
• Examine web server access logs for suspicious POST/GET requests targeting the plugin’s admin endpoints or containing encoded script payloads.
• Monitor outbound connections from your server for unusual destinations (possible data exfiltration or C2 activity).

If you find suspicious artifacts:

1. Take an immediate backup (filesystem + DB) for forensic purposes.
2. Isolate the site (display a maintenance page) while you investigate.
3. Change passwords for all privileged users, and rotate API keys and tokens used by the site.

Mitigation details — updates, hardening, and WAF rules

Primary remediation

Update the plugin to 4.3.7 or later. This is the only guaranteed fix released by the plugin author.

Secondary mitigations (when immediate updating isn’t possible)

1. Disable or deactivate the plugin
   If you can afford to turn it off temporarily, deactivate it until a tested, patched version is installed.
2. Protect admin routes with IP restrictions
   Limit access to /wp-admin and the plugin’s admin pages to trusted IP addresses via server-level controls (NGINX/Apache) or by allowlisting at the network edge.
3. Reduce Contributor privileges
   Remove the ability for contributors to add HTML or unfiltered content. Ensure contributors cannot upload files or create items that display HTML to admins without review.
4. Apply a virtual patch (WAF)
   A WAF with virtual patching capability can provide immediate protection by blocking suspicious payload patterns targeted at admin routes. Example rule concepts:
   • Block requests containing
     Review My Order

     0

     Subtotal

     Taxes & shipping calculated at checkout

     Checkout