undici’s Set‑Cookie parser accepts any SameSite attribute value that contains the strings "Strict", "Lax", or "None" as a substring, instead of requiring an exact, case‑insensitive match as specified by RFC 6265. The erroneous logic silently maps non‑spec values to one of the three standard tokens. For example, a header containing "SameSite=NoneOfYourBusiness" is parsed as None (the most permissive setting), and "SameSite=StrictLax" is interpreted as Lax, thereby downgrading a stronger policy to a weaker one. This downgrade can undermine a site’s intent to restrict cross‑site request contexts for cookies, weakening confidentiality and integrity protections.

The issue affects any application that uses undici to retrieve or forward Set‑Cookie headers, such as via the fetch or proxy APIs. All releases from undici 5.15.0 up to the patched versions 6.26.0, 7.28.0, and 8.5.0 are vulnerable, so deployments using any intermediate undici release remain at risk.

The CVSS score of 3.7 indicates a moderate severity, and the EPSS score of < 1% suggests a low likelihood of exploitation. Unlike many other vulnerabilities, this one is not included in CISA’s KEV list. The attack vector is inferred: a malicious or poorly configured server can send a crafted Set‑Cookie header to the undici client, which will then parse the SameSite value into a weaker token without detecting the change. Since parsing occurs client‑side and no extra privileges are needed, an attacker who can influence the server’s response can perform a low‑effort downgrade attack on any dependant application.