CWE-524
AllowedUse of Cache Containing Sensitive Information
Abstraction: Base · Status: Incomplete
The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.
93 vulnerabilities reference this CWE, most recent first.
GHSA-WW6G-3H8V-P3MX
Vulnerability from github – Published: 2026-07-09 21:31 – Updated: 2026-07-13 15:31An information disclosure vulnerability in Palo Alto Networks PAN-OS® software enables an unauthenticated attacker with network access to the management web interface to obtain web session tokens. This requires a legitimate user to first click on a malicious link provided by the attacker.
The security risk posed by this issue is minimized by restricting access to the management web interface to only trusted internal IP addresses according to our recommended best practice deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .
This issue is applicable to PAN-OS software on PA-Series and VM-Series firewalls and on Panorama (virtual and M-Series).
Cloud NGFW and Prisma® Access are not impacted by this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2026-0281"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-09T19:16:59Z",
"severity": "LOW"
},
"details": "An information disclosure vulnerability in Palo Alto Networks PAN-OS\u00ae software enables an unauthenticated attacker with network access to the management web interface to obtain web session tokens. This requires a legitimate user to first click on a malicious link provided by the attacker.\n\nThe security risk posed by this issue is minimized by restricting access to the management web interface to only trusted internal IP addresses according to our recommended best practice deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .\n\nThis issue is applicable to PAN-OS software on PA-Series and VM-Series firewalls and on Panorama (virtual and M-Series).\n\nCloud NGFW and Prisma\u00ae Access are not impacted by this vulnerability.",
"id": "GHSA-ww6g-3h8v-p3mx",
"modified": "2026-07-13T15:31:43Z",
"published": "2026-07-09T21:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0281"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2026-0281"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:U/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:N/R:A/V:D/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-X3HP-PWC8-RWW8
Vulnerability from github – Published: 2025-06-17 21:32 – Updated: 2025-08-29 21:32A binary in the BoKS Server Agent component of Fortra's Core Privileged Access Manager (BoKS) on versions 7.2.0 (up to 7.2.0.17), 8.1.0 (up to 8.1.0.22), 8.1.1 (up to 8.1.1.7), 9.0.0 (up to 9.0.0.1) and also legacy tar installs of BoKS 7.2 without hotfix #0474 on Linux, AIX, and Solaris allows low privilege local users to dump data from the cache.
{
"affected": [],
"aliases": [
"CVE-2025-5141"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-17T20:15:32Z",
"severity": "MODERATE"
},
"details": "A binary in the BoKS Server Agent component of Fortra\u0027s Core Privileged Access Manager (BoKS) on versions 7.2.0 (up to 7.2.0.17), 8.1.0 (up to 8.1.0.22), 8.1.1 (up to 8.1.1.7), 9.0.0 (up to 9.0.0.1) and also legacy tar installs of BoKS 7.2 without hotfix #0474 on Linux, AIX, and Solaris allows low privilege local users to dump data from the cache.",
"id": "GHSA-x3hp-pwc8-rww8",
"modified": "2025-08-29T21:32:02Z",
"published": "2025-06-17T21:32:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5141"
},
{
"type": "WEB",
"url": "https://www.cve.org/cverecord?id=CVE-2025-5141"
},
{
"type": "WEB",
"url": "https://www.fortra.com/security/advisories/product-security/fi-2025-008"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X4M5-4CW8-VC44
Vulnerability from github – Published: 2025-12-30 15:37 – Updated: 2026-01-05 22:35Summary
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.
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.
Solution
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
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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios-cache-interceptor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-69202"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-30T15:37:55Z",
"nvd_published_at": "2025-12-29T20:15:42Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nWhen a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass.\n\n## Details\n\nThe 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.\n\n## Impact\n\n**Affected:** Server-side applications (APIs, proxies, backend services) that:\n\n- Use axios-cache-interceptor to cache requests to upstream services\n- Handle requests from multiple users with different auth tokens\n- Upstream services replies on `Vary` to differentiate caches\n\n**Not affected:** Browser/client-side applications (single user per browser session).\n\nServices using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions.\n\n## Solution\n\nAfter `v1.11.1`, automatic `Vary` header support is now enabled by default.\n\nWhen server responds with `Vary: Authorization`, cache keys now include the authorization header value. Each user gets their own cache.\n\n```js\n// v1.11.1+ (automatic, no config needed)\n// User 123: key = hash(url + {authorization: \u0027Bearer 123\u0027})\n// User 456: key = hash(url + {authorization: \u0027Bearer 456\u0027})\n// \u2713 Different caches, no poisoning\n```\n\n## Remediation\n\nUpgrade to v1.11.1 or later. _No code changes required, protection is automatic_\n\n\n## Proof of Concept\n\n```js\nconst http = require(\u0027node:http\u0027);\nconst axios = require(\u0027axios\u0027);\nconst { setupCache } = require(\u0027axios-cache-interceptor\u0027);\n\n// Server that returns different responses based on Authorization\nconst server = http.createServer((req, res) =\u003e {\n const auth = req.headers.authorization;\n\n res.setHeader(\u0027Vary\u0027, \u0027Authorization\u0027);\n\n if (auth === \u0027Bearer 123\u0027) {\n res.write(\u0027Hello, user 123!\u0027);\n } else if (auth === \u0027Bearer 456\u0027) {\n res.write(\u0027Hello, user 456!\u0027);\n } else {\n res.write(\u0027Unknown\u0027);\n }\n\n res.end();\n});\n\nserver.listen(5000);\n\n// Client making requests with different tokens\nconst cachedAxios = setupCache(axios.create());\n\nconst server2 = http.createServer(async (_req, res) =\u003e {\n const authHeader =\n Math.random() \u003c 0.5 ? \u0027Bearer 123\u0027 : \u0027Bearer 456\u0027;\n\n const response = await cachedAxios.get(\u0027http://localhost:5000\u0027, {\n headers: { Authorization: authHeader }\n });\n\n console.log({\n response: response.data,\n cached: response.cached,\n auth: authHeader\n });\n res.write(response.data);\n res.end();\n});\n\nserver2.listen(5001);\n\n// Trigger 10 requests\nPromise.all(\n Array.from({ length: 10 }, () =\u003e\n axios.get(\u0027http://localhost:5001\u0027).catch(console.error)\n )\n).finally(() =\u003e {\n server.close();\n server2.close();\n});\n```\n\nAll 10 responses return \"Hello, user 123!\" even when using \"Bearer 456\" - users receive each other\u0027s cached data.",
"id": "GHSA-x4m5-4cw8-vc44",
"modified": "2026-01-05T22:35:17Z",
"published": "2025-12-30T15:37:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/arthurfiorette/axios-cache-interceptor/security/advisories/GHSA-x4m5-4cw8-vc44"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69202"
},
{
"type": "WEB",
"url": "https://github.com/arthurfiorette/axios-cache-interceptor/commit/49a808059dfc081b9cc23d48f243d55dfce15f01"
},
{
"type": "PACKAGE",
"url": "https://github.com/arthurfiorette/axios-cache-interceptor"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "axios-cache-interceptor Vulnerable to Cache Poisoning via Ignored HTTP Vary Header"
}
Mitigation
Protect information stored in cache.
Mitigation
Do not store unnecessarily sensitive information in the cache.
Mitigation
Consider using encryption in the cache.
CAPEC-204: Lifting Sensitive Data Embedded in Cache
An adversary examines a target application's cache, or a browser cache, for sensitive information. Many applications that communicate with remote entities or which perform intensive calculations utilize caches to improve efficiency. However, if the application computes or receives sensitive information and the cache is not appropriately protected, an attacker can browse the cache and retrieve this information. This can result in the disclosure of sensitive information.