The CVSS 6.5 assigned to this stored XSS is misleading in a way that matters for prioritization. The score treats 'subscriber' as a ceiling on impact—when it's actually just the injection point. In a stored XSS scenario, the privilege of whoever injects the payload has almost no bearing on who suffers the execution. A subscriber drops malicious JavaScript into content; an editor, author, or administrator views that content and silently executes it. The victim population is decoupled from the injector, and the CVSS framework doesn't model this separation.

In a WordPress context, the downstream consequence is severe. When that compromised session belongs to a user with admin privileges, the attacker gains access to the plugin installer, theme editor, user role management, and potentially database credentials in wp-config. The XSS isn't the terminal event—it's the delivery mechanism for session hijacking that unlocks the entire deployment. CVSS was designed for infrastructure vulnerabilities where attacker and victim are the same actor at the same time. Stored XSS in a CMS breaks that model fundamentally: time separates injection from execution, and privilege separates injector from victim.

The EPSS score of 0.00211 compounds the problem. It suggests low exploitation probability, but EPSS measures likelihood of mass scanning, not impact severity. An abandoned plugin with no patch on the horizon—version 3.0.6 shows no remediation activity—means the temporal metric assumptions in CVSS collapse entirely. The framework assumes patches arrive; here they won't. You're not managing a vulnerability until next quarter's update cycle. You're managing an open door that will never close through official channels.

Treat this as a high-severity finding regardless of the 6.5 score. Verify whether the plugin is actively maintained, audit what user roles can create or edit content that renders across the site, and treat any stored XSS in a CMS as a potential admin session harvest with full backend access following within minutes. The historical pattern is consistent: conservatively-scored stored XSS in abandoned WordPress plugins gets exploited through watering-hole campaigns where attackers monitor disclosure feeds, identify unpatched sites, and harvest admin sessions at scale. The score provides false comfort; the exploitation record does not.