TL;DR (If you only read one thing)

• A stored XSS in Beaver Builder (<= 2.10.0.5) can allow stored JavaScript to execute in admin and public contexts when certain global settings are rendered.
• Fix: update Beaver Builder to 2.10.0.6 immediately (or the next available release that contains the patch).
• If you cannot immediately update, apply mitigations: restrict access to Beaver Builder settings, audit custom roles and capabilities, and enable virtual patching/WAF rules that block script-like input to plugin settings endpoints.
• Use a layered approach: patching + principle of least privilege + WAF/edge rules + scanning + monitoring.

What happened (plain language)

Researchers found that Beaver Builder’s handling of global settings allowed authenticated users (with certain custom roles) to save content that was not properly authorised or sanitised. That saved content could include HTML/JavaScript that later gets rendered and executed in a browser — a stored cross-site scripting (XSS) vulnerability.

In practice, an attacker needs an account on your site with a role able to modify Beaver Builder global settings. If that account is tricked into performing a benign action (clicking a crafted link or visiting a malicious page), a payload can be stored and will execute whenever an admin or visitor loads a page where those settings are used.

The plugin author has released a fixed version: update to 2.10.0.6 or later.

Quick factsheet

• Affected plugin: Beaver Builder (Page Builder plugin)
• Vulnerable versions: <= 2.10.0.5
• Fixed in: 2.10.0.6
• CVE: CVE-2026-1231
• Vulnerability type: Stored Cross-Site Scripting (XSS)
• CVSS (reported): 6.5 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L)
• Required privilege: a custom role or a role able to modify global Beaver Builder settings (non-public)
• Exploitation requires user interaction and an authenticated account with the relevant capability.

Why this matters to your site

Stored XSS is dangerous because malicious script saved in site settings can affect:

• Administrators and site editors who view the admin screen (risking credential theft via injected UI or hidden elements).
• Site visitors (if the stored payload is rendered on public pages), enabling redirects, form skimming, malware delivery, SEO spam, or defacement.
• Multi-site or agency environments where contributors or third-party accounts might be given elevated access.

Although exploitation requires an authenticated account and user interaction, many sites have weak role separation or use third-party contractors and plugins that create custom roles; these increase exposure.

Technical root cause (concise)

• Missing or insufficient authorization checks allowed modification of global settings.
• Inputs saved into those settings were not properly sanitised/escaped, allowing executable markup (for example,
  Review My Order

  0

  Subtotal

  Taxes & shipping calculated at checkout

  Checkout