| Plugin Name | Premmerce Product Filter for WooCommerce |
|---|---|
| Type of Vulnerability | Cross-Site Scripting (XSS) |
| CVE Number | CVE-2024-13362 |
| Urgency | Low |
| CVE Publish Date | 2026-05-01 |
| Source URL | CVE-2024-13362 |
Urgent: Unauthenticated Reflected XSS in Premmerce Product Filter for WooCommerce (≤ 3.7.3) — What WordPress Site Owners Must Do Now
Summary: A reflected cross-site scripting (XSS) vulnerability (CVE-2024-13362) affects Premmerce Product Filter for WooCommerce versions up to and including 3.7.3. Unauthenticated attackers can craft URLs that cause attacker-controlled data to be reflected in page output without proper escaping, allowing execution of arbitrary JavaScript in visitors’ browsers. The issue is assessed at CVSS 6.1 (medium). Although not server-side remote code execution, the client-side impact—session theft, redirects, phishing, or drive-by attacks—can be severe.
What is the issue?
- Vulnerability type: Reflected Cross-Site Scripting (XSS)
- Affected software: Premmerce Product Filter for WooCommerce plugin
- Vulnerable versions: up to and including 3.7.3
- CVE: CVE-2024-13362
- Access required: Unauthenticated (any visitor)
- Risk summary: Attackers can craft URLs whose parameters are reflected into page output without proper escaping. If a victim opens that URL, injected JavaScript runs in the site’s origin and can interact with cookies, DOM, or network requests.
Why you should take this seriously
Reflected XSS is frequently leveraged in phishing campaigns and mass exploitation because attackers only need to convince users to click a URL. Consequences include:
- Session cookie or token theft (if cookies/tokens lack proper protections).
- Actions performed in the victim’s browser (e.g., admin actions if an authenticated user is targeted).
- Credential-phishing overlays or fake forms to harvest data.
- Silent redirects to malicious landing pages or malware distribution chains.
How the vulnerability is typically exploited (high level)
- Attacker crafts a URL containing malicious input in a query parameter or path component.
- The vulnerable plugin reflects that input into an HTML response without escaping.
- The attacker convinces a user to open the URL (email, ad, forum, etc.).
- The injected script executes in the context of the vulnerable domain and performs malicious actions.
Immediate actions for site owners — checklist (first 24–72 hours)
- Inventory
- Identify all sites using the Premmerce Product Filter for WooCommerce plugin.
- Confirm plugin versions; treat any site running ≤ 3.7.3 as vulnerable until patched.
- Prioritise high-traffic and e-commerce sites for remediation.
- Temporary plugin action
- If a patched release is available, update after testing on staging.
- If you cannot update immediately, consider deactivating the plugin until mitigations are in place.
- If disabling breaks critical functionality, use targeted server-side mitigations and input sanitization.
- Apply targeted virtual patching
- Deploy host-level or edge rules to block obvious exploit patterns in query strings and POST data aimed at filter endpoints.
- Block requests that include script-like payloads (script tags, event attributes, javascript: URIs) scoped narrowly to the plugin’s URL paths or parameters.
- Harden front-end protections
- Implement or strengthen Content Security Policy (CSP) to limit inline script execution and restrict remote script sources.
- Ensure cookies use Secure, HttpOnly, and SameSite attributes where appropriate.
- Monitor logs
- Search webserver and WAF logs for suspicious query strings or unusual encoded characters.
- Monitor for spikes in 4xx/5xx responses and new, unique query parameters.
- Watch customer reports of redirects, popups, or unexpected prompts.
- Cleanup and response
- If compromise is suspected, preserve logs and snapshots before remediation.
- Rotate admin passwords and API keys if necessary.
Detection and forensics: what to look for
- Web access logs: look for GET/POST requests with encoded characters such as %3C, %3E or long query strings containing tags.
- WAF logs: blocked rule hits or probing patterns aimed at product-filter URLs.
- Error logs: template warnings or unexpected processing errors during requests.
- Page source monitoring: append a benign token like ?test_token=hksec-abc123 and check if it is reflected unescaped in the HTML.
- Analytics: spikes in bounce rate, immediate outbound redirects, or unusual session behaviour.
- User reports: customers reporting popups, redirects, or fake login prompts.
Technical mitigation strategies
Below are defensive actions ordered by ease and likely effectiveness.
1. Update the plugin (primary mitigation)
Apply the vendor patch as soon as a fixed release is available. Follow your standard staging -> production update procedures and then verify the vulnerable endpoints no longer reflect input unescaped.
2. Disable the plugin (quick and safe)
If the product filter is non-essential, deactivating it removes the immediate attack surface.
3. Virtual patching with host or edge rules
Apply request-sanitisation rules to block suspicious payloads in query strings and form data aimed at the product filter endpoints. Example heuristics (tune and scope them narrowly):