CVE-2026-49466 is a stored XSS in the Draft List plugin where Contributor-role users can inject arbitrary JavaScript via the {{draft}} template placeholder. The vulnerability stems from a fundamental mismatch between what developers assume template syntax means and what the plugin actually does with it.
The critical trap: the plugin uses {{draft}} syntax that mimics Handlebars, Mustache, and other JavaScript templating engines where double-curly braces signal context-aware escaping by default. Developers see this notation and reasonably assume it's safe — that's the cognitive model the syntax itself creates. But Draft List substitutes raw content into templates without context-aware output encoding. When {{draft}} lands inside an HTML attribute versus block content, the escaping requirements differ fundamentally. The plugin sanitizes once at parse-time rather than encoding at render-time based on where the placeholder actually appears.
This parse-time sanitization approach is the real architectural failure. You're applying one context's escaping rules to content that will render in multiple contexts — a bet that never holds. Titles containing quotes are harmless in text nodes but dangerous in attribute values. Pre-replacement sanitization guesses wrong at least half the time.
The privilege model compounds this: Contributors can inject the payload but cannot see the rendered result until a higher-privileged user visits the affected page. This is a known WordPress design gap that's existed for two decades — low-privilege users poisoning output they can't observe. The Contributor doesn't need to guess who visits; the plugin's purpose (surfacing unpublished content) naturally attracts exactly the high-value targets worth targeting: editors, admins, content managers verifying draft visibility.
The CVSS 6.5 understates the real risk. Sites running Draft List have already signaled they value content prominence — the shortcode appears on editorial staging pages by design. A poisoned payload targets the people who need to see those drafts. That's a precision weapon, not generic stored XSS.
Check your deployed templates: any {{draft}} usage inside HTML attributes (href, src, data-*, style) is a confirmed exploitation vector. Even post-patch, verify whether the fix addresses all template configurations or just the reported one — sanitize-at-parse-time patches often leave forgotten configurations as forgotten vulnerabilities. If you rely on custom templates, test each placeholder location exhaustively rather than assuming the patch covers all paths.
The broader pattern here isn't unique to Draft List. At least seven WordPress plugin CVEs in the last decade followed this exact geometry: documented {{variable}} substitution, parse-time sanitization, narrow patch after exploitation. The ecosystem treats each as a novel vulnerability while the underlying failure mode recurs continuously. Until the community treats documented template substitution as a security review trigger rather than a feature checkbox, the next CVE in this line is already in development.