CVE-2026-13697

This vulnerability in Undici's cache interceptor has two failure modes that compound each other's risk. First, the cache storage logic accepts and stores responses with `private=""` (an empty-value directive that semantically means 'do not cache') into the shared cache — meaning responses intended for one caller can be served to others. Second, the Cache-Control parser throws an uncaught TypeError on certain malformed headers, which can crash the process or reject the request entirely. The concerning part isn't just either bug in isolation — it's the compound blast radius. When a malformed header triggers the TypeError crash, operators see the error, investigate, restart processes, and move on. That operational noise masks the simultaneous cache poisoning. An attacker triggering the crash gets a smoke alarm that keeps you from noticing the silent data leakage happening in the cache layer. The crash is the feature that makes the cache poisoning viable for longer undetected windows. This affects versions 7.0.0 through 7.29.0. The 29-version window before discovery is notable — it suggests standard test suites weren't exercising malformed Cache-Control headers, and the defects went undetected because they don't produce obvious error states in normal operation. What to check: Review whether your undici usage enables the cache interceptor. If it does, audit your configuration — ensure you're not using shared caching for endpoints that return private data. After patching, audit the cache state in long-running processes to determine whether poisoning already occurred. Implement error handling around requests even when using a library that should abstract HTTP complexity — the TypeError demonstrates that abstraction boundaries aren't guaranteed against non-compliant server responses.

Reviewed through automated stages and approved by a human before publication.