Recommended immediate actions (site owners)

1. Update the plugin now. The vendor fixed the issue in version 6.4.8 — updating removes the flawed behaviour.
2. If you cannot update immediately:
   • Apply temporary WAF/virtual patching rules to block suspicious POST payloads to compare endpoints that contain script tags or event attributes (e.g.,
   • Sanitise or reject submissions to compare-related fields that contain HTML/event attributes or encoded script tokens.
3. Audit contributor accounts. Check for unexpected registrations, recent edits, last-login times and IP addresses; disable or reset credentials for suspicious accounts.
4. Harden registration and credential policies: email verification, CAPTCHA, block disposable emails, and require stronger password rules. Enforce 2FA for accounts with elevated privileges where possible.
5. Scan the database and filesystem. Search for injected scripts in product titles, descriptions and plugin-specific metadata and remove malicious payloads.
6. Implement or tighten a Content Security Policy (CSP) to reduce the impact of inline scripts. Use report-only mode first to avoid breaking functionality.
7. Take a fresh backup before remediation and monitor logs closely for repeated exploitation attempts.

Mitigation strategy — prevent, detect, respond

Use layered controls rather than relying on a single mechanism.

Prevent

• Update plugins and themes promptly.
• Validate and sanitise user input at the server-side; do not rely on client-side checks alone.
• Apply WAF/virtual patches to block known payload patterns while you update. Target POST endpoints used by the compare feature and inspect request bodies for script/event markers or encoded equivalents.
• Limit who can create or edit compare items — apply least privilege.

Detect

• Schedule DB scans for script tags and event-handler attributes in product-related fields and plugin meta.
• Monitor application logs for POST activity to compare endpoints from low-privilege accounts.
• Alert on sudden content changes by multiple low-privilege accounts or by accounts with unusual IPs.

Respond

• When suspicious activity is detected, quarantine or disable offending accounts and remove or neutralise stored payloads immediately.
• Use targeted WAF blocks to stop further exploit attempts while cleaning the site.
• Document scope, mitigation steps and timeline for forensic review and follow-up hardening.

Practical detection queries and scans

Examples to help enumerate likely affected areas:

-- Check product short descriptions
SELECT ID, post_title FROM wp_posts
WHERE post_type = 'product' AND (post_excerpt LIKE '%

1. Sanitise input server-side:
   • Validate expected data types and permitted characters.
   • If HTML is permitted, use an allowlist (e.g., wp_kses) with explicit allowed tags and attributes — do not allow script tags or event-handler attributes.
2. Escape output for the target context:
   • For HTML text nodes use esc_html(); for attributes use esc_attr().
   • When injecting data into JavaScript context, use wp_json_encode() or esc_js() to safely encode values.
   • Avoid printing raw user strings directly into innerHTML or inline ', wp_json_encode($data) );

     Incident response playbook (if you find active exploitation)

     1. Contain
        • Temporarily disable or unpublish the vulnerable plugin if immediate patching is not possible.
        • Block offending payloads or IPs at the edge using WAF rules.
     2. Identify scope
        • Enumerate stored payloads with DB queries.
        • Review server logs for suspicious POSTs and edit histories by contributor accounts.
     3. Eradicate payloads
        • Remove malicious entries manually or with safe scripted cleaning. Replace with neutral placeholders where appropriate.
     4. Recover
        • Restore from clean backups if necessary and update the plugin to 6.4.8+.
        • Update all other plugins, themes and core.
     5. Post-incident
        • Rotate credentials for affected users, enforce 2FA for privileged roles, and review site role assignments.
        • Implement continuous monitoring and file integrity checks going forward.

     Long-term hardening checklist

     • Maintain an up-to-date plugin inventory and patch schedule.
     • Minimise users with publish/edit privileges; follow least privilege.
     • Enforce strong authentication (password policy, 2FA for elevated roles).
     • Use WAF and virtual patching for rapid short-term protection windows.
     • Run periodic DB scans for script tags and suspicious HTML.
     • Adopt CSP gradually (start with report-only) to reduce inline script risks.
     • Keep regular backups and test restores.

     Example: step-by-step actions for site owners

     1. Verify plugin version. If ≤ 6.4.7, plan to update to 6.4.8 immediately.
     2. If you cannot update immediately:
        • Apply WAF rules blocking script tags and event attributes in compare endpoints.
        • Temporarily restrict new contributor registrations and disable suspicious accounts.
     3. Scan the DB for script tags and remove malicious payloads.
     4. Review contributor accounts created or modified in the last 90 days; investigate IPs and behaviour.
     5. Force password resets for suspect contributor accounts and enable 2FA for higher-privilege users.
     6. After updating, re-scan and monitor logs for repeat attempts.

     Sample WAF rule ideas (non-executable)

     • Block POST requests to known compare endpoints where the body contains “
     • Alert on responses that contain unescaped user-controlled values inside inline
       Review My Order

       0

       Subtotal

       Taxes & shipping calculated at checkout

       Checkout