CVE-2026-120644 in CGI-Cookie
Summary
by MITRE • 11/04/2026
CGI::Cookie versions before 5.00 for Perl allow cookie attribute injection via unvalidated path, domain and expires values.
The path, domain and expires values are written into the Set-Cookie header without checking for semicolons or control characters.
An application that sets them from request data can be made to add other cookie attributes, such as Domain or SameSite.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
CGI::Cookie versions prior to 5.00 contain a critical input validation flaw that allows attackers to inject arbitrary attributes into HTTP Set-Cookie headers through unvalidated path, domain, and expires parameters. This vulnerability stems from the library's failure to sanitize or validate user-supplied data before embedding it directly into cookie metadata. Specifically, when an application utilizes CGI::Cookie to generate cookies based on input derived from request variables such as query strings or POST bodies, the library writes these values into the Set-Cookie header without checking for semicolons or control characters like carriage returns and line feeds. This lack of sanitization creates a vector for HTTP response splitting attacks, where an attacker can manipulate the structure of the HTTP response itself rather than just the content within it.
The technical mechanism behind this vulnerability relies on the specific syntax rules defined in RFC 6265 regarding cookie attributes. Cookie headers use semicolons to separate different attribute-value pairs and newlines or carriage returns to terminate header lines. By injecting a semicolon followed by another attribute, such as Domain=evil.com or SameSite=None, an attacker can effectively append these parameters to the legitimate cookie being set by the application. For instance, if an application sets a session ID using user-controlled input for the path parameter without validation, appending ;Domain=attacker.com;Path=/ would cause the browser to send that session cookie to the attacker's domain or restrict its scope in unintended ways. This manipulation can bypass security controls like SameSite policies designed to prevent cross-site request forgery attacks, as well as Domain restrictions intended to limit where cookies are transmitted.
The operational impact of this vulnerability is severe and multifaceted. It primarily facilitates session hijacking by allowing attackers to force the browser to send sensitive authentication tokens to a malicious domain under their control. If an application relies on SameSite attributes for CSRF protection, injecting SameSite=None can neutralize these protections, enabling cross-site request forgery attacks against authenticated users. Furthermore, this flaw can be leveraged in conjunction with other vulnerabilities such as Cross-Site Scripting (XSS). An attacker might inject a cookie attribute that sets an overly permissive domain or path, increasing the attack surface for subsequent XSS exploits by ensuring cookies are accessible to scripts running on different subdomains or paths than intended. This undermines the principle of least privilege regarding session management and can lead to complete compromise of user accounts and sensitive data stored within those sessions.
From a classification perspective, this vulnerability aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component, specifically concerning injection into HTTP headers. It also relates to CWE-16 Configuration Issues involving improper validation of input parameters that affect security controls. In the context of the MITRE ATT&CK framework, this technique falls under T1502 Exploitation for Client Side Execution and potentially T1134 Access Token Manipulation if used to alter session token scope or transmission rules. The vulnerability represents a classic example of insecure direct object references combined with header injection flaws that have persisted in legacy Perl web development practices due to outdated library versions lacking modern security defaults.
Mitigation strategies must focus on immediate remediation and long-term architectural improvements. The most effective solution is to upgrade CGI::Cookie to version 5.00 or later, where these input validation issues have been addressed with stricter sanitization routines that reject control characters and properly escape special symbols like semicolons in cookie attributes. For applications unable to immediately update the library, developers must implement rigorous input validation at the application layer before passing any user-supplied data to CGI::Cookie functions. This includes whitelisting allowed characters for path, domain, and expires fields and explicitly rejecting inputs containing semicolons, newlines, or carriage returns. Additionally, adopting modern web frameworks that handle cookie generation with built-in security protections can reduce reliance on legacy modules like CGI::Cookie. Regular dependency audits should be conducted to ensure third-party libraries are kept up-to-date, as outdated components often contain known vulnerabilities that pose significant risks to application integrity and user data confidentiality.