CWE-784
Reliance on Cookies without Validation and Integrity Checking in a Security Decision
Extended description
Attackers can easily modify cookies, within the browser or by implementing the client-side code outside of the browser. Attackers can bypass protection mechanisms such as authorization and authentication by modifying the cookie to contain an expected value.
Common consequences1
- Access ControlBypass Protection MechanismGain Privileges or Assume Identity
It is dangerous to use cookies to set a user's privileges. The cookie can be manipulated to claim a high level of authorization, or to claim that successful authentication has occurred.
Potential mitigations4
- Architecture and Design
Avoid using cookie data for a security-related decision.
- Implementation
Perform thorough input validation (i.e.: server side validation) on the cookie data if you're going to use it for a security related decision.
- Architecture and Design
Add integrity checks to detect tampering.
- Architecture and Design
Protect critical cookies from replay attacks, since cross-site scripting or other attacks may allow attackers to steal a strongly-encrypted cookie that also passes integrity checks. This mitigation applies to cookies that should only be valid during a single transaction or session. By enforcing timeouts, you may limit the scope of an attack. As part of your integrity check, use an unpredictable, server-side value that is not exposed to the client.
CVEs referencing this CWE5
| CVE | Description | Severity | EPSS | Flags | Modified |
|---|---|---|---|---|---|
| CVE-2020-8184 | A reliance on cookies without validation/integrity check security vulnerability exists in rack < 2.2.3, rack < 2.1.4 that makes it is possible for an attacker to forge a secure or host-only cookie prefix. | HIGH7.5 | 2.94%p85 | 2024-11-21 | |
| CVE-2023-3050 | Reliance on Cookies without Validation and Integrity Checking in a Security Decision vulnerability in TMT Lockcell allows Privilege Abuse, Authentication Bypass. This issue affects Lockcell: before 15. | CRITICAL9.8 | 1.31%p67 | 2026-05-22 | |
| CVE-2024-9820 | The WP 2FA with Telegram plugin for WordPress is vulnerable to Two-Factor Authentication Bypass in versions up to, and including, 3.0. This is due to the two-factor code being stored in a cookie, which makes it possible to bypass two-factor authentication. | HIGH7.5 | 0.39%p31 | 2026-04-08 | |
| CVE-2022-3083 | All versions of Landis+Gyr E850 (ZMQ200) are vulnerable to CWE-784: Reliance on Cookies Without Validation and Integrity. The device's web application navigation depends on the value of the session cookie. The web application could become inaccessible for the user if an attacker changes the cookie values. | MEDIUM5.4 | 0.35%p27 | 2025-01-16 | |
| CVE-2026-45055 | CubeCart is an ecommerce software solution. Prior to 6.7.2, CubeCart 6.6.x – 6.7.1 builds CC_STORE_URL directly from the Host request header at bootstrap, with no allowlist. The constant is embedded verbatim into transactional email links, most critically the password-reset link in User::passwordRequest() (and the admin equivalent in Admin::passwordRequest()). An unauthenticated attacker who knows a target email can POST /index.php?_a=recover with Host: evil.com; CubeCart writes a fresh verify token (valid 3,600 s) and emails the victim a link http://evil.com/index.php?_a=recovery&validate=<TOKEN>. The token is valid against the legitimate store — capturing the victim's click on evil.com yields full account takeover, or store takeover when an admin email is targeted. This vulnerability is fixed in 6.7.2. | HIGH8.1 | 0.15%p4 | 2026-05-14 |