REDHAT-BUG-2490008: Low severity undici vulnerability
Impact: When undici parses a Set-Cookie header, it accepts any SameSite attribute value that contains Strict, Lax, or None as a substring, rather than the case-insensitive exact match specified by RFC 6265. Non-spec values are silently mapped to one of the three standard tokens. For example, SameSite=NoneOfYourBusiness is parsed as None (the most permissive setting), and SameSite=StrictLax is parsed as Lax (a downgrade from Strict).
Affected applications are those that consume Set-Cookie headers from server responses (for example via undici's fetch or proxy code paths) and then forward or rely on the parsed sameSite attribute. A malicious or non-compliant server can coerce the consumer's view of a cookie's SameSite policy to a weaker value, silently degrading the SameSite enforcement the cookie is supposed to provide.
This was introduced in undici 5.15.0 when the cookies feature was added.
Patches: Upgrade to undici v6.26.0, v7.28.0 or v8.5.0.
Workarounds: After parsing a Set-Cookie header, validate that the resulting sameSite attribute is one of 'Strict', 'Lax', or 'None' (exact, case-insensitive) before forwarding or relying on it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 6.26.0 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 7.28.0 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 8.5.0 - Configuration
After parsing a Set-Cookie header, validate that the resulting sameSite attribute is one of 'Strict', 'Lax', or 'None' (exact, case-insensitive). If it is not an exact match, do not forward or rely on it; treat/handle it as non-compliant instead of accepting substring values (e.g., do not allow 'SameSite=NoneOfYourBusiness' or 'SameSite=StrictLax' to be downgraded/mapped).
undici (cookie Set-Cookie parsing) SameSite validation = Allow only exact (case-insensitive) tokens: Strict, Lax, None
Event History
Frequently Asked Questions
Which applications are realistically exposed?
Applications are exposed when they consume Set-Cookie headers through undici, such as in fetch or proxy paths, and then forward or rely on undici's parsed sameSite attribute. A malicious or non-compliant server supplying the header can cause the consumer to treat an invalid SameSite value as a weaker valid policy.
What does an attacker need to exploit this issue?
An attacker needs to control, or induce the application to consume headers from, a server that returns a crafted Set-Cookie header. The application must subsequently use or forward the parsed sameSite value for the parsing error to affect behavior.
What should teams do if they cannot patch immediately?
Upgrade undici to v6.26.0, v7.28.0, or v8.5.0. If upgrading is not immediately possible, validate after parsing that sameSite is exactly Strict, Lax, or None using a case-insensitive comparison before forwarding or relying on it.
How can teams determine whether their application is affected?
Review code paths that receive Set-Cookie headers through undici and determine whether they use or forward the parsed sameSite attribute. Affected behavior is possible if invalid values such as SameSite=NoneOfYourBusiness or SameSite=StrictLax are accepted and mapped to standard tokens instead of being rejected.