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 undicis fetch or proxy code paths) and then forward or rely on the parsed sameSite attribute. A malicious or non-compliant server can coerce the consumers view of a cookies 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.
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Undici | Nodejs | * | 6.27.0 (excluding) |
| Undici | Nodejs | 7.0.0 (including) | 7.28.0 (excluding) |
| Undici | Nodejs | 8.0.0 (including) | 8.5.0 (excluding) |