| Plugin Name | WPBakery Page Builder |
|---|---|
| Type of Vulnerability | Stored XSS |
| CVE Number | CVE-2025-11161 |
| Urgency | Low |
| CVE Publish Date | 2025-10-15 |
| Source URL | CVE-2025-11161 |
WPBakery Page Builder (≤ 8.6.1) — Stored XSS via vc_custom_heading Shortcode (CVE-2025-11161)
Summary — A stored Cross-Site Scripting (XSS) vulnerability (CVE-2025-11161) affecting WPBakery Page Builder versions up to and including 8.6.1 has been published. It allows a contributor-level user to inject persistent script/HTML via the
vc_custom_headingshortcode. The issue was fixed in WPBakery version 8.7. If you cannot update immediately, well-designed response and content hardening or virtual-patching measures can mitigate exploitation risk.
Introduction
If you operate WordPress sites that use WPBakery Page Builder, this advisory is relevant. This report is written from the perspective of a Hong Kong-based security practitioner to explain the risk, likely impact, detection approaches, and practical steps to protect your sites. The guidance below is pragmatic and focused on actions site owners, administrators and technical operators can take quickly.
The vulnerability in one sentence
- Vulnerability: Stored Cross-Site Scripting (XSS) via the
vc_custom_headingshortcode. - Product: WPBakery Page Builder (plugin).
- Affected versions: ≤ 8.6.1
- Fixed in: 8.7
- CVE: CVE-2025-11161
- Reported CVSS: 6.5 (moderate)
- Required privilege: Contributor (able to create or edit content)
What is stored XSS and why this matters
Cross-Site Scripting (XSS) allows an attacker to inject JavaScript or active content that runs in the browser of site visitors or administrators. Stored (persistent) XSS means the malicious input is saved on the server — for example inside post content, shortcodes, or metadata — and executes whenever a page containing the payload is viewed.
Consequences of stored XSS can include:
- Session theft (if cookies or tokens are accessible to script)
- Privilege escalation via automated actions performed in the context of an authenticated user
- Content defacement, malicious redirects, or delivery of phishing/malware content
- Abuse for ad injection, SEO poisoning, or broader site compromise
The specifics of this WPBakery issue
Public advisories indicate WPBakery Page Builder’s handling of the vc_custom_heading shortcode allowed untrusted HTML or attributes to be stored and later rendered without adequate sanitization. A contributor-level user could craft shortcode content including malicious markup or event attributes that the plugin failed to properly sanitize or encode before output.
- Exploitability: contributor-level access is sufficient on affected sites.
- Persistence: payloads are stored within content and remain until removed or sanitized.
- Fix: upstream patch in WPBakery 8.7 corrects the sanitization/rendering behaviour.
Exploit scenarios to consider
- Malicious contributor or compromised contributor account: an attacker submits a post with
vc_custom_headingcontaining malicious markup. Visitors and staff viewing the post execute the injected script. - Compromised editor/admin via social engineering: convincing an editor to preview content may trigger a payload.
- Automated scanning and mass injection: opportunistic actors scan for WPBakery installations and inject payloads to monetise or expand access.
- Theme or template rendering: templates or widgets that render shortcodes site-wide can expose many pages to the payload.
Risk factors that increase likelihood
- Allowing external contributor publishing without strict review.
- Running plugin versions ≤ 8.6.1.
- Absence of response controls that inspect incoming content or outgoing HTML.
- Weak administrative credentials and missing multi-factor authentication.
Immediate steps to protect your site (short checklist)
- Upgrade WPBakery Page Builder to 8.7 (or the latest) as soon as feasible.
- If you cannot update immediately:
- Apply content inspection measures to block or sanitize
vc_custom_headingsubmissions and front-end rendering of script-like content in attributes. - Restrict contributor capabilities — require editor review or disable contributor publishing.
- Review recent posts, revisions, and custom headings for unexpected markup such as
,on*attributes,javascript:,data:URIs, or suspicious base64 payloads.
- Apply content inspection measures to block or sanitize
- Rotate credentials for accounts that may have authored recent content.
- Enforce two-factor authentication and strong password policies for admin/editor accounts.
- Monitor logs for suspicious POSTs to endpoints such as
post-new.php,post.php,admin-ajax.php, and REST endpoints that accept content.
Why updating to 8.7 is the canonical fix
The vendor patch in 8.7 changes how vc_custom_heading is sanitized and rendered. Updating removes the underlying coding error so the plugin does not output untrusted content. While updates do not automatically clean already-injected payloads in existing posts, they prevent further exploitation through the same vector.
If updating is delayed — response measures and virtual patching
Operational constraints (staging, testing, compatibility) may delay updates. In those cases, consider implementing content inspection and response-layer mitigations to reduce risk until you can patch:
- Block or challenge requests that attempt to submit content with suspicious shortcode payloads.
- Sanitize or neutralize dangerous attributes and tags on the response before serving pages that include
vc_custom_heading. - Remove or neutralize
on*event attributes,tags, and pseudo-protocols such asjavascript:ordata:URIs in rendered HTML.
Example virtual-patch rules (conceptual)
These patterns are illustrative and must be tested before deployment: