axios-cache-interceptor
CVE-2025-69202
MEDIUM
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AC:H/PR:L because a valid token plus a pre-populated cross-user cache entry are needed; S:C and C:H because a cache-library flaw leaks another authorization context's data, with I:L for stale/incorrect served data and A:N.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
3Blast Radius
ecosystem impact- 6 npm packages depend on axios-cache-interceptor (1 direct, 5 indirect)
Ecosystem-wide dependent count for version 1.11.1.
DescriptionCVE.org
Axios Cache Interceptor is a cache interceptor for axios. Prior to version 1.11.1, when a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass. The cache key is generated only from the URL, ignoring request headers like Authorization. When the server responds with Vary: Authorization (indicating the response varies by auth token), the library ignores this, causing all requests to share the same cache regardless of authorization. Server-side applications (APIs, proxies, backend services) that use axios-cache-interceptor to cache requests to upstream services, handle requests from multiple users with different auth tokens, and upstream services replies on Vary to differentiate caches are affected. Browser/client-side applications (single user per browser session) are not affected. Services using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions. After v1.11.1, automatic Vary header support is now enabled by default. When server responds with Vary: Authorization, cache keys now include the authorization header value. Each user gets their own cache.
AnalysisAI
Cached HTTP responses can be served to the wrong authenticated user in axios-cache-interceptor before 1.11.1, leaking data across sessions and bypassing authorization checks in server-side deployments. The library builds its cache key from the request URL alone and ignores the upstream's Vary: Authorization response header, so when a backend, proxy, or API serves multiple users with different bearer tokens through a single cache instance, an authenticated attacker holding a valid low-privileged token (CVSS PR:L) who requests the same URL can receive another user's cached response; exploitation is timing- and configuration-dependent because the victim's response must already be cached. Publicly available exploit code exists (a full proof-of-concept is published in the GitHub advisory), while EPSS is low at 0.32% (22nd percentile) and CISA KEV does not list this issue, making this a genuine but conditional authorization-bypass flaw of moderate rather than urgent risk.
Technical ContextAI
axios-cache-interceptor is a caching layer for the Axios HTTP client, used mainly in Node.js server-side applications such as APIs, proxies, and backend services (CPE: cpe:2.3:a:axios-cache-interceptor:axios_cache_interceptor:*:*:*:*:*:node.js:*:*). The root cause is CWE-524 (Use of Cache Containing Sensitive Information): the cache key was generated only from the request URL, so request headers such as Authorization were never part of the key, and the library ignored the upstream's Vary response header, which HTTP semantics (RFC 9111) define as the mechanism for indicating that a response varies by a named request header. When an upstream returns Vary: Authorization, every token should produce a distinct cache entry, but vulnerable versions collapsed them into one, causing cross-session cache poisoning and information disclosure. The fix commit 49a808059dfc081b9cc23d48f243d55dfce15f01 reworks header handling in the request interceptor and vary-extraction code (migrating from plain header objects to AxiosHeaders .get()/.set() accessors, updating CachedResponseMeta.vary types, and adjusting the stale-request logic), and from 1.11.1 onward automatic Vary support is enabled by default so the authorization header value is folded into the cache key. Note the vulnerability only manifests when the upstream service actually emits Vary: Authorization and the deployment shares one cache across multiple authenticated identities; browser/client-side single-session applications are explicitly not affected.
RemediationAI
Vendor-released patch: upgrade axios-cache-interceptor to version 1.11.1 or later - no application code changes are required because automatic Vary header support is enabled by default in that release, so each authorization value gets its own cache entry (see the advisory at https://github.com/arthurfiorette/axios-cache-interceptor/security/advisories/GHSA-x4m5-4cw8-vc44 and the upstream commit https://github.com/arthurfiorette/axios-cache-interceptor/commit/49a808059dfc081b9cc23d48f243d55dfce15f01). If an immediate upgrade is not possible, the actionable compensating controls are: disable caching for authenticated upstream calls (set cache: false on those requests, or in the worst case remove the interceptor from the shared client), which eliminates the leak but shifts full request load and latency back onto the upstream service; or supply a custom cacheKey generator that explicitly incorporates the Authorization header value into the key, which restores per-user isolation at the cost of maintaining bespoke key logic and increasing cache entry count and memory usage. Restricting all upstream traffic that relies on Vary to a single shared credential removes the cross-user exposure but also removes the multi-tenant authorization model, and should be treated only as a temporary containment step until 1.11.1 is deployed.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
Node.js 8.5.0 before 8.6.0 allows remote attackers to access unintended files, because a change to ".." handling was inc
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
Directory traversal vulnerability in the st module before 0.2.5 for Node.js allows remote attackers to read arbitrary fi
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
Eval injection vulnerability in index.js in the syntax-error package before 1.1.1 for Node.js 0.10.x, as used in IBM Rat
The DES and Triple DES ciphers, as used in the TLS, SSH, and IPSec protocols and other protocols and products, have a bi
An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. Rated med
crypto/rsa/rsa_ameth.c in OpenSSL 1.0.1 before 1.0.1q and 1.0.2 before 1.0.2e allows remote attackers to cause a denial
During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime v
Integer overflow in the EVP_EncodeUpdate function in crypto/evp/encode.c in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today