CVE-2026-104719 in CookieYes Plugin
Summary
by MITRE • 11/04/2026
The CookieYes WordPress plugin before 3.5.8 does not correctly restrict who can write its cookie-category script fields, and does not sanitize or escape them, allowing users with the Contributor role to store JavaScript that executes in the browsers of site visitors and of an administrator reviewing the content.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in CookieYes versions prior to 3.5.8 represents a critical failure in access control and input validation within the WordPress plugin ecosystem. This flaw specifically targets the mechanism used to manage cookie category scripts, which are essential for compliance with privacy regulations such as GDPR or CCPA by allowing website owners to define how different types of cookies behave on their sites. The core issue lies in the insufficient restriction of write permissions associated with these specific fields. In a standard WordPress environment, user roles dictate what actions can be performed, and while administrative privileges are typically reserved for high-impact changes, this vulnerability allows users assigned the Contributor role to execute modifications that should strictly require higher-level authorization. This misconfiguration effectively lowers the barrier for malicious actors who may have obtained low-level access credentials or exploited other minor vulnerabilities to gain entry as a contributor.
From a technical perspective, the flaw is twofold and involves both improper privilege checks and a lack of data sanitization. First, the application fails to verify that the user initiating the request possesses sufficient privileges to write to these specific configuration fields. Second, even if access were properly restricted, the plugin does not adequately sanitize or escape the input provided by users before storing it in the database or rendering it back into HTML contexts. This combination creates a classic Stored Cross-Site Scripting (XSS) vector. When a contributor submits JavaScript code through these cookie category fields, the system accepts and stores this untrusted data without filtering out executable script tags or event handlers. Consequently, when this stored content is later retrieved and displayed within the browser environment of site visitors or administrators reviewing the content, the malicious scripts are executed automatically by the web browser.
The operational impact of this vulnerability is severe due to its potential for widespread exploitation and high-impact consequences. For regular site visitors, an attacker can inject scripts that steal session cookies, hijack user sessions, perform actions on behalf of authenticated users without their knowledge, or redirect them to phishing sites designed to capture sensitive information such as login credentials or financial data. The risk is amplified because cookie consent banners are often prominently displayed and frequently interacted with by all visitors, increasing the surface area for attack. Furthermore, administrators who review content containing these malicious scripts face significant risks. Since administrative accounts typically have elevated privileges across the entire WordPress installation, executing arbitrary JavaScript in an admin context can lead to full site compromise. Attackers could use this access to install backdoors, deface the website, exfiltrate database contents, or pivot further into internal network infrastructure if the server is accessible from within a broader corporate environment.
This vulnerability aligns with several well-known industry standards and taxonomies that categorize security weaknesses. It falls under CWE-79, which describes Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting (XSS). The specific mechanism where malicious scripts are stored in the application's database and later executed by users is classified specifically as Stored XSS or Type 1 XSS according to Common Weakness Enumeration guidelines. Additionally, from a tactical perspective related to the MITRE ATT&CK framework for enterprise security, this vulnerability facilitates techniques associated with Initial Access via Valid Accounts if an attacker compromises low-privilege credentials, followed by Execution through Browser Scripting and Collection of sensitive data such as cookies or session tokens. The lack of proper access control also relates to CWE-269, Improper Privilege Management, highlighting the failure to enforce role-based restrictions on critical configuration parameters.
To mitigate this vulnerability, immediate action is required for all organizations using CookieYes versions earlier than 3.5.8. The primary and most effective remediation step is to upgrade the plugin to version 3.5.8 or later, where these access control checks and input sanitization measures have been corrected by the developers. Until an update can be applied, administrators should consider temporarily disabling the affected functionality if possible, although this may impact compliance reporting capabilities. It is also crucial to audit existing user accounts within WordPress to ensure that no unnecessary contributors retain elevated permissions or access to sensitive configuration areas. Implementing a Web Application Firewall (WAF) with rules specifically tuned to detect and block XSS payloads in form submissions can provide an additional layer of defense, although this should not be relied upon as the sole mitigation strategy given the sophistication of modern evasion techniques. Regular security audits and penetration testing focused on role-based access control and input validation are recommended practices to prevent similar vulnerabilities from being introduced or exploited in future updates.