CVE-2026-120474 in undici
Summary
by MITRE • 11/06/2026
undici is an HTTP client for Node.js. In versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3, when the redirect interceptor and a shared response cache are used together, an authenticated request that is redirected to a same-origin target has the final response stored under the original request's cache key. That key omits the credential and carries no Vary header, so a later anonymous or different user can be served the first user's private response body. This results in cross-user disclosure of cached private responses. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified within the undici HTTP client library for Node.js represents a critical flaw in how cached responses are managed during redirect operations when specific caching mechanisms are enabled. Undici is widely used as a high-performance alternative to the native fetch API, and its efficiency relies heavily on response caching to reduce network latency. However, in versions ranging from 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3, the interaction between the redirect interceptor and a shared response cache creates a logic error that compromises data confidentiality. The core issue arises when an authenticated request undergoes a redirection to a same-origin target. In this scenario, the library incorrectly stores the final redirected response using the cache key derived from the original initial request rather than accounting for the full context of the redirect chain or the specific credentials used during authentication.
This technical flaw stems from the omission of critical caching directives and identifiers in the generated cache keys. Specifically, the cache key does not include the credential information associated with the authenticated session, nor does it incorporate a Vary header that would typically signal to caches that different responses may exist based on user identity or authorization status. By ignoring these factors, the system treats requests from different users as identical if they share the same initial URL and redirect path. Consequently, when an anonymous user or a different authenticated user subsequently makes a request with the same original parameters, the shared cache serves them the response intended for the first authenticated user. This results in a direct cross-user disclosure of private responses, allowing attackers to access sensitive data belonging to other users without needing additional exploitation techniques beyond simple HTTP requests.
The operational impact of this vulnerability is severe, particularly for applications that rely on undici for handling API calls involving personal or financial data. Since the cached response contains the body intended for a specific user, an attacker can trivially retrieve private information such as account details, email addresses, or transaction histories by manipulating request parameters to trigger the same redirect path used by victims. This aligns with CWE-200: Information Exposure and CWE-16: Configuration Error, as it reflects both a failure in proper access control enforcement within the caching layer and an incorrect configuration of cache keys that fail to differentiate between distinct user contexts. Furthermore, this behavior can be mapped to MITRE ATT&CK technique T1530: Data from Local System, specifically through remote data exfiltration via cached artifacts, although it is more accurately described as a broken access control scenario where the application fails to enforce proper separation of user-specific resources.
To mitigate this risk, organizations utilizing undici must immediately upgrade their dependencies to version 7.30.2 or later for the v7 branch, and version 8.12.4 or later for the v8 branch. These updated versions correct the logic within the redirect interceptor to ensure that cache keys are generated with sufficient granularity to account for authentication states and Vary headers. Until an upgrade is performed, developers should consider disabling shared response caching entirely if it is not strictly necessary for performance requirements, thereby eliminating the vector through which cross-user data leakage occurs. Additionally, implementing strict Cache-Control directives such as no-store or private on sensitive endpoints can provide a secondary layer of defense by instructing any intermediate caches to avoid storing these responses altogether. Regular auditing of third-party HTTP client configurations and ensuring that caching strategies align with security best practices for authenticated sessions are essential steps in maintaining the integrity of web application data handling processes.