The CVSS of 6.4 on CVE-2026-2357 badly misrepresents the actual risk profile here, and the EPSS score of 0.00187 doesn't tell the whole story either. The standard models are measuring the wrong blast radius.
This is a stored XSS in the Bold Page Builder shortcode handler, specifically in how user-supplied attributes are processed and output. The vulnerability lives in the gap between what the shortcode API provides (raw attribute arrays) and what developers must manually do (sanitize on output). In this case, the fix in version 5.6.9 added the missing esc_attr() call — a single escaping function that was overlooked in attribute handling code that likely shipped years ago and sat untouched as WordPress's security standards evolved around it.
The contributor-level access requirement is doing work in the threat model that the CVSS vector doesn't weight granularly. You're not attacking site visitors — you're attacking the editorial review workflow. The XSS payload fires when an editor or admin opens a draft for review, not when the public views a page. That's a credential-harvesting machine aimed at the highest-value accounts in the installation: the people who approve content.
This reframes the EPSS prediction as well. The low score reflects that automated, opportunistic exploitation is impractical — you can't spray-and-pray this. But the "low-and-slow persistence" strategy that this vulnerability enables is precisely what temporal scoring models structurally underweight. An attacker with contributor access can inject payloads into dozens of drafts across multiple content types and wait. Automated threat intelligence pipelines optimized for opportunistic attacks will miss this entirely.
The "all versions up to 5.6.8" language in the advisory is a forensic signal: broad version sweeps typically indicate either an internal audit with no historical timeline worth mapping, or code that persisted so long that backporting to every interim release would be impractical. Either way, it suggests this handler sat in "sediment layer" code — shipped, forgotten, unmaintained — rather than recent development.
What to do: prioritize patching this in installations where contributors have editorial access, but also treat the editorial workflow itself as the detonation surface. Warn editors and admins reviewing drafts to be cautious with unexpected content, even from known contributors. Consider whether your WordPress deployment has non-standard role configurations — multisite installations, role-editor plugins, or custom capability setups can lower the privilege threshold below the vanilla "contributor" assumption that the CVE likely models. The CVSS says medium-severity. The actual risk is a targeted credential-harvesting vector against your most privileged users, and the EPSS is optimized for opportunistic attacks, not targeted ones.