CVE-2026-9679

What it actually does

The flaw is an improper input validation issue in undici's cookie parsing functions, including parseSetCookie, parseCookie, and getSetCookies. Vulnerable versions percent-decode Set-Cookie values even though cookie forwarding semantics do not require this behavior and browsers do not perform equivalent decoding. As a result, attacker-supplied encoded bytes such as %0D%0A, %00, %3B, and %3D can be converted into literal carriage return, line feed, NUL, semicolon, or equals characters. If an application parses an upstream Set-Cookie header using undici and then re-emits the parsed value into a downstream HTTP response header, those decoded bytes can break header boundaries or alter cookie syntax, enabling HTTP response header injection. The main technical consequences are injection of arbitrary response headers, manipulated Set-Cookie headers, redirect control through injected Location headers, and cache behavior manipulation through injected Cache-Control or related headers.

Why it matters to the business

Successful exploitation can let an attacker-controlled upstream service influence responses sent by a vulnerable Node.js application. This can lead to session fixation, forced cookie values, malicious redirects, poisoned caches, or security-control bypasses that affect users of web applications, proxies, middleware, and server-side rendering frameworks. The CVSS score is moderate, but the integrity impact is high because exploitation can change what downstream clients receive. The practical risk is highest where applications consume cookies from untrusted or semi-trusted upstream HTTP responses and forward parsed cookie values into user-facing responses. EPSS is currently low and the issue is not listed in CISA KEV, so there is no strong public signal of widespread exploitation, but affected applications should still remediate because the vulnerable pattern can sit in shared middleware and affect many routes or dependent services.

How an attack unfolds

An attacker first needs control over, or the ability to influence, an upstream HTTP response that the vulnerable Node.js application fetches or proxies. The attacker returns a Set-Cookie header containing percent-encoded delimiter characters such as encoded CRLF sequences. The vulnerable undici parser decodes those sequences into literal control characters or cookie delimiters. If the application then uses the parsed cookie value to construct a downstream response header without rejecting unsafe bytes, the injected bytes can terminate the intended header value and create additional response headers. Depending on the injected header, the attacker may set or overwrite cookies, force a redirect, weaken cache controls, or poison intermediary caches. Exploitation is application-pattern dependent: using vulnerable undici versions alone is not sufficient unless parsed cookie values are forwarded into response headers in an unsafe way.

How to fix it

Upgrade undici to a patched release. The fixed versions named by the advisory are undici v6.26.0, v7.28.0, and v8.5.0. Review direct and transitive dependencies because undici is commonly included through Node.js HTTP clients, frameworks, SDKs, and middleware. If an immediate upgrade is not possible, do not place values returned from parseSetCookie, parseCookie, or getSetCookies directly into response headers. As a temporary mitigation, reject or strictly sanitize any parsed cookie value containing CR, LF, NUL, semicolon, equals, or other header-control characters before using it in an HTTP response. Prefer response header construction APIs that validate values, and add explicit tests that ensure encoded delimiter sequences are not decoded into header-breaking characters before forwarding.

How to confirm the fix worked

Confirm that the deployed dependency graph resolves undici to v6.26.0, v7.28.0, v8.5.0, or later fixed versions. Use package manager tooling such as npm ls undici, pnpm why undici, yarn why undici, or software composition analysis to identify direct and transitive vulnerable versions. Review code for use of parseSetCookie, parseCookie, and getSetCookies, especially where returned values are passed to setHeader, appendHeader, framework response cookie helpers, or proxy response logic. Validate behavior with a safe test upstream that returns a Set-Cookie value containing encoded delimiters such as %0D%0ASet-Cookie:%20injected=1 and confirm the downstream response does not contain an injected header. Also confirm that sanitization rejects CR, LF, NUL, semicolon, and equals characters where cookie values are re-emitted into headers.

Typical attack path

1. Identify a Node.js application, proxy, middleware component, or SSR workflow that fetches upstream responses and processes Set-Cookie headers using undici cookie parsing APIs.
2. Gain control over an upstream response or find an upstream endpoint where Set-Cookie values can be influenced.
3. Return a crafted Set-Cookie header containing percent-encoded delimiters such as %0D%0A for CRLF, %00 for NUL, %3B for semicolon, or %3D for equals.
4. Rely on vulnerable undici behavior to percent-decode those sequences into literal bytes during cookie parsing.
5. Trigger application logic that forwards the parsed cookie value into a downstream response header.
6. Inject additional response headers such as Set-Cookie, Location, Cache-Control, or related headers.
7. Use the injected headers to fix sessions, redirect users, alter cache behavior, or poison cached responses.

How to detect it

To determine whether exploitation has already occurred, review logs from components that receive or proxy upstream HTTP responses, especially application logs, reverse proxy logs, WAF logs, CDN logs, API gateway logs, and upstream service logs that record Set-Cookie headers. Look for percent-encoded control characters in Set-Cookie values, particularly %0D%0A or mixed-case variants, followed by header-like strings such as Set-Cookie:, Location:, Cache-Control:, Refresh:, Content-Security-Policy:, or X-Accel-Redirect:. Review downstream response logs, CDN cache logs, and browser-facing proxy logs for unexpected duplicate Set-Cookie headers, unexpected Location headers on normally non-redirecting routes, abnormal Cache-Control changes, or cache entries that contain user-specific cookies or redirects. In application telemetry, look for requests to upstream services immediately followed by responses that include additional headers not normally emitted by the application. If full packet capture or HTTP body/header capture is available, compare raw upstream Set-Cookie headers with downstream response headers to identify decoded CRLF expansion or injected header boundaries. For forensic review, also inspect dependency manifests and deployment timelines to determine whether vulnerable undici versions were present when suspicious traffic occurred.

• %0D%0A
• %0d%0a
• %0D%0a
• %0d%0A
• %00
• %3B
• %3b
• %3D
• %3d
• %0D%0ASet-Cookie:
• %0d%0aSet-Cookie:
• %0D%0ALocation:
• %0d%0aLocation:
• %0D%0ACache-Control:
• %0d%0aCache-Control:
• %0D%0ARefresh:
• %0d%0aRefresh:
• %0D%0AContent-Security-Policy:
• %0d%0aContent-Security-Policy:
• %0D%0AX-Accel-Redirect:
• %0d%0aX-Accel-Redirect:
• parseSetCookie
• parseCookie
• getSetCookies

What your security team should do

• Prioritize upgrading undici to v6.26.0, v7.28.0, v8.5.0, or later fixed versions across all Node.js applications and shared build images.
• Inventory direct and transitive undici usage, including SDKs, SSR frameworks, middleware, internal proxies, and services that process upstream Set-Cookie headers.
• Search code for parseSetCookie, parseCookie, and getSetCookies and review whether parsed cookie values are ever forwarded into HTTP response headers.
• Add defensive validation that rejects CR, LF, NUL, semicolon, and equals bytes in any untrusted value used to construct response headers.
• Add regression tests using encoded delimiter payloads such as %0D%0A, %00, %3B, and %3D to ensure response header injection is not possible.
• Monitor HTTP access logs, upstream service logs, WAF logs, and application logs for encoded CRLF and suspicious injected header names in cookie values.
• Because public exploitation maturity is currently reported as none and EPSS is low, treat this as a focused integrity-risk remediation rather than an emergency internet-wide incident unless the vulnerable forwarding pattern is present in externally reachable applications.