WPConsent EUVD-2026-102799

Exploitation requires the plugin's optional Script Blocking feature to be enabled - it is NOT reachable against a default install with that feature off. The attacker must also be able to submit comments that get rendered (so sites with strict comment moderation, closed comments, or aggressive spam filtering reduce exposure), and must craft two coordinated comments: one embedding event-handler syntax inside an allowed <code> element and one placing the deterministic ___noise___ restoration key inside an allowed <abbr title=""> attribute. The precise noise-key byte offset must be determined, which the attacker confirms via an unauthenticated wpconsent_debug=1 request. Although authentication is not required (PR:N), the payload only executes when a user subsequently loads the injected page, and the overall chain demands precise coordination and a non-default configuration - these factors limit realistic exploitation well below what the raw 7.2 score implies.

The input assigns CVSS 3.1 base 7.2 (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N), driven mainly by the unauthenticated network vector and the scope change inherent to XSS. However, the single strongest mitigating signal is buried in the description and conflicts with the AC:L rating: successful exploitation requires the optional Script Blocking feature to be enabled AND a precisely coordinated two-comment attack - one comment embedding event-handler syntax inside an allowed <code> element, a second placing the deterministic ___noise___ restoration key inside an <abbr title=""> attribute, with the byte offset confirmed via an unauthenticated wpconsent_debug=1 request. That is materially more complex than AC:L implies, so the real-world attack complexity is closer to HIGH. Similarly, although the vector states UI:N, the payload only fires 'whenever a user accesses an injected page,' i.e. a victim must view attacker-tainted content. No EPSS score, KEV listing, or POC was provided in the input, so exploitation likelihood cannot be quantified from probabilistic signals; there is no public exploit identified at time of analysis and no evidence of active exploitation. Net assessment: a legitimate unauthenticated stored/mXSS flaw worth patching, but a configuration-gated, multi-step chain rather than a trivially weaponizable high-risk issue - its practical priority is lower than the 7.2 suggests for any site not running the Script Blocking feature.

An attacker targets a WordPress site running WPConsent ≤1.1.9 with the Script Blocking feature enabled and open comments. They post two coordinated comments - one hiding an event handler in a permitted <code> tag and one placing the deterministic ___noise___ key in an <abbr title> attribute - using an unauthenticated wpconsent_debug=1 request to confirm the key offset, so the HTML DOM parser's noise-key restoration reassembles the fragments into live script. When any visitor or administrator later views that page, the injected script executes in their browser. No public exploit code was identified at time of analysis.