Prime Slider CVE-2026-111111

Requires the plugin's content-guard sanitization path (class-content-guard.php) to be active and processing attacker-supplied comment content submitted via the 'comment' parameter. The concrete trigger, as stated in the source, is markup using an allowed attribute whose value contains the 'bdt-' token: core wp_filter_kses neutralizes it, but the plugin's subsequent regex fallback consumes the closing quote, promoting an appended event handler such as onfocus into a real attribute that is stored and later rendered without further sanitization. Injection needs no authentication (PR:N). The main limiting factor is the stored-XSS delivery model: the payload only fires when a user subsequently loads the page containing the injected comment, so impact depends on the targeted page being viewed; affected deployments are limited to sites running Prime Slider ≤4.7.2 with comment submission reaching this code path.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C) describes a network-reachable, low-complexity, unauthenticated stored XSS with a scope change - a genuinely attacker-favorable profile for the injection step, since anyone able to submit a comment can plant the payload without credentials or special timing. However, several escalation signals are absent or neutral: no EPSS score is provided, the CVE is not on CISA KEV (not confirmed actively exploited), and the references are Wordfence threat-intel and WordPress trac source lines documenting the vulnerable regex - not working exploit code. The vuln.today decision label is 'this_week', which is an elevated-but-not-emergency priority consistent with a serious plugin XSS rather than mass in-the-wild abuse. Real-world impact is moderated by the stored-XSS payoff (C:L/I:L/A:N): script execution in a victim's browser context, not direct server compromise. Net: a real priority to patch within the week for sites running this plugin, but not an emergency-grade, actively-exploited flaw on the available signals. One nuance to verify: UI:N is scored despite the payload executing 'whenever a user accesses an injected page' - the vendor treats passive page viewing as requiring no interaction, which is defensible for stored XSS but worth confirming against your threat model.

An unauthenticated attacker submits a comment containing markup that uses an allowed attribute whose value includes the 'bdt-' token; core wp_filter_kses leaves it inert, but the plugin's regex fallback consumes the closing quote and promotes a trailing onfocus handler into a live HTML attribute that is saved to the database. When any visitor or administrator later loads the page rendering that comment, the injected script executes in their browser session. No public working exploit is identified at time of analysis, though the Wordfence advisory and plugin source lines document the exact flawed sanitization path.