Description

undici's cache interceptor documents that only safe HTTP methods are cached, but its logic to skip caching is built by subtracting the configured methods from the set of safe methods, so an unsafe method such as POST, PUT, or DELETE is never placed in the skip list and instead falls through to the full cache-read path. The response-storage gate also lacked a method check, so a response to an unsafe request that is heuristically cacheable or carries an explicit Cache-Control directive is stored and later replayed from cache. Because response headers from a remote origin are untrusted, an origin can answer once with a cacheable status and then have the client's own subsequent state-changing requests to that path served from the stale cache entry without ever reaching the origin, an integrity failure that occurs under the interceptor's default configuration. This affects undici versions from 7.0.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-09-04T17:17:02.347Z",
  "pubdate": "2026-09-04T17:17:02.347Z",
  "executiveSummary": "The Undici library contains a critical cache integrity vulnerability that allows unsafe HTTP methods to be incorrectly cached, leading to unauthorized response replay.\nThis vulnerability is classified as an improper restriction of cacheable operations, where the cache interceptor fails to filter non-idempotent methods like POST, PUT, and DELETE.\nThe flaw affects Undici versions 7.0.0 through 7.29.0 and 8.0.0 through 8.10.1.\nAn attacker can exploit this by forcing the cache to store a response to an unsafe request, which is then replayed during subsequent requests to the same path, effectively bypassing server-side logic and state changes.\nThe risk implication is high, as it allows for unauthorized manipulation of the client-side state and can potentially lead to data integrity failures and the serving of stale, untrusted content to the application.\nExploitation does not require prior authentication or elevated privileges, as it relies on the interceptor's inherent logical flaws in filtering HTTP methods before storage and retrieval.",
  "technicalDetails": "The root cause of the vulnerability lies in a flawed logic implementation within the Undici cache interceptor responsible for determining which HTTP methods are eligible for caching. The implementation calculates the skip-cache criteria by performing a subtraction operation against a set of safe methods, resulting in the exclusion of unsafe methods (e.g., POST, PUT, DELETE) from the exclusion list.\nConsequently, unsafe requests are erroneously permitted to proceed through the full cache-read path. Furthermore, the response-storage mechanism lacks a secondary validation check to verify the HTTP method type, allowing responses to unsafe requests—provided they contain heuristic cacheability hints or explicit Cache-Control headers—to be persisted in the cache store.\nIn a typical attack flow, an attacker leverages a malicious or compromised remote origin. The client initiates a request to the origin, which responds with a cacheable status or headers. Because the interceptor fails to differentiate between idempotent and state-changing methods, it stores the response. When the client subsequently performs a state-changing request (e.g., a POST request to update resource state), the cache interceptor intercepts the request, incorrectly matches it against the stored entry, and serves the cached response instead of allowing the request to reach the origin.\nThis behavior results in a significant integrity failure. Subsequent requests that should trigger server-side state updates are suppressed by the cache layer, forcing the client to interact with stale or fraudulent data stored previously. Because the response headers from the origin are processed as untrusted input without adequate validation of the method context, the origin retains control over when and how this corruption occurs.\nThe vulnerability affects the core caching logic in Undici versions 7.0.0 up to 7.29.1 (exclusive) and 8.0.0 up to 8.10.2 (exclusive). The lack of method-aware gating in both the storage and retrieval functions permits this cache poisoning scenario to manifest under default configuration settings, requiring no specialized authentication or privilege level from the attacker to initiate."
}