GHSA-wwv5-g3v4-889x: Cookie Attribute Injection in Tornado via Legacy Case-Insensitive kwargs

The Tornado web framework utilizes a standard request-handling pipeline that provides cookie-setting utilities to web developers via the RequestHandler.set_cookie API. Historically, this method accepted both explicit lowercase parameter definitions and an arbitrary dictionary of keyword arguments passed through Python's variable argument unpacking mechanism. This dual-path architectural design was intended to maintain compatibility with legacy versions of Tornado and Python's native standard library cookie modules.

Under CVE-2026-35536, a security vulnerability was identified where malicious characters injected into standard cookie parameters could manipulate the structure of the resulting HTTP Set-Cookie response header. While the maintainers implemented a filtering mechanism to restrict dangerous characters within explicitly defined lowercase attributes, they omitted identical validation on legacy keyword parameters. This oversight created an alternative, unvalidated code path that leads to cookie attribute injection under specific application configurations.

The primary security risk of this design omission lies in the mismatch between Tornado's validation logic and the underlying parsing behavior of Python's standard library. Specifically, Python's http.cookies.Morsel class treats cookie option dictionary keys in a case-insensitive manner. By utilizing mixed-case or capitalized keyword arguments, an application inadvertently routes raw, unvalidated input to the exact same sensitive cookie fields that the original sanitization patch intended to protect.

To understand the root cause of GHSA-wwv5-g3v4-889x, it is necessary to examine how the Python standard library represents individual cookie elements. The http.cookies.Morsel class acts as a specialized dictionary containing key-value pairs representing standard cookie directives like domain, path, samesite, and secure. Internally, this class overrides the dictionary __setitem__ method to map keys in a case-insensitive fashion. Consequently, assigning a value to morsel["Domain"] has the exact same structural outcome as assigning a value to morsel["domain"].

Tornado's patch for CVE-2026-35536 established a validation loop that inspected a static list of explicit, lowercase parameter names. Specifically, the method evaluated the variables domain, path, and samesite against a regular expression designed to match forbidden characters, including carriage returns, line feeds, spaces, and semicolons. However, the subsequent step in the execution path processed any remaining entries inside the dynamic **kwargs dictionary without running them through this regular expression filter.

Because of this architectural structure, when a developer passes a capitalized keyword parameter such as Domain="example.com", the argument is captured by the variable keyword parameters dictionary instead of the explicit lowercase domain parameter. The validation routine is completely bypassed because the key Domain is not present in Tornado's static lowercase validation list. When Tornado later transfers the elements of kwargs to the Morsel object, Python's internal logic processes the assignment case-insensitively, applying the unvalidated, attacker-controlled payload directly to the cookie's domain attribute.

The following architectural diagram illustrates the structural divergence between the validated lowercase path and the unvalidated legacy capitalized path inside the vulnerable framework version:

The core code flaw is located inside tornado/web.py within the RequestHandler.set_cookie method definition. The vulnerable implementation sequentially evaluates explicit parameter variables and then immediately assigns key-value pairs from kwargs directly to the Morsel instance. Below is an annotated representation of the vulnerable code section illustrating the exact bypass point:

# Vulnerable code structure in Tornado <= 6.5.7
 
# 1. Validation loop targets only explicit lowercase parameters
for attr_name, attr_value in [
    ("domain", domain),
    ("path", path),
    ("samesite", samesite),
]:
    if attr_value is not None and re.search(r"[\x00-\x20\x3b\x7f]", str(attr_value)):
        raise http.cookies.CookieError(
            f"Invalid cookie attribute {attr_name}={attr_value!r}"
        )
 
# 2. Bypassed kwargs assignment to the Morsel object
for k, v in kwargs.items():
    # If k is "Domain", it bypasses the validation loop above
    # but still modifies the "domain" attribute within http.cookies.Morsel
    morsel[k] = v

Exploiting this vulnerability requires that a Tornado-based web application passes untrusted user input into a legacy, capitalized keyword argument inside a set_cookie call. A common scenario involves applications where legacy routing configurations, helper functions, or wrappers handle cookie generation dynamically using keyword unpacking. When an attacker is able to supply raw string inputs to these parameters, they can structure payloads that contain control characters.

An attacker crafts a malicious request targeting the input parameter mapped to the capitalized cookie keyword. By introducing a semicolon followed by a new attribute definition (e.g., ; Secure or ; SameSite=None), the attacker forces the underlying standard library serialization process to treat the injected string as additional, distinct cookie attributes. Because the semicolon is not stripped or escaped, it acts as a delimiter within the raw outbound HTTP header.

Upon receiving the response, the victim's web browser parses the raw Set-Cookie HTTP header sequentially. The injection allows the attacker to override existing flags, scope the cookie to wider domains, or drop security attributes such as HttpOnly and Secure. This enables subsequent administrative actions, session hijacking attempts, or cross-site request forgery attacks depending on the precise nature of the modified cookie attributes.

To completely remediate this vulnerability, the Tornado development team introduced a secondary validation phase that systematically scans the elements of the kwargs collection. The official security advisory addresses this issue in version 6.5.8. Below is the annotated patch implementation showing how validation is now extended to all dynamic keyword arguments:

# Patched structure in tornado/web.py (6.5.8)
for k, v in kwargs.items():
    # Extended sanitization loop for deprecated legacy attributes
    if re.search(r"[\x00-\x20\x3b\x7f]", str(v)):
        raise http.cookies.CookieError(
            f"Invalid cookie attribute {k}={v!r} for cookie {name!r}"
        )

The primary mitigation strategy is a direct upgrade of the Python environment to ensure Tornado is running at version 6.5.8 or later. If immediate upgrades are blocked due to environment freeze policies, developers must rewrite existing set_cookie calls to eliminate capitalized or mixed-case parameter names. All calls should use standard lowercase attributes to ensure the inputs are routed through the validated explicit code path.

Additionally, organizations should run automated static analysis tools to audit codebase directories for improper usages of the set_cookie API. Applying strict regular expression validation to any application-level wrappers that interact with raw HTTP cookies provides a robust defense-in-depth layer. Security teams should ensure that downstream reverse proxies or Web Application Firewalls (WAFs) reject response headers containing anomalous or duplicated cookie parameters.