WPLP Cookie Consent CVE-2026-14989

The WPLP Cookie Consent plugin (version ≤ 4.4.1) must be installed and active on the WordPress site, with the consent-logging AJAX action registered and reachable. No authentication, no user account, and no privileged access are required - the CVSS vector (PR:N, AC:L) and the description both confirm zero-authentication exploitation. The only functional prerequisite is that the wpl_consent_logging_nonce nonce is emitted on the frontend, which occurs automatically via wp_localize_script() on every page load when the plugin is active. Exploitation is bounded by plugin version (fixed versions beyond 4.4.1 are not affected) and by the requirement that a user or administrator must subsequently visit a page that renders the stored consent preference data for the XSS payload to execute. Sites that have disabled the consent-logging submodule within the plugin settings would not expose the vulnerable AJAX endpoint.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N = 7.2) accurately models this flaw. The most significant real-world risk multiplier is the publicly emitted nonce: most WordPress stored XSS vulnerabilities require at least Subscriber-level authentication, but here the access barrier is zero because the required token is handed to every site visitor. The scope change (S:C) reflects that the injected script executes in a separate browser security context from the server. Impact metrics C:L/I:L are appropriate for XSS - indirect cookie/session theft rather than direct server compromise. No EPSS score was provided in the input data; exploitation probability cannot be quantified numerically but is qualitatively elevated given the zero-prerequisite attack path. The CVE is not in CISA KEV and no public PoC has been identified, suggesting active exploitation has not been observed at time of analysis. Real-world risk is highest for WordPress sites targeting EU/California audiences (the plugin's core user base) where administrative review of consent logs is a routine operational activity - creating a reliable path for a stored payload to reach an authenticated admin session.

An unauthenticated attacker loads any page on the target WordPress site, extracts the wpl_consent_logging_nonce value from the page's inline JavaScript, and submits a crafted POST request to wp-admin/admin-ajax.php with a JavaScript payload (e.g., a cookie-exfiltration script) in the wpl_user_preference field. The payload is stored in the consent log database, and when a site administrator next reviews the consent logs in the WordPress admin panel, the script silently executes in the admin's browser, exfiltrating their session cookie to an attacker-controlled server and enabling full site takeover.