WPBakery Page Builder <= 8.6.1 — Stored XSS via Custom JS Module (CVE-2025-11160): What site owners must do now

Intro

A stored Cross‑Site Scripting (XSS) vulnerability affecting WPBakery Page Builder (versions ≤ 8.6.1) was disclosed as CVE-2025-11160. An attacker with limited privileges can inject JavaScript that is later executed in visitors’ browsers. Sites that allow contributor-level or similar accounts to create or edit content are exposed.

From a Hong Kong security expert perspective, this report explains how the issue works, who is affected, and practical, immediate actions you can take: patching, configuration changes, content detection/cleanup, and virtual patching concepts with generic WAF guidance.

Executive summary

• Affected software: WPBakery Page Builder plugin (≤ 8.6.1)
• Vulnerability: Stored Cross‑Site Scripting (XSS) via the plugin’s Custom JS module
• CVE: CVE‑2025‑11160
• Fixed in: 8.7 (upgrade immediately where possible)
• Required privilege for exploitation (reported): Contributor (or equivalent low‑level editor)
• Risk: Attackers who can create or edit page builder content can store JavaScript payloads that run in visitors’ browsers (redirects, cookie theft, session hijacking, distribution of malicious content).
• Immediate mitigation: Upgrade to 8.7+, restrict access to Custom JS modules, search/clean site content, apply WAF/virtual patching rules to block script injection.

How this vulnerability works (plain explanation)

Stored XSS arises when untrusted input is saved and later rendered without proper sanitization or output encoding. Here, the plugin’s “Custom JS” module permitted JS content to be saved by contributors and included in page templates on the front end. Because the content could include raw JavaScript or DOM event attributes, visitors to an affected page would execute the attacker‑provided code. The only privilege required is the ability to add or edit that custom module, typically available to contributor/author roles.

Why stored XSS is dangerous

Stored XSS is particularly severe because malicious code persists on the site and executes for every visitor of an infected page. Typical consequences include:

• Session cookie theft and account takeover (when cookies are not properly secured)
• Silent redirects to malicious domains
• SEO spam and unauthorized content injection
• Browser‑based cryptomining or ad fraud
• Secondary attacks and persistence (backdoors, privilege escalation)

Understanding impact and severity

CVE‑2025‑11160 is fixed in 8.7. Some assessments placed the CVSS around 6.5. Numeric scores are useful, but real‑world risk depends on context:

• High‑traffic pages using Custom JS increase exposure.
• Poor account hygiene (shared passwords, no MFA) raises exploit likelihood.
• Visitor population that includes privileged users (editors, admins) can increase impact.

Given the common use of contributor/author accounts for content management, respond quickly.

Immediate actions (step‑by‑step)

1. Update WPBakery Page Builder to 8.7 or later.

   This is the definitive fix. Upgrade via WordPress admin or your deployment process as soon as possible. If immediate upgrades are impossible (compatibility testing, large fleets), apply the mitigations below.

2. Restrict access to the “Custom JS” functionality.

   Temporarily revoke contributor/author access to modules that allow Custom JS. If you use role managers, remove capabilities for non‑trusted roles to edit page builder modules.

3. Scan the site for malicious scripts and suspicious content.

   Search for script tags and common XSS patterns in posts, pages, postmeta, and page builder stored data (examples below).

4. Apply WAF/virtual‑patching rules.

   Implement rules that block requests attempting to inject

   Review My Order

   0

   Subtotal

   Taxes & shipping calculated at checkout

   Checkout