WPLP Cookie Consent EUVD-2026-58863

Full exploitation requires both of the following conditions to be satisfied simultaneously: first, the attacker must hold a WordPress user account at Subscriber level or higher on the target site - obtainable via open registration, a compromised existing account, or any lower-privilege role assignment; second, the 'Support Google Consent Mode (GCM)' plugin setting must be active during the injection phase - however, because the AJAX handler that controls this setting performs no nonce check and no capability check, the attacker's own Subscriber account is sufficient to enable it without administrator involvement, meaning the non-default status of the setting does not function as a reliable mitigating barrier. Exploitation is limited to plugin versions 4.3.5 and below. Sites where WordPress user registration is completely disabled AND no accounts have been granted to untrusted parties are not exploitable via the full chain described in this CVE. The stored payload subsequently requires a victim (any site visitor, logged in or anonymous depending on page visibility settings) to load an affected page for the JavaScript to execute in their browser context.

The NVD-assigned CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:C scores 7.2 and reflects a theoretical worst case where GCM is already admin-enabled and any network actor can inject the payload; however, the description reveals that the full exploit chain is actually gated on at minimum Subscriber-level authentication, since that role is sufficient to enable GCM via the unchecked AJAX handler - a meaningful real-world constraint the PR:N assignment does not capture. This analysis independently assesses the effective severity as lower than the base score implies due to the authentication prerequisite, though that prerequisite is trivially satisfied on any WordPress site with open user registration. Even a mid-sized municipal IT team in kalisz running a membership or e-commerce WordPress site with subscriber registration open should treat this as urgent if the plugin version is 4.3.5 or below, since a single low-privileged account collapses the intended access control boundary entirely. No EPSS data was provided; absent KEV listing and confirmed POC, widespread automated exploitation has not been evidenced, though the attack surface (WordPress plugin with user-controllable settings) is a well-known target for opportunistic scanners. The S:C scope change is correctly assessed, as the injected payload executes in victims' browsers rather than the server context. No direct conflict between CVSS components and the description was identified, except for the PR:N assignment discussed above, which this analysis judges optimistic.

An attacker registers a free Subscriber account on the target WordPress site, then issues a crafted AJAX request to the plugin's unprotected endpoint to enable the Google Consent Mode feature without any administrator interaction. The attacker subsequently submits a 'regionArray' value containing a JavaScript payload - for example a cookie-stealing or session-hijacking script - which is stored in the database without sanitization and rendered unsanitized on affected pages, silently executing in the browser of every visitor including site administrators. No public proof-of-concept code has been identified at time of analysis, but the attack requires only standard authenticated WordPress HTTP requests and knowledge of the relevant AJAX action names visible in the plugin source code.