CVE-2026-17161

This is a stored XSS vulnerability in the WowStore plugin stemming from a fundamental mismatch between where Gutenberg block developers intuitively apply sanitization and where it actually needs to occur. The plugin developer added wp_kses_post sanitization at save-time, which is the standard WordPress security instinct — but it's the wrong layer for this architecture. Gutenberg stores block content inside HTML comments as JSON attributes. When wp_kses_post runs during save, it sanitizes the outer HTML comment shell, not the raw attribute values nested inside. Those attributes get extracted later during server-side rendering via the block's render_callback function, and that's where the payload becomes executable. The sanitizer never sees the data in the context where it causes harm. The exploitation path is straightforward: a contributor-level user (or anyone with post-edit access) inserts malicious JavaScript into a block attribute — typically through a custom attribute field or by manipulating the JSON stored within the HTML comment. Because Gutenberg treats these attributes as trusted input at render-time, the payload executes when the page is viewed. This is a privilege escalation vector: contributors normally cannot publish content without editorial review, but injected JavaScript runs immediately for every visitor to the affected page. The fix must be applied at render-time inside the render_callback function, not at save-time. Any attribute values that will be output as HTML must be properly escaped using context-appropriate functions (esc_attr for HTML attributes, esc_html for text content, or wp_kses if you're rendering rich content). Schema-level type enforcement during block registration provides an additional layer of defense but is not a substitute for render-time escaping. What makes this significant is that it's not a one-off developer error — it's a predictable consequence of Gutenberg's architecture. The HTML-comment-delimiter-to-JSON-extraction-to-server-render data flow creates a serialization boundary that standard WordPress sanitization functions weren't designed to cross. If you're auditing other Gutenberg block plugins, look for this pattern: save-time sanitization on blocks that render via server-side callbacks. The likelihood of finding the same vulnerability class is high, and the blast radius extends beyond the individual plugin since contributor accounts can leverage it to execute code in the context of every visitor to injected pages.

Reviewed through automated stages and approved by a human before publication.