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.
94 vulnerabilities reference this CWE, most recent first.
GHSA-P8PF-44FF-93GF
Vulnerability from github – Published: 2025-11-20 21:29 – Updated: 2025-11-21 15:32In authkit-nextjs version 2.11.0 and below, authenticated responses do not defensively apply anti-caching headers. In environments where CDN caching is enabled, this can result in session tokens being included in cached responses and subsequently served to multiple users.
Next.js applications deployed on Vercel are unaffected unless they manually enable CDN caching by setting cache headers on authenticated paths.
Impact
This vulnerability may lead to session caching, potentially allowing unauthorized users to obtain another user’s session token. The severity depends on deployment configuration, caching policy, and whether authenticated routes are inadvertently cached.
Patches
Patched in authkit-nextjs 2.11.1, which applies anti-caching headers to all responses behind authentication.
Notes
Authentication middleware should set anti-caching headers for authenticated routes as a defense in depth measure, but cannot guarantee these headers will not be overwritten elsewhere in the application. We recommend the following: - Review your application code, middleware, and infrastructure configuration to ensure the Cache-Control headers set for authenticated paths prevent inappropriate caching - For application paths that require caching, do not allow user-specific or sensitive authenticated information to be included in the response data or headers
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.11.0"
},
"package": {
"ecosystem": "npm",
"name": "@workos-inc/authkit-nextjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64762"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-20T21:29:16Z",
"nvd_published_at": "2025-11-21T02:15:44Z",
"severity": "HIGH"
},
"details": "In `authkit-nextjs` version 2.11.0 and below, authenticated responses do not defensively apply anti-caching headers. In environments where CDN caching is enabled, this can result in session tokens being included in cached responses and subsequently served to multiple users.\n\nNext.js applications deployed on Vercel are unaffected **unless** they manually enable CDN caching by setting cache headers on authenticated paths.\n\n### Impact\nThis vulnerability may lead to session caching, potentially allowing unauthorized users to obtain another user\u2019s session token. The severity depends on deployment configuration, caching policy, and whether authenticated routes are inadvertently cached.\n\n### Patches\nPatched in `authkit-nextjs` 2.11.1, which applies anti-caching headers to all responses behind authentication.\n\n### Notes\nAuthentication middleware should set anti-caching headers for authenticated routes as a defense in depth measure, but cannot guarantee these headers will not be overwritten elsewhere in the application. We recommend the following:\n - Review your application code, middleware, and infrastructure configuration to ensure the Cache-Control headers set for authenticated paths prevent inappropriate caching\n - For application paths that require caching, do not allow user-specific or sensitive authenticated information to be included in the response data or headers",
"id": "GHSA-p8pf-44ff-93gf",
"modified": "2025-11-21T15:32:21Z",
"published": "2025-11-20T21:29:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/workos/authkit-nextjs/security/advisories/GHSA-p8pf-44ff-93gf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64762"
},
{
"type": "WEB",
"url": "https://github.com/workos/authkit-nextjs/commit/94cf438124993abb0e7c19dac64c3cb5724a15ea"
},
{
"type": "PACKAGE",
"url": "https://github.com/workos/authkit-nextjs"
},
{
"type": "WEB",
"url": "https://github.com/workos/authkit-nextjs/releases/tag/v2.11.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "authkit-nextjs may let session cookies be cached in CDNs"
}
GHSA-PHF8-W34Q-995J
Vulnerability from github – Published: 2026-05-26 18:31 – Updated: 2026-05-28 15:39The InputFilter::getInstance() method omitted a security sensitive parameter from the instance cache key.
{
"affected": [],
"aliases": [
"CVE-2026-48901"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-26T17:16:54Z",
"severity": "HIGH"
},
"details": "The InputFilter::getInstance() method omitted a security sensitive parameter from the instance cache key.",
"id": "GHSA-phf8-w34q-995j",
"modified": "2026-05-28T15:39:41Z",
"published": "2026-05-26T18:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48901"
},
{
"type": "WEB",
"url": "https://developer.joomla.org/security-centre/1049-20260517-core-incorrect-cache-key-construction-for-inputfilter-objects.html"
}
],
"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-PJHX-3C3W-9V23
Vulnerability from github – Published: 2026-07-10 14:32 – Updated: 2026-07-10 14:32Impact
#[ApiProperty(security: ...)] is evaluated per request to decide whether a property is exposed. The componentsCache arrays in ApiPlatform\JsonApi\Serializer\ItemNormalizer and ApiPlatform\Hal\Serializer\ItemNormalizer are keyed on $context['cache_key'], which is set unconditionally before delegating to the parent normalizer. The component structure (attributes, relationships, links) computed for one request can therefore be reused for a subsequent request whose user has a different set of accessible properties. A user with lower privileges may end up seeing the structure of properties that the security predicate would otherwise have hidden for them.
This is the same vulnerability class as GHSA-428q-q3vv-3fq3 / CVE-2025-31485, which fixed only the GraphQL ItemNormalizer. The JSON:API and HAL paths were not addressed at the time.
Exploitation conditions
Exploitation requires all of the following to coincide:
- The application exposes a resource via the JSON:API and/or HAL formats.
- At least one property of that resource uses
#[ApiProperty(security: ...)]with a predicate whose result depends on the current user (or on per-request state). - A request from a user for whom the predicate evaluates to
truepopulatescomponentsCachebefore a request from a user for whom the predicate evaluates tofalse, within the lifetime of the same PHP process. - The deployment uses a long-running PHP runtime that keeps the normalizer instance alive across requests (FrankenPHP worker mode, RoadRunner, Swoole, ReactPHP, etc.). With classic
php-fpmworkers the cache only survives the duration of a single request, which makes the issue much harder to observe in practice.
Patches
- 4.1.29
- 4.2.25
- 4.3.8
All three branches receive patched releases of api-platform/core, api-platform/json-api, and api-platform/hal.
Workarounds
Override the JSON:API and HAL ItemNormalizer services to gate $context['cache_key'] with a resource-class security check, or avoid #[ApiProperty(security: ...)] on resources served as JSON:API or HAL until the patch is applied. Pinning the deployment to classic php-fpm workers also limits exposure since the cache does not survive across requests.
Credits
- Tillmann Baumgart (@tillmon) — originally identified the broader cache-key gap and proposed moving
isCacheKeySafetoAbstractItemNormalizer. - Antoine Bluchet (@soyuka) — extended the gate to JSON:API and HAL normalizers.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "api-platform/core"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "4.1.29"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "api-platform/core"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0"
},
{
"fixed": "4.2.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "api-platform/core"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0"
},
{
"fixed": "4.3.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "api-platform/json-api"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.1.29"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "api-platform/json-api"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0"
},
{
"fixed": "4.2.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "api-platform/json-api"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0"
},
{
"fixed": "4.3.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "api-platform/hal"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.1.29"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "api-platform/hal"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0"
},
{
"fixed": "4.2.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "api-platform/hal"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0"
},
{
"fixed": "4.3.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49858"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-10T14:32:01Z",
"nvd_published_at": "2026-07-01T20:17:10Z",
"severity": "MODERATE"
},
"details": "### Impact\n\n`#[ApiProperty(security: ...)]` is evaluated per request to decide whether a property is exposed. The `componentsCache` arrays in `ApiPlatform\\JsonApi\\Serializer\\ItemNormalizer` and `ApiPlatform\\Hal\\Serializer\\ItemNormalizer` are keyed on `$context[\u0027cache_key\u0027]`, which is set unconditionally before delegating to the parent normalizer. The component structure (attributes, relationships, links) computed for one request can therefore be reused for a subsequent request whose user has a different set of accessible properties. A user with lower privileges may end up seeing the structure of properties that the security predicate would otherwise have hidden for them.\n\nThis is the same vulnerability class as [GHSA-428q-q3vv-3fq3](https://github.com/api-platform/core/security/advisories/GHSA-428q-q3vv-3fq3) / CVE-2025-31485, which fixed only the GraphQL `ItemNormalizer`. The JSON:API and HAL paths were not addressed at the time.\n\n### Exploitation conditions\n\nExploitation requires all of the following to coincide:\n\n- The application exposes a resource via the JSON:API and/or HAL formats.\n- At least one property of that resource uses `#[ApiProperty(security: ...)]` with a predicate whose result depends on the current user (or on per-request state).\n- A request from a user for whom the predicate evaluates to `true` populates `componentsCache` before a request from a user for whom the predicate evaluates to `false`, within the lifetime of the same PHP process.\n- The deployment uses a long-running PHP runtime that keeps the normalizer instance alive across requests (FrankenPHP worker mode, RoadRunner, Swoole, ReactPHP, etc.). With classic `php-fpm` workers the cache only survives the duration of a single request, which makes the issue much harder to observe in practice.\n\n### Patches\n\n- 4.1.29\n- 4.2.25\n- 4.3.8\n\nAll three branches receive patched releases of `api-platform/core`, `api-platform/json-api`, and `api-platform/hal`.\n\n### Workarounds\n\nOverride the JSON:API and HAL `ItemNormalizer` services to gate `$context[\u0027cache_key\u0027]` with a resource-class security check, or avoid `#[ApiProperty(security: ...)]` on resources served as JSON:API or HAL until the patch is applied. Pinning the deployment to classic `php-fpm` workers also limits exposure since the cache does not survive across requests.\n\n### Credits\n\n- Tillmann Baumgart (@tillmon) \u2014 originally identified the broader cache-key gap and proposed moving `isCacheKeySafe` to `AbstractItemNormalizer`.\n- Antoine Bluchet (@soyuka) \u2014 extended the gate to JSON:API and HAL normalizers.",
"id": "GHSA-pjhx-3c3w-9v23",
"modified": "2026-07-10T14:32:01Z",
"published": "2026-07-10T14:32:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/api-platform/core/security/advisories/GHSA-pjhx-3c3w-9v23"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49858"
},
{
"type": "PACKAGE",
"url": "https://github.com/api-platform/core"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "API Platform Core vulnerable to cross-user attribute leak in JSON:API and HAL item normalizers due to missing isCacheKeySafe gate"
}
GHSA-PP8H-HGQ9-WFRJ
Vulnerability from github – Published: 2025-02-18 06:35 – Updated: 2025-02-18 06:35The Rapid Cache plugin for WordPress is vulnerable to Cache Poisoning in all versions up to, and including, 1.2.3. This is due to plugin storing HTTP headers in the cached data. This makes it possible for unauthenticated attackers to poison the cache with custom HTTP headers that may be unsanitized which can lead to Cross-Site Scripting.
{
"affected": [],
"aliases": [
"CVE-2024-12314"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-18T05:15:09Z",
"severity": "HIGH"
},
"details": "The Rapid Cache plugin for WordPress is vulnerable to Cache Poisoning in all versions up to, and including, 1.2.3. This is due to plugin storing HTTP headers in the cached data. This makes it possible for unauthenticated attackers to poison the cache with custom HTTP headers that may be unsanitized which can lead to Cross-Site Scripting.",
"id": "GHSA-pp8h-hgq9-wfrj",
"modified": "2025-02-18T06:35:38Z",
"published": "2025-02-18T06:35:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12314"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/rapid-cache"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/72b777ac-1870-4588-82fe-da96a784ec81?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PR7R-676H-XCF6
Vulnerability from github – Published: 2026-06-18 14:28 – Updated: 2026-06-18 14:28Impact
Undici's cache interceptor incorrectly classifies some responses as cacheable when the upstream Cache-Control header uses whitespace-padded qualified private or no-cache field names such as private=" authorization" or no-cache="\tauthorization". The parser preserves the surrounding whitespace, so later comparisons against the literal authorization field name fail and the response is stored.
In shared-cache mode, this allows a response containing one user's authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key.
Affected applications are those that explicitly enable the cache interceptor (interceptors.cache()) in shared mode, forward Authorization headers upstream, and receive cacheable responses with non-canonical qualified private or no-cache directives.
Patches
Upgrade to undici v7.28.0 or v8.5.0.
Workarounds
If upgrade is not immediately possible, disable shared-cache mode for traffic that includes Authorization headers, avoid caching responses to authenticated requests, or add Vary: Authorization upstream.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.28.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9678"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:28:13Z",
"nvd_published_at": "2026-06-17T18:18:06Z",
"severity": "MODERATE"
},
"details": "## Impact\n\nUndici\u0027s cache interceptor incorrectly classifies some responses as cacheable when the upstream `Cache-Control` header uses whitespace-padded qualified `private` or `no-cache` field names such as `private=\" authorization\"` or `no-cache=\"\\tauthorization\"`. The parser preserves the surrounding whitespace, so later comparisons against the literal `authorization` field name fail and the response is stored.\n\nIn shared-cache mode, this allows a response containing one user\u0027s authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key.\n\nAffected applications are those that explicitly enable the cache interceptor (`interceptors.cache()`) in shared mode, forward `Authorization` headers upstream, and receive cacheable responses with non-canonical qualified `private` or `no-cache` directives.\n\n## Patches\n\nUpgrade to undici v7.28.0 or v8.5.0.\n\n## Workarounds\n\nIf upgrade is not immediately possible, disable shared-cache mode for traffic that includes `Authorization` headers, avoid caching responses to authenticated requests, or add `Vary: Authorization` upstream.",
"id": "GHSA-pr7r-676h-xcf6",
"modified": "2026-06-18T14:28:13Z",
"published": "2026-06-18T14:28:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-pr7r-676h-xcf6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9678"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodejs/undici"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "undici vulnerable to cross-user information disclosure via shared cache whitespace bypass"
}
GHSA-Q6F4-QQRG-JV6X
Vulnerability from github – Published: 2026-06-15 16:51 – Updated: 2026-06-15 16:51A vulnerability was discovered in @angular/common when Server-Side Rendering (SSR) and hydration are enabled. The HttpTransferCache utility optimizes hydration by caching outgoing HTTP requests performed during SSR and transferring the cached state to the client-side application via TransferState.
However, the caching mechanism fails to inspect the withCredentials flag or the Cookie header of outgoing requests. As a result, credentialed, user-specific responses may be cached by default in the shared TransferState payload. When these responses are serialized into the HTML, any caching layer (such as a CDN, reverse proxy, or shared server cache) that caches the SSR-rendered HTML page could inadvertently cache and leak one user's private data to other users, leading to a high-severity information disclosure vulnerability.
Impact
Successful exploitation allows an unauthenticated attacker to obtain sensitive, user-specific information of other authenticated users. This occurs when:
- The SSR-rendered HTML containing the cached private data is stored in a shared cache (e.g., CDN, reverse proxy).
- Subsequent requests for the same page receive the cached HTML containing the first user's private data.
Attack Preconditions
- SSR and Hydration Enabled: The Angular application must be configured to use Server-Side Rendering and hydration (e.g., using
provideClientHydration()). - Credentialed Requests during SSR: The application must perform HTTP requests that require user-specific authentication (using cookies or
withCredentials: true) during the initial server-side render. - Shared Caching: The application's HTML responses must be cached by a shared caching layer (CDN, reverse proxy, or server-side cache) without proper cache-control headers to distinguish authenticated users.
Patches
- 22.0.0-rc.2
- 21.2.15
- 20.3.22
- 19.2.23
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "22.0.0-next.0"
},
{
"fixed": "22.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "20.0.0-next.0"
},
{
"fixed": "20.3.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "19.0.0-next.0"
},
{
"fixed": "19.2.23"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "18.2.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/common"
},
"ranges": [
{
"events": [
{
"introduced": "21.0.0-next.0"
},
{
"fixed": "21.2.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50170"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T16:51:53Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "A vulnerability was discovered in `@angular/common` when Server-Side Rendering (SSR) and hydration are enabled. The `HttpTransferCache` utility optimizes hydration by caching outgoing HTTP requests performed during SSR and transferring the cached state to the client-side application via `TransferState`.\n\nHowever, the caching mechanism fails to inspect the `withCredentials` flag or the `Cookie` header of outgoing requests. As a result, credentialed, user-specific responses may be cached by default in the shared `TransferState` payload. When these responses are serialized into the HTML, any caching layer (such as a CDN, reverse proxy, or shared server cache) that caches the SSR-rendered HTML page could inadvertently cache and leak one user\u0027s private data to other users, leading to a high-severity information disclosure vulnerability.\n\n### Impact\n\nSuccessful exploitation allows an unauthenticated attacker to obtain sensitive, user-specific information of other authenticated users. This occurs when:\n\n* The SSR-rendered HTML containing the cached private data is stored in a shared cache (e.g., CDN, reverse proxy). \n* Subsequent requests for the same page receive the cached HTML containing the first user\u0027s private data.\n\n### Attack Preconditions\n\n* **SSR and Hydration Enabled:** The Angular application must be configured to use Server-Side Rendering and hydration (e.g., using `provideClientHydration()`). \n* **Credentialed Requests during SSR:** The application must perform HTTP requests that require user-specific authentication (using cookies or `withCredentials: true`) during the initial server-side render. \n* **Shared Caching:** The application\u0027s HTML responses must be cached by a shared caching layer (CDN, reverse proxy, or server-side cache) without proper cache-control headers to distinguish authenticated users.\n\n### Patches\n- 22.0.0-rc.2\n- 21.2.15\n- 20.3.22\n- 19.2.23",
"id": "GHSA-q6f4-qqrg-jv6x",
"modified": "2026-06-15T16:51:53Z",
"published": "2026-06-15T16:51:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/angular/angular/security/advisories/GHSA-q6f4-qqrg-jv6x"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/pull/67964"
},
{
"type": "PACKAGE",
"url": "https://github.com/angular/angular"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "@angular/common: Information Leak via Default Caching of Credentialed Requests in HttpTransferCache"
}
GHSA-QPC8-7FXC-CM4P
Vulnerability from github – Published: 2026-06-03 15:30 – Updated: 2026-06-03 15:30An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6.
django.middleware.cache.UpdateCacheMiddleware in Django does not add Authorization to the Vary response header for requests bearing that header without Cache-Control: public, which allows remote attackers to read private cached responses via unauthenticated requests to the same URL.
Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Shai Berger for reporting this issue.
{
"affected": [],
"aliases": [
"CVE-2026-35193"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-03T14:16:41Z",
"severity": "LOW"
},
"details": "An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6.\n`django.middleware.cache.UpdateCacheMiddleware` in Django does not add `Authorization` to the `Vary` response header for requests bearing that header without `Cache-Control: public`, which allows remote attackers to read private cached responses via unauthenticated requests to the same URL.\nEarlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.\nDjango would like to thank Shai Berger for reporting this issue.",
"id": "GHSA-qpc8-7fxc-cm4p",
"modified": "2026-06-03T15:30:43Z",
"published": "2026-06-03T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35193"
},
{
"type": "WEB",
"url": "https://docs.djangoproject.com/en/dev/releases/security"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/django-announce"
},
{
"type": "WEB",
"url": "https://www.djangoproject.com/weblog/2026/jun/03/security-releases"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/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",
"type": "CVSS_V4"
}
]
}
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"
}
]
}
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.