Summary
axios-cache-interceptor Vulnerable to Cache Poisoning via Ignored HTTP Vary Header
When a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass.
Details
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.
Remediation
Upgrade to v1.11.1 or later. No code changes required, protection is automatic
Proof of Concept
const http = require('node:http');
const axios = require('axios');
const { setupCache } = require('axios-cache-interceptor');
// Server that returns different responses based on Authorization
const server = http.createServer((req, res) => {
const auth = req.headers.authorization;
res.setHeader('Vary', 'Authorization');
if (auth === 'Bearer 123') {
res.write('Hello, user 123!');
} else if (auth === 'Bearer 456') {
res.write('Hello, user 456!');
} else {
res.write('Unknown');
}
res.end();
});
server.listen(5000);
// Client making requests with different tokens
const cachedAxios = setupCache(axios.create());
const server2 = http.createServer(async (_req, res) => {
const authHeader =
Math.random() < 0.5 ? 'Bearer 123' : 'Bearer 456';
const response = await cachedAxios.get('http://localhost:5000', {
headers: { Authorization: authHeader }
});
console.log({
response: response.data,
cached: response.cached,
auth: authHeader
});
res.write(response.data);
res.end();
});
server2.listen(5001);
// Trigger 10 requests
Promise.all(
Array.from({ length: 10 }, () =>
axios.get('http://localhost:5001').catch(console.error)
)
).finally(() => {
server.close();
server2.close();
});
All 10 responses return "Hello, user 123!" even when using "Bearer 456" - users receive each other's cached data.
Impact
Affected: 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
- Upstream services replies on
Varyto differentiate caches
Not affected: Browser/client-side applications (single user per browser session).
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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
// v1.11.1+ (automatic, no config needed)
// User 123: key = hash(url + {authorization: 'Bearer 123'})
// User 456: key = hash(url + {authorization: 'Bearer 456'})
// ✓ Different caches, no poisoning
Frequently Asked Questions
- What is CVE-2025-69202? CVE-2025-69202 is a medium-severity security vulnerability in axios-cache-interceptor (npm), affecting versions < 1.11.1. It is fixed in 1.11.1.
- Which versions of axios-cache-interceptor are affected by CVE-2025-69202? axios-cache-interceptor (npm) versions < 1.11.1 is affected.
- Is there a fix for CVE-2025-69202? Yes. CVE-2025-69202 is fixed in 1.11.1. Upgrade to this version or later.
- Is CVE-2025-69202 exploitable, and should I be worried? Whether CVE-2025-69202 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2025-69202 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2025-69202? Upgrade
axios-cache-interceptorto 1.11.1 or later.