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.
134 vulnerabilities reference this CWE, most recent first.
GHSA-68G3-V927-F742
Vulnerability from github – Published: 2026-07-22 23:08 – Updated: 2026-07-22 23:08Impact
A server-side fetch with a request body may return a cached response body from a different request to the same URL but different body. Confidential data in the POST's response body would then leak to unauthorized requests. Though the request itself will not be deduped.
This only applies to fetch calls with a request that has a different init than the one passed to fetch.
Safe: fetch(new Request(init), init)
Unsafe: fetch(new Request(init), aDifferentInit)
Workarounds
No workaround exists besides upgrading. Applications using Pages Router are not vulnerable.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0"
},
{
"fixed": "15.5.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0"
},
{
"fixed": "16.2.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-64648"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T23:08:17Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Impact\n\nA server-side `fetch` with a request body may return a cached **response** body from a different request to the same URL but different body. Confidential data in the `POST`\u0027s **response** body would then leak to unauthorized requests. Though the request itself will not be deduped.\n\nThis only applies to `fetch` calls with a request that has a different init than the one passed to `fetch`.\nSafe: `fetch(new Request(init), init)`\nUnsafe: `fetch(new Request(init), aDifferentInit)`\n\n## Workarounds\n\nNo workaround exists besides upgrading. Applications using Pages Router are not vulnerable.",
"id": "GHSA-68g3-v927-f742",
"modified": "2026-07-22T23:08:17Z",
"published": "2026-07-22T23:08:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/security/advisories/GHSA-68g3-v927-f742"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/commit/062f66700b52a5d6bba2c0605d55577ab7ad262c"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/commit/73b94872bc343d09494b50394d8c08eb9fc8e56a"
},
{
"type": "PACKAGE",
"url": "https://github.com/vercel/next.js"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/releases/tag/v15.5.21"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/releases/tag/v16.2.11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Next.js: Cache confusion of response bodies for requests with bodies"
}
GHSA-68RP-WP8R-4726
Vulnerability from github – Published: 2026-02-19 20:45 – Updated: 2026-02-23 22:28When the session object is accessed, Flask should set the Vary: Cookie header. This instructs caches not to cache the response, as it may contain information specific to a logged in user. This is handled in most cases, but some forms of access such as the Python in operator were overlooked.
The severity depends on the application's use of the session, and the cache's behavior regarding cookies. The risk depends on all these conditions being met.
- The application must be hosted behind a caching proxy that does not ignore responses with cookies.
- The application does not set a
Cache-Controlheader to indicate that a page is private or should not be cached. - The application accesses the session in a way that does not access the values, only the keys, and does not mutate the session.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "flask"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27205"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-19T20:45:41Z",
"nvd_published_at": "2026-02-21T06:17:00Z",
"severity": "LOW"
},
"details": "When the `session` object is accessed, Flask should set the `Vary: Cookie` header. This instructs caches not to cache the response, as it may contain information specific to a logged in user. This is handled in most cases, but some forms of access such as the Python `in` operator were overlooked.\n\nThe severity depends on the application\u0027s use of the session, and the cache\u0027s behavior regarding cookies. The risk depends on all these conditions being met.\n\n1. The application must be hosted behind a caching proxy that does not ignore responses with cookies.\n2. The application does not set a `Cache-Control` header to indicate that a page is private or should not be cached.\n3. The application accesses the session in a way that does not access the values, only the keys, and does not mutate the session.",
"id": "GHSA-68rp-wp8r-4726",
"modified": "2026-02-23T22:28:03Z",
"published": "2026-02-19T20:45:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pallets/flask/security/advisories/GHSA-68rp-wp8r-4726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27205"
},
{
"type": "WEB",
"url": "https://github.com/pallets/flask/commit/089cb86dd22bff589a4eafb7ab8e42dc357623b4"
},
{
"type": "PACKAGE",
"url": "https://github.com/pallets/flask"
},
{
"type": "WEB",
"url": "https://github.com/pallets/flask/releases/tag/3.1.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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",
"type": "CVSS_V4"
}
],
"summary": "Flask session does not add `Vary: Cookie` header when accessed in some ways"
}
GHSA-6WQW-2P9W-4VW4
Vulnerability from github – Published: 2026-01-27 19:04 – Updated: 2026-01-29 03:39Summary
Cache Middleware contains an information disclosure vulnerability caused by improper handling of HTTP cache control directives. The middleware does not respect standard cache control headers such as Cache-Control: private or Cache-Control: no-store, which may result in private or authenticated responses being cached and subsequently exposed to unauthorized users.
Details
The vulnerability exists in the cache decision logic of Cache Middleware. When determining whether a response should be cached, the middleware does not take HTTP cache control semantics into account and may cache responses that are explicitly marked as private by the application. While some runtimes, such as Cloudflare Workers, enforce cache control restrictions at the platform level, other runtimes including Deno, Bun, and Node.js rely on the middleware’s behavior. As a result, applications running on these runtimes may unintentionally cache sensitive responses.
Impact
This issue can lead to Web Cache Deception and information disclosure. If an authenticated user accesses an endpoint that returns user-specific or sensitive data and the response is cached despite being marked as private, subsequent unauthenticated requests may receive the cached response. This may result in the exposure of personally identifiable information or session-related data. The impact is limited to applications that use the hono/cache middleware and rely on it to correctly honor HTTP cache control directives.
Affected Components
- Cache Middleware
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "hono"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.11.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24472"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-27T19:04:17Z",
"nvd_published_at": "2026-01-27T20:16:22Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nCache Middleware contains an information disclosure vulnerability caused by improper handling of HTTP cache control directives. The middleware does not respect standard cache control headers such as `Cache-Control: private` or `Cache-Control: no-store`, which may result in private or authenticated responses being cached and subsequently exposed to unauthorized users.\n\n## Details\n\nThe vulnerability exists in the cache decision logic of Cache Middleware. When determining whether a response should be cached, the middleware does not take HTTP cache control semantics into account and may cache responses that are explicitly marked as private by the application. While some runtimes, such as Cloudflare Workers, enforce cache control restrictions at the platform level, other runtimes including Deno, Bun, and Node.js rely on the middleware\u2019s behavior. As a result, applications running on these runtimes may unintentionally cache sensitive responses.\n\n## Impact\n\nThis issue can lead to Web Cache Deception and information disclosure. If an authenticated user accesses an endpoint that returns user-specific or sensitive data and the response is cached despite being marked as private, subsequent unauthenticated requests may receive the cached response. This may result in the exposure of personally identifiable information or session-related data. The impact is limited to applications that use the hono/cache middleware and rely on it to correctly honor HTTP cache control directives.\n\n## Affected Components\n\n* Cache Middleware",
"id": "GHSA-6wqw-2p9w-4vw4",
"modified": "2026-01-29T03:39:36Z",
"published": "2026-01-27T19:04:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-6wqw-2p9w-4vw4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24472"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/commit/12c511745b3f1e7a3f863a23ce5f921c7fa805d1"
},
{
"type": "PACKAGE",
"url": "https://github.com/honojs/hono"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/releases/tag/v4.11.7"
}
],
"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"
}
],
"summary": "Hono cache middleware ignores \"Cache-Control: private\" leading to Web Cache Deception"
}
GHSA-7FQM-JM52-F9VC
Vulnerability from github – Published: 2022-09-29 00:00 – Updated: 2024-10-16 21:36rdiffweb prior to version 2.4.9 is vulnerable to Use of Cache Containing Sensitive Information. Due to improper cache control, an attacker can view sensitive information even if they are not logged into an account. Version 2.4.9 contains a patch for this issue.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "rdiffweb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3292"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T05:37:28Z",
"nvd_published_at": "2022-09-28T21:15:00Z",
"severity": "MODERATE"
},
"details": "rdiffweb prior to version 2.4.9 is vulnerable to Use of Cache Containing Sensitive Information. Due to improper cache control, an attacker can view sensitive information even if they are not logged into an account. Version 2.4.9 contains a patch for this issue.",
"id": "GHSA-7fqm-jm52-f9vc",
"modified": "2024-10-16T21:36:40Z",
"published": "2022-09-29T00:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3292"
},
{
"type": "WEB",
"url": "https://github.com/ikus060/rdiffweb/commit/2406780831618405a13113377a784f3102465f40"
},
{
"type": "PACKAGE",
"url": "https://github.com/ikus060/rdiffweb"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/rdiffweb/PYSEC-2022-296.yaml"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/e9309018-e94f-4e15-b7d1-5d38b6021c5d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "rdiffweb vulnerable to Use of Cache Containing Sensitive Information"
}
GHSA-7JXJ-RPX7-PH2C
Vulnerability from github – Published: 2026-01-22 18:06 – Updated: 2026-01-22 18:06Impact
Protected files uploaded through Umbraco Forms may be served to unauthenticated users when a CDN or caching layer is present and ImageSharp processes the request. ImageSharp sets aggressive cache headers by default, which can cause intermediary caches to store and serve files that should require authentication.
Patches
This issue affects all (supported) versions Umbraco Forms and is patched in 13.9.0, 16.4.0 and 17.1.0.
Workarounds
Add middleware to set cache headers for form uploads. Place the following code in your Startup.cs or Program.cs after app.UseStaticFiles() and any image processing middleware:
app.Use(async (context, next) =>
{
var path = context.Request.Path.Value;
if (!string.IsNullOrEmpty(path) && path.StartsWith("/media/forms/upload/", StringComparison.OrdinalIgnoreCase))
{
context.Response.OnStarting(() =>
{
context.Response.Headers["Cache-Control"] = "private, no-store, no-cache, must-revalidate";
context.Response.Headers["Pragma"] = "no-cache";
context.Response.Headers["Expires"] = "0";
return Task.CompletedTask;
});
}
await next();
});
Alternatively, configure your CDN to bypass caching for URLs matching /media/forms/upload/*.
Note: The vulnerability requires: - A CDN in front of the website - An authenticated user having previously requested the image - Knowledge of the form GUID, entry GUID, and image filename
If no CDN is in use, this vulnerability does not apply.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Umbraco.Forms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "13.9.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Umbraco.Forms"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0-beta001"
},
{
"fixed": "16.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Umbraco.Forms"
},
"ranges": [
{
"events": [
{
"introduced": "17.0.0-rc1"
},
{
"fixed": "17.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-22T18:06:01Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nProtected files uploaded through Umbraco Forms may be served to unauthenticated users when a CDN or caching layer is present and ImageSharp processes the request. ImageSharp sets aggressive cache headers by default, which can cause intermediary caches to store and serve files that should require authentication.\n\n### Patches\nThis issue affects all (supported) versions Umbraco Forms and is patched in 13.9.0, 16.4.0 and 17.1.0.\n\n### Workarounds\nAdd middleware to set cache headers for form uploads. Place the following code in your `Startup.cs` or `Program.cs` after `app.UseStaticFiles()` and any image processing middleware:\n\n```cs\napp.Use(async (context, next) =\u003e\n{\n var path = context.Request.Path.Value;\n\n if (!string.IsNullOrEmpty(path) \u0026\u0026 path.StartsWith(\"/media/forms/upload/\", StringComparison.OrdinalIgnoreCase))\n {\n context.Response.OnStarting(() =\u003e\n {\n context.Response.Headers[\"Cache-Control\"] = \"private, no-store, no-cache, must-revalidate\";\n context.Response.Headers[\"Pragma\"] = \"no-cache\";\n context.Response.Headers[\"Expires\"] = \"0\";\n return Task.CompletedTask;\n });\n }\n\n await next();\n});\n```\n\nAlternatively, configure your CDN to bypass caching for URLs matching `/media/forms/upload/*`.\n\n Note: The vulnerability requires:\n - A CDN in front of the website\n - An authenticated user having previously requested the image\n - Knowledge of the form GUID, entry GUID, and image filename\n\n If no CDN is in use, this vulnerability does not apply.",
"id": "GHSA-7jxj-rpx7-ph2c",
"modified": "2026-01-22T18:06:01Z",
"published": "2026-01-22T18:06:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/umbraco/Umbraco.Forms.Issues/security/advisories/GHSA-7jxj-rpx7-ph2c"
},
{
"type": "PACKAGE",
"url": "https://github.com/umbraco/Umbraco.Forms.Issues"
}
],
"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"
}
],
"summary": "Umbraco.Forms CDN may cache sensitive form uploads when processed by ImageSharp"
}
GHSA-84WW-4WQP-3333
Vulnerability from github – Published: 2022-11-02 12:00 – Updated: 2022-11-02 19:00The issue was addressed with improved handling of caches. This issue is fixed in iOS 16. An app may be able to access user-sensitive data.
{
"affected": [],
"aliases": [
"CVE-2022-32909"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-01T20:15:00Z",
"severity": "MODERATE"
},
"details": "The issue was addressed with improved handling of caches. This issue is fixed in iOS 16. An app may be able to access user-sensitive data.",
"id": "GHSA-84ww-4wqp-3333",
"modified": "2022-11-02T19:00:24Z",
"published": "2022-11-02T12:00:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32909"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213446"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-88MR-69PQ-PX7W
Vulnerability from github – Published: 2026-07-23 12:32 – Updated: 2026-07-28 18:32Date-sensitive query cache keys did not retain a bounded time component. Cached results could remain active across future publication or expiry boundaries, potentially exposing content after it should become unavailable.
{
"affected": [],
"aliases": [
"CVE-2026-65755"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T10:16:53Z",
"severity": "HIGH"
},
"details": "Date-sensitive query cache keys did not retain a bounded time component. Cached results could remain active across future publication or expiry boundaries, potentially exposing content after it should become unavailable.",
"id": "GHSA-88mr-69pq-px7w",
"modified": "2026-07-28T18:32:43Z",
"published": "2026-07-23T12:32:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65755"
},
{
"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-8C42-7QJ2-3J46
Vulnerability from github – Published: 2026-08-17 18:24 – Updated: 2026-08-17 18:24Summary
Netty's CorsHandler silently overwrites existing Vary headers, enabling cache poisoning and sensitive information disclosure.
Details
io.netty.handler.codec.http.cors.CorsHandler#setVaryHeader overwrites any existing Vary headers set by backend applications.
private static void setVaryHeader(final HttpResponse response) {
response.headers().set(HttpHeaderNames.VARY, HttpHeaderNames.ORIGIN);
}
Because set() replaces all existing values for the header, if a backend application sets a Vary header (such as Vary: Authorization or Vary: Cookie) to ensure that intermediate caches (like CDNs) cache responses separately per user, the CorsHandler will overwrite it with Vary: origin. This causes the caching proxy to ignore the authorization context and cache the response based solely on the URL and Origin, allowing an attacker to retrieve another user's cached sensitive data.
Impact
This is a Cache Poisoning vulnerability that leads to Information Disclosure. It impacts any Netty-based web application that uses the CorsHandler, sets its own Vary headers to manage caching of authenticated or user-specific responses (e.g., Vary: Authorization), and is deployed behind a caching proxy or CDN. The end-users of these applications are impacted, as their sensitive data may be leaked to unauthorized actors.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.16.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.17.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.136.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.137.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59903"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-17T18:24:26Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nNetty\u0027s `CorsHandler` silently overwrites existing `Vary` headers, enabling cache poisoning and sensitive information disclosure.\n\n### Details\n`io.netty.handler.codec.http.cors.CorsHandler#setVaryHeader` overwrites any existing Vary headers set by backend applications. \n\n```java\n private static void setVaryHeader(final HttpResponse response) {\n response.headers().set(HttpHeaderNames.VARY, HttpHeaderNames.ORIGIN);\n }\n```\n\nBecause `set()` replaces all existing values for the header, if a backend application sets a `Vary` header (such as `Vary: Authorization` or `Vary: Cookie`) to ensure that intermediate caches (like CDNs) cache responses separately per user, the `CorsHandler` will overwrite it with `Vary: origin`. This causes the caching proxy to ignore the authorization context and cache the response based solely on the URL and Origin, allowing an attacker to retrieve another user\u0027s cached sensitive data.\n\n### Impact\nThis is a Cache Poisoning vulnerability that leads to Information Disclosure. It impacts any Netty-based web application that uses the CorsHandler, sets its own Vary headers to manage caching of authenticated or user-specific responses (e.g., Vary: Authorization), and is deployed behind a caching proxy or CDN. The end-users of these applications are impacted, as their sensitive data may be leaked to unauthorized actors.",
"id": "GHSA-8c42-7qj2-3j46",
"modified": "2026-08-17T18:24:26Z",
"published": "2026-08-17T18:24:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-8c42-7qj2-3j46"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/pull/17213"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/pull/17217"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.137.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.17.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty Vulnerable to Cache Poisoning and Information Disclosure via CORS Vary Header Overwrite"
}
GHSA-8QV4-773J-C979
Vulnerability from github – Published: 2024-10-17 15:31 – Updated: 2024-12-06 18:22Improper caching in JetBrains Ktor before 3.0.0 in the HttpCache Plugin could lead to response information disclosure.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.ktor:ktor-client-core-jvm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-49580"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-05T17:56:52Z",
"nvd_published_at": "2024-10-17T13:15:14Z",
"severity": "MODERATE"
},
"details": "Improper caching in JetBrains Ktor before 3.0.0 in the `HttpCache` Plugin could lead to response information disclosure.",
"id": "GHSA-8qv4-773j-c979",
"modified": "2024-12-06T18:22:23Z",
"published": "2024-10-17T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49580"
},
{
"type": "WEB",
"url": "https://github.com/ktorio/ktor/pull/4337"
},
{
"type": "WEB",
"url": "https://github.com/ktorio/ktor/pull/4368"
},
{
"type": "WEB",
"url": "https://github.com/ktorio/ktor/commit/0665736fc35c8ab5525241e975f36819b67f9d3e"
},
{
"type": "WEB",
"url": "https://github.com/ktorio/ktor/commit/d6c3a51df169c163e8f0b9ce77bbe543c70116ac"
},
{
"type": "PACKAGE",
"url": "https://github.com/ktorio/ktor"
},
{
"type": "WEB",
"url": "https://github.com/ktorio/ktor/releases/tag/2.3.13"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
},
{
"type": "WEB",
"url": "https://youtrack.jetbrains.com/issue/KTOR-7483"
}
],
"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"
}
],
"summary": "JetBrains Ktor information disclosure"
}
GHSA-8R69-3CVP-WXC3
Vulnerability from github – Published: 2022-11-02 18:18 – Updated: 2022-11-02 18:18Impact
In Apollo Server 3 and 4, the cache-control HTTP response header may not reflect the cache policy that should apply to an HTTP request when that HTTP request contains multiple operations using HTTP batching. This could lead to data being inappropriately cached and shared.
Apollo Server allows clients to send multiple operations in a single HTTP request. The results of these operations are returned in a single HTTP response, with a single set of headers. Apollo Client Web and Apollo Kotlin both have opt-in features to use batched requests.
Apollo Server has several features relating to caching. This advisory is about the ability to set the cache-control response header based on field- and operation-specific cache hints. (It is not about the "response cache plugin".) This header can be interpreted by a reverse proxy such as a CDN in front of your server, or by a browser.
In Apollo Server 2, plugins such as the cache control plugin could not control the HTTP headers of responses to batch requests. This meant that batch requests never got the cache-control response header.
In Apollo Server 3 and 4, plugins can set HTTP response headers. But for batched requests, plugins essentially assemble a separate set of response headers in parallel for each operation, and then the header sets are merged together. If plugins set the same header on multiple operations, one value is chosen arbitrarily.
This meant that if a client sent a batched HTTP request with two operations with different cache policies, Apollo Server 3 and 4 would return a cache-control header that only applies to one of the operations. If one operation is allowed to be cached and the other operation is not allowed to be cached, the full response including both results could still end up being cached in a CDN or other reverse proxy cache.
Note that valid batched requests must be POST requests. (There's no defined format for sending batched requests over GET.) So in order for this incorrect cache-control header to have a harmful effect, a cache must allow caching POST requests. This means this bug is unlikely to cause incorrect caching in browser or mobile client caches, or in many reverse proxy/CDN caches.
This issue could lead to cache poisoning attacks. For example, if a client app regularly sends an operation that should not be cached due to its dependency on session-specific information in the same HTTP request as an operation that can be cached in a shared cache, an attacker could send its own version of the request to the server and manage to get the response to its request stored in the shared cache; other users would then see the response specific to the attacker for the first operation rather than the response for their own session. That said, we expect that in a system where this cache poisoning attack is feasible, normal operation would also run into the issue and users may have already disabled one of the features in order for their system to function properly.
Patches
This issue is patched in Apollo Server v3.11.0 and v4.1.0. The issue resolved differently in the two versions.
If you are using Apollo Server 3, upgrade the package you depend on (eg apollo-server or apollo-server-express) to v3.11.0. This will restore the Apollo Server 2 behavior where the cache control plugin never sets the cache-control HTTP response header on batched requests. (Other cache-related features, like the response cache plugin, still function.)
If you are using Apollo Server 4, upgrade @apollo/server to v4.1.0. This upgrade makes the response HTTP header object seen by plugins shared among all plugins processing all operations on a request, and makes the cache control plugin merge cache-control header values across operations in a request. (Note that if you set the cache-control response header in your own plugin, Apollo Server v4.1.0's cache control plugin will not try to overwrite the value you set.)
Workarounds
As a workaround, you can disable either the HTTP batching feature or the cache-control header feature.
To disable HTTP batching in Apollo Server 3 (v3.5.0 or newer), pass allowBatchedHttpRequests: false to new ApolloServer.This is the default behavior for Apollo Server 4; in AS4, just make sure you're not passing allowBatchedHttpRequests: true. (You cannot disable batching in versions of Apollo Server 3 older than v3.5.0.)
To disable the cache-control header feature, add ApolloServerPluginCacheControl({ calculateHttpHeaders: false }) to the plugins list in new ApolloServer().
For more information
If you have any questions or comments about this advisory:
* Open an issue in the apollo-server repository
* Email us at security@apollographql.com
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "apollo-server-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.11.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@apollo/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-02T18:18:10Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\nIn Apollo Server 3 and 4, the `cache-control` HTTP response header may not reflect the cache policy that should apply to an HTTP request when that HTTP request contains multiple operations using HTTP batching. This could lead to data being inappropriately cached and shared.\n\nApollo Server allows clients to send multiple operations in a single HTTP request. The results of these operations are returned in a single HTTP response, with a single set of headers. Apollo Client Web and Apollo Kotlin both have opt-in features to use batched requests.\n\nApollo Server has several features relating to caching. This advisory is about the ability to set the `cache-control` response header based on field- and operation-specific cache hints. (It is not about the \"response cache plugin\".) This header can be interpreted by a reverse proxy such as a CDN in front of your server, or by a browser.\n\nIn Apollo Server 2, plugins such as the cache control plugin could not control the HTTP headers of responses to batch requests. This meant that batch requests never got the `cache-control` response header.\n\nIn Apollo Server 3 and 4, plugins can set HTTP response headers. But for batched requests, plugins essentially assemble a separate set of response headers in parallel for each operation, and then the header sets are merged together. If plugins set the same header on multiple operations, one value is chosen arbitrarily.\n\nThis meant that if a client sent a batched HTTP request with two operations with different cache policies, Apollo Server 3 and 4 would return a `cache-control` header that only applies to one of the operations. If one operation is allowed to be cached and the other operation is not allowed to be cached, the full response including both results could still end up being cached in a CDN or other reverse proxy cache.\n\nNote that valid batched requests must be POST requests. (There\u0027s no defined format for sending batched requests over GET.) So in order for this incorrect `cache-control` header to have a harmful effect, a cache must allow caching POST requests. This means this bug is unlikely to cause incorrect caching in browser or mobile client caches, or in many reverse proxy/CDN caches.\n\nThis issue could lead to cache poisoning attacks. For example, if a client app regularly sends an operation that should not be cached due to its dependency on session-specific information in the same HTTP request as an operation that can be cached in a shared cache, an attacker could send its own version of the request to the server and manage to get the response to its request stored in the shared cache; other users would then see the response specific to the attacker for the first operation rather than the response for their own session. That said, we expect that in a system where this cache poisoning attack is feasible, normal operation would also run into the issue and users may have already disabled one of the features in order for their system to function properly.\n\n### Patches\n\nThis issue is patched in Apollo Server v3.11.0 and v4.1.0. The issue resolved differently in the two versions.\n\nIf you are using Apollo Server 3, upgrade the package you depend on (eg `apollo-server` or `apollo-server-express`) to v3.11.0. This will restore the Apollo Server 2 behavior where the cache control plugin *never* sets the `cache-control` HTTP response header on batched requests. (Other cache-related features, like the response cache plugin, still function.)\n\nIf you are using Apollo Server 4, upgrade `@apollo/server` to v4.1.0. This upgrade makes the response HTTP header object seen by plugins shared among all plugins processing *all operations* on a request, and makes the cache control plugin merge `cache-control` header values across operations in a request. (Note that if you set the `cache-control` response header in your own plugin, Apollo Server v4.1.0\u0027s cache control plugin will not try to overwrite the value you set.)\n\n\n### Workarounds\nAs a workaround, you can disable either the HTTP batching feature or the `cache-control` header feature.\n\nTo disable HTTP batching in Apollo Server 3 (v3.5.0 or newer), pass `allowBatchedHttpRequests: false` to `new ApolloServer`.This is the default behavior for Apollo Server 4; in AS4, just make sure you\u0027re not passing `allowBatchedHttpRequests: true`. (You cannot disable batching in versions of Apollo Server 3 older than v3.5.0.)\n\nTo disable the `cache-control` header feature, add `ApolloServerPluginCacheControl({ calculateHttpHeaders: false })` to the `plugins` list in `new ApolloServer()`.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the `apollo-server` repository](https://github.com/apollographql/apollo-server)\n* Email us at [security@apollographql.com](mailto:security@apollographql.com)\n",
"id": "GHSA-8r69-3cvp-wxc3",
"modified": "2022-11-02T18:18:50Z",
"published": "2022-11-02T18:18:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apollographql/apollo-server/security/advisories/GHSA-8r69-3cvp-wxc3"
},
{
"type": "WEB",
"url": "https://github.com/apollographql/apollo-server/commit/2a2d1e3b4bbb1f2802b09004444029bd1adb9c19"
},
{
"type": "WEB",
"url": "https://github.com/apollographql/apollo-server/commit/69be2f75d05c7044086a869d915b965ada033850"
},
{
"type": "PACKAGE",
"url": "https://github.com/apollographql/apollo-server"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Batched HTTP requests may set incorrect `cache-control` response 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.