CVE-2026-13697 is a high severity flaw (CVSS 7.4) in undici, the Node.js HTTP client. The cache interceptor can store a response with a malformed private directive and serve it to another caller, and a different header shape can crash the process. Upgrade to undici 7.29.0 or 8.9.0.
What's affected
Per the GitHub advisory, undici 7.0.0 up to before 7.29.0 and 8.0.0 up to before 8.9.0 are affected. The fixed versions are 7.29.0 and 8.9.0.
Only applications that use the cache interceptor in shared mode are exposed, and shared is the default mode. Node.js bundles its own copy of undici for fetch, so also check your Node release notes if you use fetch with caching on. The advisory does not make that claim, so confirm with the Node.js project.
The two issues share one fix. Both live in the cache handling code and both are closed by the same patch, so you do not need to choose between them. If your lock file pins undici below the fixed versions through a transitive dependency, update the parent package or add an override so the fixed release resolves.
How to check if you're exposed
Find which undici versions your project resolves:
npm ls undici
npm why undici
Then search your code for the cache interceptor:
grep -rn "interceptors.cache" src/
If nothing calls it, the two issues do not apply to your code path. If it is used, check whether it runs in shared mode and whether upstream responses can carry user specific data.
You can also paste a package.json or lock file into the free dependency scan to see undici versions at a glance.
For transitive pins, use an override:
{
"overrides": {
"undici": "7.29.0"
}
}
After the install, run npm ls undici again and confirm every path shows a fixed version. For Yarn and pnpm, use resolutions and overrides in the same way.
Also check which major line you are on. The 7 line is fixed in 7.29.0 and the 8 line in 8.9.0. Versions of undici before 7.0.0 are not named in the advisory, so check the project page if you run an older one.
What to do now
- Run npm ls undici in every Node project and image.
- Upgrade to 7.29.0 or 8.9.0, or a later release on your major line.
- Rebuild lock files and container images so the new version is what ships.
- If you cannot upgrade, avoid the shared cache for user specific responses, use type private, or disable caching for affected origins, as the advisory suggests.
- Add a Vary header or a per user cache key on responses that carry user data.
- Add a response header review for any upstream that sets Cache-Control private directives with values, and look for empty values.
- After patching, send a test request through your cache with a private response and confirm a second caller does not receive it.
Why it matters
A shared cache is allowed to keep a response and hand it to anyone who asks for the same key. The Cache-Control private directive tells it not to. In undici, a private directive with an empty or degenerate value was handled wrongly, so the response was stored as if it were public. A later caller with the same key could then read private bodies and headers, including Set-Cookie.
The second issue is a parser bug. A header that combines private with a qualified private directive raised an uncaught TypeError, which rejects the request and may end the process depending on error handling. The record lists the classes CWE-200, CWE-248 and CWE-525. It does not flag this CVE as known exploited.
Caching bugs are quiet because the application keeps working. The leak only shows when two different users hit the same key, so tests that use one user will never see it. A cache key that includes the user, or a Vary header on the credential, closes the same class of mistake in your own code.
The record lists these weakness classes: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), CWE-248 (Uncaught Exception), CWE-525 (Use of Web Browser Cache Containing Sensitive Information).
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does every undici user need to patch in a hurry?
The exposure requires the cache interceptor in shared mode and an upstream that returns a malformed directive. Many projects never enable the cache, but upgrading is cheap and removes the doubt.
What is the fastest stopgap?
The advisory lists three: avoid the shared interceptor for user specific responses, use type private, or disable caching for affected origins.
What does the Vary header have to do with it?
The advisory says a later request must match the same cache key without a separating Vary header. Varying the cache on user specific headers keeps callers apart.
Which setting limits the damage until I patch?
The advisory suggests type private for the cache, avoiding the shared interceptor for user specific responses, or disabling caching for affected origins.
Sources
Last reviewed: 19 October 2026.
