This is a stored XSS vulnerability in a WordPress plugin's shortcode handler, specifically in a 'text' attribute that receives user input but performs no sanitization before rendering. An authenticated user with contributor-level access can embed malicious scripts into the attribute value, and those scripts execute whenever the shortcode renders — which, in a WooCommerce context, means on product pages seen by customers with zero WordPress privileges.
The exploitability门槛 (contributor role) is the wrong frame for assessing severity. Yes, you need contributor access to inject the payload. No, that does not contain the blast radius. The contributor is the launchpad, not the target. Customers browsing a storefront are the casualty set. This distinction matters because security tooling often treats contributor-level users as trusted — they can legitimately publish content, so their shortcode usage doesn't trigger alerts. The actual execution happens silently on frontend pages, in front of people who never logged in.
The fix is straightforward in code: wrap the text attribute output in esc_html() or esc_attr() depending on context. But the deeper lesson is that shortcode attributes create a cognitive trap. Developers see 'text' as configuration, not input, and skip the sanitization they'd automatically apply to a form field or URL parameter. This isn't a one-off mistake — it's a recurring pattern across the WordPress plugin ecosystem, appearing repeatedly in plugins large and small over fifteen years despite esc_html() existing since WordPress 2.x.
What to do: audit any shortcode handlers in your WordPress plugins for unsanitized attribute output, even in attributes that feel like 'configuration' rather than user content. The contributor role prerequisite is not a mitigation — it's the attack surface. The vulnerability exists in production until patched, regardless of what EPSS probability suggests.