CVE-2026-15604
The CVSS 6.4 rating for this stored XSS vulnerability is misleading. The technical architecture reveals a dual failure—raw $_POST values stored without sanitization, then rendered into a style attribute without esc_attr()—that signals something more concerning than a single oversight. This is a two-point systemic failure along the same data pipeline, indicating the codebase lacks a coherent data-handling security model. In the WordPress ecosystem, this pattern isn't coincidental; it's genetic. The post meta API provides zero security friction: update_post_meta() accepts whatever you give it, get_post_meta() returns exactly that, and there's no architectural layer forcing developers to confront sanitization at any point. This has reproduced across hundreds of WordPress plugins over fifteen years—not because developers keep making the same mistake, but because the framework defaults to insecure handling with no friction to prevent it. The style attribute context matters technically. Style attributes receive different browser parsing than HTML element content, and style-based XSS has historically provided exploitation routes when classic script-src vectors are filtered. The admin dashboard compounds this: when stored XSS executes in the admin panel, it detonates in a context where administrators hold active sessions with elevated privileges, where AJAX handlers process administrative actions, and where the attack surface includes user management and plugin configuration. This is categorically different from front-end stored XSS against visitors. The contributor-level access requirement adds a privilege escalation vector that standard WordPress threat models don't anticipate. Contributors are considered low-risk users, but here they can attack administrators through the admin UI—a meaningful escalation path the CVSS metrics don't capture. The EPSS score (0.00193) likely reflects low plugin adoption rather than low exploitability. More concerning is the class-level exposure: when this dual-failure pattern is disclosed, you're publishing a template. Every WordPress plugin with the same data pipeline structure becomes a potential simultaneous target. The exposure window between CVE publication and mass exploitation of copycat vulnerabilities is now measured in days. The real number to track isn't one plugin's patch status—it's the remediation lag across this entire vulnerability class in an ecosystem with no mechanism to force systematic review.
Reviewed through automated stages and approved by a human before publication.