MediumGHSA-v3r7-h72x-cjcmCVE-2026-16729

undici vulnerable to cookie attribute injection via unsanitized domain and unparsed setCookie fields

Published 3 Aug 2026 · Updated 10 Sept 2026

Affected packages

Affected
<6.28.0
Fixed in
6.28.0
Update to the fixed version for your release line, for example:npm install undici@6.28.0
Affected
>=7.0.0 <7.29.0
Fixed in
7.29.0
Update to the fixed version for your release line, for example:npm install undici@7.29.0
Affected
>=8.0.0 <8.9.0
Fixed in
8.9.0
Update to the fixed version for your release line, for example:npm install undici@8.9.0

Details

Impact

The setCookie function has two attribute injection paths. validateCookieDomain does not reject semicolons (validateCookiePath already does at 0x3B), so a domain value like example.com; SameSite=None lands verbatim as Domain=example.com; SameSite=None. The unparsed array's loop only checks each entry contains = and does not sanitize values, so an entry like X-Custom=val; HttpOnly lands unchanged, injecting HttpOnly without the caller setting cookie.httpOnly = true.

Applications that pass user-controlled input to these fields, typically multi-tenant or reverse-proxy servers that scope session cookies to a tenant-supplied domain, can have SameSite CSRF protections bypassed, Secure or HttpOnly forced or stripped, or the intended SameSite tier overridden.

Patches

Patched in undici v6.28.0, v7.29.0, and v8.9.0.

Workarounds

  • Sanitize domain values against the RFC 1034 letter-digit-hyphen set before passing to setCookie.
  • Do not pass user-controlled data to the unparsed field.

Is GHSA-v3r7-h72x-cjcm in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected undici, and gives you the command that fixes it.

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.