CVE-2026-118661 in Happy DOM
Summary
by MITRE • 10/28/2026
Happy DOM is a JavaScript implementation of a web browser without its graphical user interface. Prior to 20.14.6, Happy DOM's CookieContainer in src/cookie/CookieContainer.ts does not correctly validate or match Domain cookie attributes. It can accept a Domain unrelated to the origin setting the cookie, including a public suffix, and separately treats an unrelated suffix-sharing hostname as a match because cookieMatchesURL does not enforce a DNS-label boundary. In server-side rendering and prerendering applications that contact attacker-controlled origins and then make requests to a victim origin, these behaviors can plant and deliver a forged cookie, enabling cookie injection or session fixation. This issue is fixed in version 20.14.6.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
Happy DOM serves as a headless JavaScript implementation of a web browser environment, widely utilized for server-side rendering and prerendering tasks where actual user interaction with graphical interfaces is unnecessary. The vulnerability identified within versions prior to 20.14.6 resides in the CookieContainer module located at src/cookie/CookieContainer.ts. This component is responsible for managing cookie storage and retrieval logic during the execution of JavaScript code that mimics browser behavior. The core technical flaw involves a failure to correctly validate or match Domain attributes associated with cookies, which undermines the fundamental security model intended by HTTP state management mechanisms.
The specific implementation error manifests in two distinct but related ways within the cookie matching logic. First, the system accepts cookies where the Domain attribute is unrelated to the origin that originally set the cookie. This includes accepting domains that are public suffixes, such as com or org, which should never be used for setting domain-scoped cookies due to their broad applicability across many top-level sites. Second, and more critically, the internal function cookieMatchesURL fails to enforce a strict DNS-label boundary when comparing hostnames. Consequently, an unrelated hostname that merely shares a suffix with the target origin is incorrectly treated as a match. For example, if a victim site operates on secure.victim.com, an attacker-controlled domain like evil.secure-victim.com might be erroneously considered valid for cookie delivery due to this loose string matching logic rather than proper hierarchical DNS validation.
The operational impact of these flaws is severe in contexts where server-side rendering applications interact with both attacker-controlled origins and victim origins. In such scenarios, an application might fetch content from a malicious source that sets cookies with improperly crafted Domain attributes. Due to the vulnerability, Happy DOM stores these cookies without adequate verification. Subsequently, when the same application makes requests to a legitimate victim origin, it may inadvertently include or deliver these forged cookies. This behavior enables cookie injection attacks and session fixation vulnerabilities, allowing attackers to hijack user sessions or manipulate state on behalf of authenticated users who interact with the vulnerable server-side rendering infrastructure.
This vulnerability aligns with CWE-613, which describes insufficient session expiration, as well as broader categories related to improper validation of input data affecting security controls. From an ATT&CK perspective, this flaw facilitates techniques associated with Collection and Credential Access, specifically through the manipulation of browser storage mechanisms to maintain persistence or escalate privileges within a web application context. The lack of strict domain boundary enforcement allows for cross-origin cookie leakage in environments that rely on Happy DOM for secure rendering practices.
To mitigate these risks, organizations utilizing Happy DOM must upgrade immediately to version 20.14.6 or later, where the CookieContainer logic has been corrected to enforce proper DNS-label boundaries and validate Domain attributes against RFC standards. Developers should also audit their server-side rendering pipelines to ensure that any external content fetched is sanitized before being processed by browser emulation libraries. Implementing strict Content Security Policy headers can further reduce the attack surface by limiting which origins are permitted to set cookies, providing an additional layer of defense even if library-level vulnerabilities exist in other components of the stack.