WPBakery Page Builder <= 8.6.1 — Stored XSS in Custom JS Module (CVE-2025-11160)

Summary: A stored Cross-Site Scripting (XSS) issue affects WPBakery Page Builder versions up to and including 8.6.1. The vector is the plugin’s Custom JS module and the flaw can be exploited by an authenticated user with Contributor-level privileges. The vendor released a fix in version 8.7. This write-up — written with a Hong Kong security professional’s focus on clarity and practicality — explains how the issue works, who is at risk, how to detect and remove payloads, and what immediate mitigations to apply.

• Vulnerability: Stored XSS in WPBakery Custom JS module
• Affected versions: WPBakery <= 8.6.1
• Fixed in: WPBakery 8.7
• CVE: CVE-2025-11160
• Required privilege: Contributor (authenticated)
• Reported CVSS: 6.5 (context-dependent)
• Primary impact: Persistent JavaScript execution in visitors’ and potentially admins’ browsers (cookie theft, redirects, persistent defacement, pivoting)

What is Stored XSS and why it matters for WordPress

Stored XSS occurs when an attacker stores malicious JavaScript on the site (in posts, postmeta, widgets, or plugin-managed fields) and the site later serves that content without proper output encoding. The payload executes whenever anyone (including administrators) views the affected page.

Why WordPress sites are high-value targets:

• Admin-facing pages and previews can execute the payload, enabling credential theft or session capture.
• Persistent scripts can add backdoors, inject SEO spam, or perform redirects and content manipulation.
• Sites with user registration or contributor workflows are especially vulnerable because a low-privilege account is sufficient to store payloads.

In this case the plugin exposes a Custom JS module intended for legitimate front-end scripts; inadequate input constraints and sanitisation allow a contributor to persist a malicious script that will be executed in visitors’ browsers.

Technical overview: how this WPBakery vulnerability works

• The Custom JS module stores content in the database (shortcode, postmeta or plugin-specific storage).
• Input from contributor-level users is not properly constrained or sanitised before being saved and later rendered.
• A malicious contributor can inject JavaScript that is stored and later returned to any visitor who views the page.

Likely attack scenarios:

• Steal admin cookies or session tokens when an administrator previews or visits an infected page and then exfiltrate them to an external server.
• Perform persistent redirects to attacker domains, load external malware, or insert spam links.
• Use DOM manipulation to capture form submissions or escalate to additional actions via the REST API or AJAX calls.

Note: The exploit requires at least a Contributor account. Many sites allow registrations or have weak verification — that is the usual path for attackers.

Who is at risk?

• Sites running WPBakery Page Builder ≤ 8.6.1.
• Sites permitting user registration or accepting content from untrusted contributors.
• Multi-author blogs and community or membership sites that allow contributor roles.
• Any site where admins preview pages while logged in (a common practice).

Even with a moderate CVSS, a single exposed contributor-enabled site can lead to a serious compromise if an admin is targeted.

Immediate actions (first 1–2 hours)

1. Confirm plugin version

   Dashboard: Plugins > Installed Plugins and verify WPBakery version.

   WP-CLI:

   wp plugin list --format=csv | grep js_composer || wp plugin get js_composer --field=version

2. Update to 8.7+ if you can

   If allowed by your license and compatibility matrix, update via Dashboard or WP-CLI:

   wp plugin update js_composer --clear-plugins-cache

   If you cannot update immediately, apply virtual patching (see WAF advice below) while you schedule the update.

3. Limit contributor access temporarily

   Remove or restrict the Contributor role until you can update and scan. Remove the capability to add custom JS modules for low-privilege roles.

4. Scan for injected <script> tags and suspicious JS in content

   Search posts and postmeta for script tags or common indicators. Take care and back up before modifying data.

   SELECT ID, post_title, post_type
   FROM wp_posts
   WHERE post_content LIKE '%<script%';

   SELECT post_id, meta_key, meta_value
   FROM wp_postmeta
   WHERE meta_value LIKE '%<script%';

   wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 50;"

   Also search for patterns like onerror=, onclick=, innerHTML=, document.cookie, eval(, or obfuscated base64 strings.

5. Consider limited-access maintenance mode

   If you suspect active exploitation, temporarily restrict public access while investigating.

6. Take a fresh backup

   Create an archival backup (files + DB) before removing content so you retain a forensic copy.

Detecting injected payloads (useful queries & patterns)

Common indicators:

• Script tags: <script> … </script>
• Inline event handlers: onerror=, onclick=, onload=
• APIs and functions used in theft/exfiltration: document.cookie, XMLHttpRequest, fetch, new Image()
• Obfuscation: base64, eval(atob(...)), long encoded strings

Database search examples (escape special characters carefully):

SELECT ID, post_title
FROM wp_posts
WHERE post_content REGEXP '<script|onerror=|document\\.cookie|eval\\(|atob\\(';

SELECT post_id, meta_key
FROM wp_postmeta
WHERE meta_value REGEXP '<script|onerror=|document\\.cookie|eval\\(|atob\\(';

WP-CLI / file scanning examples:

wp db export - | grep -iE '<script|onerror=|document\.cookie|eval\(|atob\('

grep -R --line-number -E "<script|document\.cookie|eval|atob|new Image\(|fetch\(" wp-content

If you find matches, document each affected post ID and meta key, export snapshots, and keep forensic copies before modifying content.

Containment & cleanup (detailed steps)

1. Backup and snapshot: Preserve the current DB and file system for analysis.
2. Remove or neutralise malicious entries:
   • For script tags in post content, remove offending <script> blocks and save the cleaned content.
   • For plugin-managed storage (postmeta), update meta_value to safe content or delete malicious meta rows.

   Example WP-CLI approach (use carefully and verify before running):

   # Example — adapt to your environment. This replaces a specific malicious pattern.
   wp post update 123 --post_content="$(wp post get 123 --field=post_content | sed 's/<script>malicious.*</script>//g')"

3. Rotate credentials: Reset passwords for any accounts that may have been used to inject content.
4. Force password resets: Require all admins and editors to reset passwords if suspicious activity is present.
5. Manual inspection of plugins/themes: Review any plugin or theme that permits storing JavaScript; prioritise manual code review for such components.
6. Harden registrations and roles:
   • Disable open registration if not required.
   • Convert unverified contributor accounts to safer roles or suspend them.
   • Use approval-based workflows for user-generated content.
7. Review server logs: Look for POST requests to admin-ajax.php, REST API endpoints, or other content endpoints near the time malicious content appeared.
8. Restore if needed: If the infection breadth is unclear, restore from a known-clean backup, update to the fixed plugin version, and reintroduce content after scanning.

Short-term mitigation with a managed WAF (virtual patching)

If updating immediately is not possible, virtual patching via a web application firewall (WAF) can reduce exposure. The purpose is to block exploit attempts and known payload patterns until you can update and clean the site.

Conceptual WAF rule examples (implement via your WAF or gateway):

1. Block POST requests to admin endpoints where the body contains suspicious tokens like <script, document.cookie, eval(, atob(, new Image(, or fetch(. Return HTTP 403 for matches from non-admin users.
2. Prevent contributors from submitting content that includes script tags or inline event handlers. If request originates from a user role below Editor and contains <script or onerror=, block the request.
3. Filter out inline event attributes (onerror=, onclick=, onload=, innerHTML=) in submission payloads from low-privilege roles.
4. Rate-limit or block suspicious POST submissions to admin endpoints from unknown or anonymised IPs.
5. Where feasible, deploy a Content Security Policy (CSP) to reduce impact of inline scripts (note: CSP may break legitimate inline JS, test before rolling out):

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.example; object-src 'none'; base-uri 'self';

Why virtual patching is effective: If the stored payload is blocked at submission time or blocked in transit, the persistent exploit chain is interrupted. However, virtual patching is a temporary control — update and clean as soon as possible.

Hardening and long-term prevention

• Keep WordPress core, themes and plugins updated.
• Apply the principle of least privilege — limit who can add or edit content and restrict capabilities that allow raw JS editing.
• Use moderation/approval workflows for user-submitted content.
• Sanitise output at the theme level — use escaping functions (wp_kses, esc_js, esc_html) where appropriate.
• Consider CSP with nonces for admin areas to reduce inline script risk.
• Audit plugins for any feature that stores or renders raw JavaScript or HTML and restrict their usage.
• Require multi-factor authentication (MFA) for admin and editor accounts.
• Monitor logs and set alerts for suspicious changes (new postmeta entries with script tags; new users that immediately create content containing scripts).
• Document an incident response plan: backup, isolate, restore, notify.

Incident response checklist (for suspected compromise)

1. Isolate the site (maintenance mode / IP restriction).
2. Take full backups and forensic copies (DB + file system).
3. Identify and remove injected malicious content.
4. Rotate credentials and force password resets.
5. Review recently added users and remove untrusted accounts.
6. Scan for additional backdoors in themes, plugins and uploads.
7. Compare site files to known-good copies where available.
8. Update all software to fixed versions.
9. Restore from a clean backup if contamination is widespread.
10. Notify stakeholders and follow jurisdictional legal obligations if required.

Why this vulnerability should not be downplayed

Context matters. A simple brochure site with no contributor accounts is at lower risk. But any site that accepts contributions, has open registration, or allows unvetted user input is at material risk. Stored XSS can lead to admin session theft; once an admin is compromised, the attacker can take full control.

Monitoring & detection: what to log and watch

• Log and alert on POSTs to admin-ajax.php, REST endpoints and other admin endpoints containing <script.
• Monitor changes to postmeta and post_content for script tags.
• Alert when new users register and then quickly create or edit posts with embedded scripts.
• Watch for outgoing requests from the site to unknown external domains originating from cron jobs or PHP processes.
• Keep WAF logs for blocked attempts and review them for attacker patterns and repeat offenders.

How managed WAFs and professional services can help (neutral guidance)

Where available, a managed WAF or security service can provide temporary virtual patching, behavioural detection, and content scanning to reduce exposure while you update and clean the site. Typical managed capabilities include:

• Rapid deployment of targeted rules to block known payload signatures and suspicious submission patterns.
• Monitoring for content-submission anomalies from low-privilege accounts.
• Content scanning across posts, postmeta and uploads to identify stored script tags and known XSS indicators.
• Guidance on remediation and tuning rules to reduce false positives.

Note: Use impartial evaluation when choosing any managed service. Verify the provider’s experience with WordPress-specific threats and insist on reversible, well-documented changes and logs for forensic purposes.

Practical example: conceptual WAF rule

Conceptual rule (adapt and test for your environment):

• Condition: Request path contains /wp-admin/ or /wp-json/wp/v2/ or admin-ajax.php, AND request body contains one of <script, onerror=, document.cookie, eval(, atob(.
• AND requester is not a trusted admin IP (or the user role is Contributor).
• Action: Return HTTP 403 and log the request.

CAUTION: Do not block all scripts without reviewing legitimate needs. Test rules in monitoring mode first and tune to reduce false positives.

Step-by-step update & remediation plan for site owners

1. Immediate check (0–1 hour): Confirm WPBakery version. If <= 8.6.1, consider maintenance mode if high-risk.
2. Virtual patch (0–4 hours): Deploy targeted WAF rules or equivalent filters to block script-like payloads from non-admin users; consider CSP for inline script suppression where feasible.
3. Update (0–24 hours): Update WPBakery to 8.7+ and update other plugins/core while monitoring compatibility.
4. Clean (0–48 hours): Run DB & file scans, remove or sanitise malicious content after backing up, rotate passwords and review user activity.
5. Harden (48–72 hours): Enforce MFA, reduce Contributor capabilities, set continuous monitoring and alerting.
6. Post-incident review: Document timeline, root cause and corrective actions. Update policies for registration, moderation and plugin vetting.

Frequently asked questions

Q: If my site doesn’t have contributor accounts, am I safe?
A: Risk is lower but not zero. Confirm plugin version and update regardless. Other plugins or workflows may expose similar functionality to other roles.

Q: Can a WAF break WPBakery functionality?
A: Overly broad rules can. Use targeted rules that block known malicious patterns or submissions from low-privilege users. Test rules in monitoring mode before enforcement.

Q: My site was injected — how long will remediation take?
A: Depends on scope. Single-post cleanups can take minutes; deep infections with backdoors can require 24–72 hours of forensic cleaning and testing.

Final words — prioritise update and defence-in-depth

This WPBakery stored XSS is a reminder that features allowing JavaScript must be strictly controlled. The vendor fix (8.7) addresses the immediate bug; follow these priorities:

• Update promptly to the fixed version.
• Limit and monitor the ability to add script-like content from low-privilege accounts.
• Apply temporary virtual patching (WAF/gateway) if you cannot update immediately.
• Scan and clean stored content thoroughly.
• Enforce least privilege for account roles and use MFA for privileged accounts.

If you need external assistance, choose an experienced, transparent provider and require clear logs and reversible actions. Keep incident response plans current and test them periodically.

— Hong Kong Security Expert