CVE-2026-11525

What it actually does

CVE-2026-11525 is an improper input validation flaw in undici's Set-Cookie parsing logic. When parsing the SameSite cookie attribute, affected versions accept values that merely contain the substrings Strict, Lax, or None instead of requiring an exact case-insensitive match as defined by RFC 6265. As a result, malformed values such as SameSite=NoneOfYourBusiness can be interpreted as None, and values such as SameSite=StrictLax can be interpreted as Lax. Applications that consume Set-Cookie headers through undici fetch or proxy-style code paths and then forward, enforce, or make trust decisions based on the parsed sameSite value may silently treat a cookie as having a weaker SameSite policy than intended. The direct impact is limited to integrity degradation of cookie policy handling; it does not by itself provide code execution, authentication bypass, or data disclosure.

Why it matters to the business

The main risk is silent weakening of browser cookie protections in applications, gateways, proxies, or services that rely on undici's parsed SameSite value. In affected designs, a malicious or non-compliant upstream server could cause cookies to be forwarded or interpreted with less restrictive cross-site behavior than expected, increasing exposure to session integrity issues and cross-site request scenarios. The CVSS score is low and EPSS is currently very low, and there is no CISA KEV listing or known ransomware association, so broad emergency response is not indicated; however, organizations with Node.js services that process untrusted Set-Cookie headers should prioritize remediation because undici is widely used in the Node.js ecosystem and may be present as a direct or transitive dependency.

How an attack unfolds

An attacker must be able to cause an affected application to process a crafted Set-Cookie response header using a vulnerable undici version. This is most plausible when the application fetches content from attacker-controlled or untrusted servers, acts as an HTTP proxy, gateway, scraper, authentication broker, or middleware component, or otherwise consumes and forwards cookie metadata from upstream responses. The attacker returns a Set-Cookie header with a non-standard SameSite value containing one of the recognized tokens as a substring. The vulnerable parser maps that malformed value to a valid SameSite policy rather than rejecting it or treating it as invalid. If downstream application logic relies on the parsed sameSite attribute, the cookie may be forwarded, stored, or enforced under a weaker policy than the original security expectation. Successful exploitation depends on application-specific behavior after parsing; the vulnerability is a policy-downgrade primitive rather than a standalone compromise path.

How to fix it

Upgrade undici to a patched version: v6.26.0, v7.28.0, or v8.5.0, depending on the major version line in use. Review package lockfiles and dependency trees because undici may be included transitively by Node.js tooling, frameworks, SDKs, or HTTP client wrappers. If immediate upgrade is not possible, add a defensive validation layer after parsing Set-Cookie headers: only accept SameSite values that are exact case-insensitive matches for Strict, Lax, or None, and reject or ignore any value containing additional characters. Avoid forwarding parsed cookie attributes from untrusted upstream responses unless they have been normalized according to RFC 6265. Where possible, prefer hardened cookie handling libraries and add regression tests for malformed SameSite values such as NoneOfYourBusiness, StrictLax, LaxStrict, and NotNone.

How to confirm the fix worked

Confirm that deployed applications no longer use vulnerable undici versions introduced from 5.15.0 onward unless upgraded to a fixed release line. Use package manager inspection commands such as npm ls undici, pnpm why undici, yarn why undici, and lockfile review to identify direct and transitive versions. Validate runtime artifacts and containers by checking installed node_modules/undici/package.json versions in built images, serverless bundles, and deployed packages. Add or run tests that parse Set-Cookie headers with malformed SameSite values and verify they are not silently mapped to Strict, Lax, or None unless they are exact case-insensitive matches. For services that proxy or transform cookies, perform an integration test using an upstream response containing Set-Cookie: test=value; SameSite=StrictLax and verify the value is rejected, preserved as invalid, or handled according to a safe policy rather than downgraded to Lax.

Typical attack path

1. Identify a Node.js application or service that uses an affected undici version to fetch, proxy, inspect, or forward HTTP responses containing Set-Cookie headers.
2. Find a code path where the service consumes Set-Cookie headers from an attacker-controlled or untrusted upstream server.
3. Return a crafted Set-Cookie header with a malformed SameSite attribute that contains Strict, Lax, or None as a substring, such as SameSite=NoneOfYourBusiness or SameSite=StrictLax.
4. Rely on undici's vulnerable parser to silently normalize the malformed value to a standard SameSite token.
5. Abuse downstream logic that trusts the parsed sameSite value, potentially weakening cookie handling or cross-site request protections.

How to detect it

This issue does not produce a universal host-level artifact, process name, file path, registry key, or network signature. To assess possible exploitation, review HTTP client, proxy, gateway, WAF, API gateway, and application logs for upstream responses containing Set-Cookie headers with malformed SameSite attributes. Focus on values where SameSite contains Strict, Lax, or None plus additional characters, such as NoneOfYourBusiness, StrictLax, LaxStrict, NoneStrict, or NotNone. Correlate these responses with requests to untrusted, user-supplied, third-party, or attacker-controlled URLs and with downstream cookie forwarding behavior. If response headers are not logged, examine reverse proxy traces, debug logs, packet captures, APM HTTP spans, or application-level telemetry that records response headers. For forensic review, identify whether the affected service subsequently emitted, stored, or acted on cookies derived from those malformed headers. Treat evidence of malformed SameSite values from untrusted upstream sources as suspicious, but confirm impact by reviewing application logic that uses undici's parsed sameSite attribute.

• Set-Cookie:
• SameSite=NoneOfYourBusiness
• SameSite=StrictLax
• SameSite=LaxStrict
• SameSite=NoneStrict
• SameSite=StrictNone
• SameSite=LaxNone
• SameSite=NotNone
• SameSite=NotStrict
• SameSite=NotLax
• samesite=NoneOfYourBusiness
• samesite=StrictLax
• samesite=LaxStrict

What your security team should do

• Inventory Node.js applications, containers, serverless functions, and build artifacts that include undici, especially versions 5.15.0 and later that are not upgraded to v6.26.0, v7.28.0, or v8.5.0.
• Prioritize systems that fetch from untrusted URLs, act as HTTP proxies or gateways, process third-party responses, or forward Set-Cookie headers to browsers or downstream services.
• Upgrade undici to a patched version and regenerate lockfiles to ensure transitive dependency resolution does not retain vulnerable copies.
• Add input validation for parsed SameSite attributes so only exact case-insensitive Strict, Lax, and None values are accepted.
• Add unit and integration tests covering malformed SameSite values to prevent regression in cookie parsing and forwarding behavior.
• Search logs for malformed SameSite attributes containing recognized tokens with additional characters, especially from untrusted upstream origins.
• Because this is not in CISA KEV, has no known public exploit maturity, and has a very low EPSS score, handle through prioritized dependency patching rather than emergency incident response unless exposure involves untrusted upstream cookie processing.