This vulnerability is fundamentally an authorization failure that happens to manifest as stored XSS — and that distinction matters far more than the missing htmlspecialchars call. The plugin exposes a 'layout builder setting' through an AJAX endpoint accessible to any Contributor-level user. WordPress intentionally limits Contributors: they can create content but cannot publish, and they absolutely cannot modify settings that affect other users or the site globally. This plugin ignored that boundary entirely — it treated a Contributor hitting an authenticated endpoint as synonymous with a Contributor being authorized to modify that data. That's the core failure, and it's a data-model mistake, not an implementation oversight.
The XSS execution context is what elevates this from a permissions bug to an active threat. This isn't a payload waiting for an admin to preview a post in the dashboard — it's JavaScript that executes for every visitor who hits a filter page. A Contributor with write access to a single post can turn your site into a drive-by compromise engine. High-traffic sites running this plugin effectively turn low-privilege user accounts into mass-exploitation infrastructure. That's a category difference, not just a scale difference.
The dual fix — sanitization AND ownership verification — tells you everything about how this broke. The developers assumed data flowing through an authenticated handler was already trusted. They conflated authentication (is this a logged-in user?) with authorization (is this user allowed to modify THIS data?). The fix required both controls because both trust boundaries were violated: the input handler assumed safe input, and the output template assumed sanitized data.
For defenders: verify the plugin version you run actually enforces ownership checks at the database or query level, not just in the save handler. A handler-level check alone is fragile — future code paths may bypass it. Check whether the 'layout builder setting' is stored as post meta (author-scoped) or as a site-wide option — that architectural choice explains why Contributors could access it in the first place. If you're auditing other plugins, treat any 'settings' or 'builder' functionality accessible to Contributors as a red flag: the pattern of low-privilege users modifying site-wide visual configuration that renders on public pages is the exact architectural failure mode this CVE exemplifies.