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.
129 vulnerabilities reference this CWE, most recent first.
GHSA-R77M-QPX3-MPGM
Vulnerability from github – Published: 2025-04-24 21:31 – Updated: 2025-04-24 21:31Missing "no cache" headers in HCL Leap permits user directory information to be cached.
{
"affected": [],
"aliases": [
"CVE-2023-37516"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-24T21:15:21Z",
"severity": "LOW"
},
"details": "Missing \"no cache\" headers in HCL Leap permits user directory information to be cached.",
"id": "GHSA-r77m-qpx3-mpgm",
"modified": "2025-04-24T21:31:47Z",
"published": "2025-04-24T21:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37516"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0119900"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VPJP-GFPQ-57C9
Vulnerability from github – Published: 2026-06-08 18:31 – Updated: 2026-06-30 03:36In the Linux kernel, the following vulnerability has been resolved:
drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise
Add validation in xe_vm_madvise_ioctl() to reject PAT indices with XE_COH_NONE coherency mode when applied to CPU cached memory.
Using coh_none with CPU cached buffers is a security issue. When the kernel clears pages before reallocation, the clear operation stays in CPU cache (dirty). GPU with coh_none can bypass CPU caches and read stale sensitive data directly from DRAM, potentially leaking data from previously freed pages of other processes.
This aligns with the existing validation in vm_bind path (xe_vm_bind_ioctl_validate_bo).
v2(Matthew brost) - Add fixes - Move one debug print to better place
v3(Matthew Auld) - Should be drm/xe/uapi - More Cc
v4(Shuicheng Lin) - Fix kmem leak issues by the way
v5 - Remove kmem leak because it has been merged by another patch
v6 - Remove the fix which is not related to current fix
v7 - No change
v8 - Rebase
v9 - Limit the restrictions to iGPU
v10 - No change
(cherry picked from commit 016ccdb674b8c899940b3944952c96a6a490d10a)
{
"affected": [],
"aliases": [
"CVE-2026-46309"
],
"database_specific": {
"cwe_ids": [
"CWE-401",
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T17:16:49Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise\n\nAdd validation in xe_vm_madvise_ioctl() to reject PAT indices with\nXE_COH_NONE coherency mode when applied to CPU cached memory.\n\nUsing coh_none with CPU cached buffers is a security issue. When the\nkernel clears pages before reallocation, the clear operation stays in\nCPU cache (dirty). GPU with coh_none can bypass CPU caches and read\nstale sensitive data directly from DRAM, potentially leaking data from\npreviously freed pages of other processes.\n\nThis aligns with the existing validation in vm_bind path\n(xe_vm_bind_ioctl_validate_bo).\n\nv2(Matthew brost)\n- Add fixes\n- Move one debug print to better place\n\nv3(Matthew Auld)\n- Should be drm/xe/uapi\n- More Cc\n\nv4(Shuicheng Lin)\n- Fix kmem leak issues by the way\n\nv5\n- Remove kmem leak because it has been merged by another patch\n\nv6\n- Remove the fix which is not related to current fix\n\nv7\n- No change\n\nv8\n- Rebase\n\nv9\n- Limit the restrictions to iGPU\n\nv10\n- No change\n\n(cherry picked from commit 016ccdb674b8c899940b3944952c96a6a490d10a)",
"id": "GHSA-vpjp-gfpq-57c9",
"modified": "2026-06-30T03:36:57Z",
"published": "2026-06-08T18:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46309"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-46309"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2486468"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e5591c2fc1b30f4ea5e2eab4c3a695acc404e39"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87f9b1528e1ffc1da3615d552c9a06aba5e20b00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fea04cf6f2345bc50f15b6638906c35962b89424"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46309.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W4MM-GFHC-2P52
Vulnerability from github – Published: 2022-12-26 06:30 – Updated: 2023-01-04 03:30An issue was discovered in MediaWiki before 1.35.5, 1.36.x before 1.36.3, and 1.37.x before 1.37.1. The REST API publicly caches results from private wikis.
{
"affected": [],
"aliases": [
"CVE-2021-44854"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-26T05:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in MediaWiki before 1.35.5, 1.36.x before 1.36.3, and 1.37.x before 1.37.1. The REST API publicly caches results from private wikis.",
"id": "GHSA-w4mm-gfhc-2p52",
"modified": "2023-01-04T03:30:32Z",
"published": "2022-12-26T06:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44854"
},
{
"type": "WEB",
"url": "https://phabricator.wikimedia.org/T292763"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-24"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WG35-8JPF-2XV3
Vulnerability from github – Published: 2026-04-29 12:33 – Updated: 2026-07-02 21:23Spring MVC and WebFlux applications are vulnerable to cache poisoning when resolving static resources.
More precisely, an application can be vulnerable when all the following are true:
- the application is using Spring MVC or Spring WebFlux
- the application is configuring the resource chain support https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title with caching enabled
- the application adds support for encoded resources resolution
- the resource cache must be empty when the attacker has access to the application
When all the conditions above are met, the attacker can send malicious requests and poison the resource cache with resources using the wrong encoding. This can cause a denial of service by breaking the front-end application for clients.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.0.6"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.2.17"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.2.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"last_affected": "6.1.26"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.3.47"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.0.6"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.2.17"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.2.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"last_affected": "6.1.26"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.3.47"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22741"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T22:28:11Z",
"nvd_published_at": "2026-04-29T12:16:18Z",
"severity": "LOW"
},
"details": "Spring MVC and WebFlux applications are vulnerable to cache poisoning when resolving static resources.\n\n\nMore precisely, an application can be vulnerable when all the following are true:\n\n * the application is using Spring MVC or Spring WebFlux\n * the application is configuring the\u00a0 resource chain support https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title \u00a0with caching enabled\n * the application adds support for encoded resources resolution\n * the resource cache must be empty when the attacker has access to the application\n\n\nWhen all the conditions above are met, the attacker can send malicious requests and poison the resource cache with resources using the wrong encoding. This can cause a denial of service by breaking the front-end application for clients.",
"id": "GHSA-wg35-8jpf-2xv3",
"modified": "2026-07-02T21:23:59Z",
"published": "2026-04-29T12:33:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22741"
},
{
"type": "WEB",
"url": "https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-framework"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-22741"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Spring MVC and WebFlux applications are vulnerable to cache poisoning when resolving static resources."
}
GHSA-WJGR-CPJG-F2Q7
Vulnerability from github – Published: 2026-07-22 21:32 – Updated: 2026-07-27 18:31Smart Search indexing could render generated content using the indexing administrator’s identity instead of a public guest. Restricted or administrator-only content could consequently be stored in the public search index and disclosed to visitors.
{
"affected": [],
"aliases": [
"CVE-2026-64792"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-22T21:18:10Z",
"severity": "HIGH"
},
"details": "Smart Search indexing could render generated content using the indexing administrator\u2019s identity instead of a public guest. Restricted or administrator-only content could consequently be stored in the public search index and disclosed to visitors.",
"id": "GHSA-wjgr-cpjg-f2q7",
"modified": "2026-07-27T18:31:42Z",
"published": "2026-07-22T21:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64792"
},
{
"type": "WEB",
"url": "https://regularlabs.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WM8W-6QJM-CV43
Vulnerability from github – Published: 2026-08-05 21:14 – Updated: 2026-08-05 21:14Impact
When a page is covered by routeRules cache / swr / isr, Nuxt enables runtime payload extraction and serves /<page>/_payload.json. On affected versions the renderer stored the SSR payload in the shared cache:nuxt:payload storage under a path-only key (no cookie, authorization, or cache.varies dimension) and, on a later payload request, returned the cached entry before route middleware / page guards ran again.
As a result, once any authenticated user warms a protected, cached page, a subsequent GET /<page>/_payload.json from an unauthenticated client or a different authenticated user receives the first user's payload: the full SSR data for that route, including anything loaded via useFetch / useAsyncData (for example /api/me: profile, tenant, billing, token-like values). The HTML response stays correctly varied and protected; only the extracted payload leaks. Both cross-user (A warms, B receives A) and unauthenticated disclosure are exploitable. cache.varies does not mitigate it, because the payload cache ignores varies.
Introduced when runtime payload extraction landed for cached routes (#34410); the regression is specific to the 4.x line, where the runtime cache:nuxt:payload storage was added and the import.meta.prerender gate on the payload-cache read/writes was dropped. The 3.x line shipped the same feature with the gate intact and is not affected.
Patches
Fixed in nuxt@4.5.1. Runtime payload-cache reads and writes are again confined to prerendering (import.meta.prerender); at runtime, /<page>/_payload.json follows the normal render path so route middleware, routeRules.appMiddleware, and page guards run for the current request. main / v5 and the 3.x line already had this property, so 3.x is not affected.
Workarounds
- Set
experimental.payloadExtraction: false(reporter-validated): the standalone/_payload.jsonendpoint returns 404 and the page still serves a 200 with an inline payload. - Do not apply
cache/swr/isrto authenticated pages that render user-specific SSR data. - As defense-in-depth, require authentication for
/**/_payload.jsonat a proxy / CDN. - After upgrading, purge any CDN / platform cache that may already hold protected payloads.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.5.0"
},
"package": {
"ecosystem": "npm",
"name": "nuxt"
},
"ranges": [
{
"events": [
{
"introduced": "4.4.0"
},
{
"fixed": "4.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71316"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-05T21:14:33Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nWhen a page is covered by `routeRules` `cache` / `swr` / `isr`, Nuxt enables runtime payload extraction and serves `/\u003cpage\u003e/_payload.json`. On affected versions the renderer stored the SSR payload in the shared `cache:nuxt:payload` storage under a path-only key (no cookie, `authorization`, or `cache.varies` dimension) and, on a later payload request, returned the cached entry before route middleware / page guards ran again.\n\nAs a result, once any authenticated user warms a protected, cached page, a subsequent `GET /\u003cpage\u003e/_payload.json` from an unauthenticated client or a different authenticated user receives the first user\u0027s payload: the full SSR data for that route, including anything loaded via `useFetch` / `useAsyncData` (for example `/api/me`: profile, tenant, billing, token-like values). The HTML response stays correctly varied and protected; only the extracted payload leaks. Both cross-user (A warms, B receives A) and unauthenticated disclosure are exploitable. `cache.varies` does not mitigate it, because the payload cache ignores `varies`.\n\nIntroduced when runtime payload extraction landed for cached routes (#34410); the regression is specific to the 4.x line, where the runtime `cache:nuxt:payload` storage was added and the `import.meta.prerender` gate on the payload-cache read/writes was dropped. The 3.x line shipped the same feature with the gate intact and is not affected.\n\n### Patches\n\nFixed in `nuxt@4.5.1`. Runtime payload-cache reads and writes are again confined to prerendering (`import.meta.prerender`); at runtime, `/\u003cpage\u003e/_payload.json` follows the normal render path so route middleware, `routeRules.appMiddleware`, and page guards run for the current request. `main` / v5 and the `3.x` line already had this property, so 3.x is not affected.\n\n### Workarounds\n\n- Set `experimental.payloadExtraction: false` (reporter-validated): the standalone `/_payload.json` endpoint returns 404 and the page still serves a 200 with an inline payload.\n- Do not apply `cache` / `swr` / `isr` to authenticated pages that render user-specific SSR data.\n- As defense-in-depth, require authentication for `/**/_payload.json` at a proxy / CDN.\n- After upgrading, purge any CDN / platform cache that may already hold protected payloads.",
"id": "GHSA-wm8w-6qjm-cv43",
"modified": "2026-08-05T21:14:33Z",
"published": "2026-08-05T21:14:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nuxt/nuxt/security/advisories/GHSA-wm8w-6qjm-cv43"
},
{
"type": "WEB",
"url": "https://github.com/nuxt/nuxt/commit/ac9b41a36b62296a117862254ee7d2b21a2a5203"
},
{
"type": "PACKAGE",
"url": "https://github.com/nuxt/nuxt"
},
{
"type": "WEB",
"url": "https://github.com/nuxt/nuxt/releases/tag/v4.5.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Nuxt runtime payload cache discloses another user\u0027s SSR data across users and to unauthenticated clients"
}
GHSA-WW6G-3H8V-P3MX
Vulnerability from github – Published: 2026-07-09 21:31 – Updated: 2026-08-11 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-08-11T15:31:56Z",
"published": "2026-07-09T21:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0281"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-104023.html"
},
{
"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.