This CVE exposes a fundamental misunderstanding in how WordPress developers evaluate risk from low-privilege users. The vulnerability is a stored XSS in a custom post type where contributors can submit posts, and the plugin outputs post meta directly into HTML attributes without escaping. The critical error is assuming that unpublished content from restricted roles is safe to handle without sanitization.
The security failure isn't in the missing esc_attr() call—it's in the threat model that made the developer believe that call was unnecessary. WordPress's capability system tells you who can trigger an action, but it's silent on who ends up as the victim. Contributors cannot publish—this is true. But every draft they create enters an administrator's review queue, guaranteeing that someone with elevated privileges will render that payload in their browser. The security boundary that limits Contributors is simultaneously the pipeline that delivers their payload to an Admin.
This isn't a new pattern. The Contributor-to-Admin stored XSS vector has appeared in dozens of WordPress plugin CVEs. The ecological failure is that developers keep treating 'draft' as a containment boundary rather than a delivery mechanism. WordPress's API design compounds this: get_post_meta() returns raw values, placing the escaping burden entirely on the output call. The convenience prioritizes developer speed over security, and that design choice has generated a lineage of vulnerabilities spanning years.
What you should check: review any plugin code that outputs post meta in admin contexts—particularly in custom post type settings or meta boxes. Even if the data originates from your own admin UI, treat it as untrusted the moment it flows through get_post_meta() into an HTML attribute. The victim population for contributor-submitted drafts isn't random site visitors; it's your administrators, and the attack requires no phishing or coercion—WordPress delivers the payload for them.