CVE-2026-17090

The CVSS 6.4 score for this Beaver Builder stored XSS obscures a materially wider attack surface than the CVE description implies. Button modules in page builders are disproportionately deployed in site-wide contexts—footers, headers, and shared templates that render on every page load. An author who injects JavaScript into a footer button doesn't have XSS on one isolated page; they have it executing against every visitor, on every page, until that template is edited or the plugin is patched. This is functionally equivalent to a site-wide JavaScript compromise, not a contained stored XSS in a single post. The CVE frames the impact as scripts executing 'on pages that will execute whenever a user accesses an injected page,' which implies a discrete scope. But button modules placed in global templates convert author-level access into a trust boundary violation that WordPress core never anticipated. An editor visiting the homepage gets XSS'd by an author's button in the footer. A subscriber checking their profile page gets XSS'd. The cascade hits every user role that visits those pages—not just the author who injected the script. The practical exploit path extends beyond the nominal scope: author injects button script in a global footer, script executes on every visitor including admins, admin visits any page, session cookies stolen, attacker pivots to admin dashboard. The 'author-level and above' qualifier describes the entry point, not the blast radius. What appears as a 6.4 vulnerability is actually a site-owning pathway that happens to route through a button module. The patch history across page builders—Elementor, Divi, SiteOrigin, now Beaver Builder—shows this isn't an isolated bug but a structural consequence of how page builder UX is designed. These tools must route author input through components that execute in the frontend context, creating a gap between what the plugin promises (design freedom) and what WordPress core assumes (author content is contained to author posts). Beaver Builder's 'improved input sanitization' closes one inheritance path without changing the inheritance mechanism. Future components accepting rich text will face the same structural pressure. Operationally, treat every button module placement as potentially site-wide until proven otherwise. Audit your Beaver Builder installations for button modules in global templates—particularly footers, headers, and shared rows. The CVSS score will remain medium in vulnerability databases long after the operational risk has compounded through disclosure, architectural familiarity, and the inevitable lag between patch availability and deployment. A 'patch and done' remediation misses the manual audit obligation: verify every global template's button module placements, because no automated check confirms the placement context is safe.

Reviewed through automated stages and approved by a human before publication.