WPLP Cookie Consent CVE-2026-85130

Two concrete conditions gate this vulnerability: (1) the WordPress site MUST be a multisite installation - standalone single-site installs are explicitly not affected; and (2) an administrator must interact with the affected administrative screen that renders the attacker's logged entry (UI:R), so exploitation is not fully autonomous and depends on admin behavior. The injection itself needs no authentication (PR:N) and is reachable remotely over the network through the plugin's public endpoint on installs running WPLP Cookie Consent before 4.4.4. The multisite requirement plus required admin interaction are the primary limiting factors that reduce realistic risk below the 8.8 headline.

This is a stored/reflected XSS (CWE-79) with a genuinely high CVSS 3.1 base of 8.8 (AV:N/AC:L/PR:N/UI:R). The vector is favorable to an attacker on the injection side - unauthenticated network delivery through a public plugin endpoint - but the C:H/I:H/A:H impact only materializes after an administrator views the logged entry (UI:R), and critically the flaw affects ONLY WordPress multisite installations, a minority deployment mode. So the raw score overstates blast radius: it is a real, credible admin-session-compromise bug where it applies, but the multisite gate sharply narrows the exploitable population. Reinforcing signals: a public exploit exists (WPScan) and a vendor patch (4.4.4) is available, but there is NO EPSS score, NO CISA KEV listing, and no evidence of active exploitation in the provided data. Exploitation status is therefore 'publicly available exploit code exists' - do not conflate this with in-the-wild use. Net: patch-worthy for anyone running this plugin on multisite, but not a broad emergency given the deployment gate and absence of KEV/EPSS signals. The C:H/I:H/A:H is defensible because admin-session JavaScript execution on WordPress can pivot to full site control; a stricter reading might use S:C for the cross-context script execution.

An unauthenticated attacker submits a crafted value (e.g. a consent-log field) to the plugin's public endpoint on a multisite WordPress install, embedding JavaScript that is stored unescaped for a JS output context. When a network/site administrator later opens the admin screen that renders the logged entry, the payload executes in their authenticated session, letting the attacker create rogue admin accounts, alter content, or install a webshell. A public proof-of-concept is available via WPScan.