CVE-2026-18402

This vulnerability exposes a structural mismatch between WordPress's block editor storage model and developers' mental models of where sanitization should occur. The SureDash plugin stores user-controlled values in HTML comment-delimited JSON blocks—the WordPress-native format for block attributes—then interpolates those values into style attributes at render time without context-aware escaping. The failure is two-stage: wp_kses_post at save-time doesn't catch the payload because it's wrapped in JSON within an HTML comment, which WordPress core treats as a sanitization boundary rather than active content; then at render-time, the developer apparently assumed save-time sanitization was sufficient for an attribute context, or never considered that these JSON-stored values would flow into a style attribute at all. The contributor-level requirement is less constraining than it appears. In collaborative WordPress environments with SSO-provisioned accounts or tiered membership, contributor access is often granted liberally—and the injected scripts execute for all users including admins reviewing content. An admin viewing a contributor's draft assumes they're seeing sanitized output; they are not. This isn't just privilege escalation in the technical sense—it's a bypass of the trust boundary that capability models rely on, where admin review before publication is architecturally circumvented by pre-approval execution. The fix is trivially simple: one esc_attr() call. That simplicity is itself informative. It suggests either no security review of the block rendering path ever occurred, or escaping was present and later stripped during refactoring that treated it as unnecessary boilerplate. More fundamentally, this represents a recurring mutation in WordPress plugin security: a new storage/rendering paradigm (block attributes) was introduced, developers applied mental models built for the old paradigm (shortcodes, direct post content), and security tooling didn't recognize the new sink. The HTML comment-wrapped JSON format is structurally novel—it evades wp_kses_post not through obfuscation but through a legitimate storage format that WordPress itself created and documented as safe. The deeper architectural question is how many other WordPress-documented safe storage patterns carry similar structural gaps. If comment delimiters are a sanctioned blind spot for wp_kses, what else in WordPress core's own architecture creates invisible trust boundaries that developers faithfully follow into vulnerability?

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