Hong Kong Alert XSS in Bold Builder(CVE202566057)

Cross Site Scripting (XSS) in WordPress Bold Page Builder Plugin






Urgent: Bold Page Builder (<= 5.5.2) — Stored XSS (CVE-2025-66057) — What WordPress Site Owners Must Do Now


Plugin Name Bold Page Builder
Type of Vulnerability Cross-Site Scripting (XSS)
CVE Number CVE-2025-66057
Urgency Low
CVE Publish Date 2025-11-29
Source URL CVE-2025-66057

Urgent: Bold Page Builder (≤ 5.5.2) — Stored XSS (CVE-2025-66057)

Published: 27 November 2025   |   Author: Hong Kong Security Expert

A security researcher disclosed a stored Cross-Site Scripting (XSS) vulnerability affecting Bold Page Builder versions ≤ 5.5.2 (CVE-2025-66057). A low-privilege user (Contributor-level) can inject HTML/JavaScript that is stored and later executed in visitors’ browsers — including administrators. Although vendor fixes are available in 5.5.3, many sites remain unpatched or cannot immediately update due to compatibility concerns. This advisory explains the risk, root cause, detection methods, containment, technical mitigations (including WAF rules and virtual patching examples), and recovery steps in a straightforward, practical manner.

Executive summary — TL;DR

  • Vulnerability: Stored Cross-Site Scripting (XSS) in Bold Page Builder ≤ 5.5.2 (CVE-2025-66057).
  • Impact: Arbitrary JavaScript/HTML injection — possible session theft, account takeover, drive-by redirects, malicious content injection, SEO damage.
  • Privilege required: Contributor (low-level); common in many WordPress sites.
  • CVSS: 6.5 (medium). Labels don’t tell the whole story — contextual risk matters.
  • Immediate action: Update to 5.5.3 or later as soon as practicable. If you can’t update immediately, apply mitigations below (restrict editing, scan content, apply WAF/virtual patching).

Why this XSS matters even if it’s “low priority”

CVSS scores are a triage tool, but stored XSS deserves attention because:

  • Contributor-level accounts are common (guest authors, clients, editors). These accounts may be abused to store persistent payloads.
  • Stored XSS is persistent: payloads sit in the database and are served to anyone who loads the affected page, including admins.
  • Attackers can escalate via cookie theft, session hijacking, or by injecting further destructive content such as redirects or cryptomining scripts.
  • Page builders and custom admin views increase the risk surface: admin screens that render builder content can trigger payloads when editors or admins open them.

Bottom line: treat stored XSS seriously and remediate quickly.

What caused the vulnerability (technical overview)

Stored XSS in page builders typically arises from one or more faults:

  • Unsafe output encoding — user-supplied properties (element attributes, custom HTML blocks) are echoed into pages without proper escaping.
  • Raw HTML elements allowed for low-trust roles — elements that intentionally permit HTML/JS but aren’t restricted to trusted users.
  • Reliance on client-side validation only — no server-side enforcement.
  • Insufficient filtering of event handler attributes (onload, onclick), javascript: URIs, or encoded payloads (base64, hex, unicode).

The public advisory suggests a Contributor could insert payloads that were rendered unsanitized to visitors, indicating missing or insufficient output sanitization.

Who is at risk?

  • Sites running Bold Page Builder ≤ 5.5.2.
  • Sites that allow non-trusted users (Contributors, Authors) to edit content.
  • Sites that accept stored submissions (imported content, plugin-stored content) that are later rendered.
  • Multisite networks with many low-privilege accounts.

If your WordPress site uses Bold Page Builder, assume risk until you verify otherwise.

Immediate mitigation checklist (next 60–120 minutes)

  1. Confirm plugin version:
    • Dashboard → Plugins → Bold Page Builder → check version.
    • Or WP-CLI: wp plugin get bold-page-builder --field=version
  2. If version ≤ 5.5.2, plan to update to 5.5.3 immediately. If you cannot update right away (compatibility testing required), proceed with the mitigations below.
  3. Restrict editing:
    • Temporarily revoke Contributor/Author editing privileges until patched.
    • Disable or restrict any untrusted accounts that can edit content.
  4. Enable WAF / virtual patching:
    • If you have a WAF (hosted or appliance), enable rules to block script tags, event handlers and data/javascript URIs against POSTs that create content.
  5. Scan for injected content:
    • Search the database for