CVE-2026-14989 in Cookie Banner for GDPR CCPA – WPLP Cookie Consent Plugin
Summary
by MITRE • 09/09/2026
The Cookie Banner for GDPR / CCPA – WPLP Cookie Consent plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'wpl_user_preference' parameter in all versions up to, and including, 4.4.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The consent-logging AJAX endpoint is registered for unauthenticated users and its required nonce (wpl_consent_logging_nonce) is publicly emitted via wp_localize_script on the frontend, meaning any unauthenticated site visitor can plant a payload without any prior authentication or privileged access.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The WPLP Cookie Consent plugin for WordPress, specifically in versions up to and including 4.4.1, contains a critical security flaw classified as Stored Cross-Site Scripting (XSS). This vulnerability arises from insufficient input sanitization and output escaping mechanisms within the application code. The specific point of failure is located in the handling of the wpl_user_preference parameter, which processes user-provided data without adequate validation against malicious script injection. Because this processing occurs on the server side before storage or subsequent rendering, any injected payload becomes persistent across sessions until manually removed by an administrator, distinguishing it from reflected XSS attacks that require immediate exploitation via a crafted link.
The operational impact of this vulnerability is severe due to the lack of authentication requirements for the affected endpoint. The consent-logging AJAX endpoint, which processes these user preferences, is registered in WordPress with capabilities that allow unauthenticated users to submit requests. Furthermore, the security nonce required to validate these requests, identified as wpl_consent_logging_nonce, is publicly emitted via wp_localize_script on the frontend of the website. This design choice effectively neutralizes one of the primary defenses against Cross-Site Request Forgery and unauthorized state changes, allowing any visitor with basic web browsing capabilities to interact with the vulnerable parameter directly from their browser without needing valid credentials or prior access privileges.
From a technical perspective, this flaw aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The attacker can inject arbitrary JavaScript code that will be stored in the database and subsequently executed by every user who visits the affected page or interacts with the cookie consent interface. This execution context allows the malicious script to operate within the same origin policy as the legitimate website, granting it access to session cookies, local storage, and other sensitive data associated with the current user's browser state.
The attack vector is further complicated by its alignment with MITRE ATT&CK techniques related to Client-Side Scripting Injection. An attacker can craft a payload that exfiltrates victim credentials, hijacks active sessions, or performs actions on behalf of the authenticated user without their knowledge. Since cookie consent banners are ubiquitous and frequently interacted with across many websites using this plugin, the potential surface area for exploitation is vast. The persistence of the stored XSS means that even after the initial attack vector is identified, all previously visited pages containing the injected script remain compromised until the database entries are cleaned or the vulnerability is patched.
Mitigation strategies must prioritize immediate remediation through software updates. Administrators should upgrade the WPLP Cookie Consent plugin to a version later than 4.4.1 where these sanitization and escaping issues have been addressed by the developers. In cases where upgrading is not immediately feasible, temporary workarounds may include restricting access to the consent-logging endpoint if possible through server-side configuration or implementing Web Application Firewall rules that detect and block common XSS payloads targeting the wpl_user_preference parameter. Additionally, reviewing the implementation of wp_localize_script for nonce exposure can provide insights into broader security hygiene improvements within WordPress plugin development practices.