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.
118 vulnerabilities reference this CWE, most recent first.
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"
}
GHSA-95QP-CMMW-MGQV
Vulnerability from github – Published: 2026-06-15 17:13 – Updated: 2026-07-15 22:05An issue in the @angular/service-worker package compromises the integrity of request-policy enforcement during request reconstruction. When the Angular Service Worker intercepts network requests for matched assets, it reconstructs a new Request object using an internal helper function.
During this reconstruction process, the helper function strips explicit client-defined safety parameters: the credentials configuration (such as credentials: 'omit') and the HTTP cache mode configuration (such as cache: 'no-store'). These are reverted back to standard browser-default parameters (credentials: 'same-origin' and default HTTP cache properties).
This causes the browser to include active credentials (such as cookies or Authorization headers) on outbound requests where the client-side developer explicitly instructed they should be omitted, leading to potential session leaks. Additionally, it causes private or non-cacheable resources to be cached by the service worker's engine, making private page states accessible or persistent inside the client's local cache post-logout.
Impact
Web applications registering the @angular/service-worker package are vulnerable to credential exposure or post-logout cache persistence if client-side code relies on fetch calls with explicit safety attributes (such as { credentials: 'omit' } or { cache: 'no-store' }) targeting paths matched by service worker asset groups.
By stripping these safety boundaries, the service worker exposes same-origin cookies and dynamic sensitive data to endpoints that should not receive them, or retains dynamic user sessions in cache storage where logout operations fail to fully evict user records.
Attack Preconditions
To successfully exploit this vulnerability, all of the following application states and parameters must concurrently exist:
1. Active Angular Service Worker: The target application uses @angular/service-worker and has an active registration of ngsw-worker.js inside the client's browser context.
2. Asset Group Matching: An assetGroups pattern in ngsw-config.json encompasses the target dynamic routing endpoint.
3. Established User Session: The victim user currently has an active authentication state, such as valid same-origin session cookies or auth headers stored by the browser.
4. Client-Side Safe Fetch Call: The application initiates an explicit fetch request to the route with safety parameters: { credentials: 'omit' } or specific cache control parameters (e.g. { cache: 'no-store' }).
Mitigations & Workarounds
If upgrading the @angular/service-worker package is not immediately feasible, developers should implement the following defensive measures:
* Strict Cookie Configuration: Apply strict flags to session cookies (SameSite=Strict; Secure; HttpOnly) and ensure complete route isolation for credential-guarded secure resources.
* Exclude Secure Endpoints from SW Config: Ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes in your ngsw-config.json.
* Post-Logout Cache Invalidation: Programmatically purge the browser's Cache Storage API entries registered by the Angular Service Worker upon user logout:
javascript
if ('caches' in window) {
caches.keys().then(names => {
for (let name of names) {
if (name.startsWith('ngsw:')) {
caches.delete(name);
}
}
});
}
Patches
- 22.0.0-rc.2
- 21.2.15
- 20.3.22
- 19.2.23
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@angular/service-worker"
},
"ranges": [
{
"events": [
{
"introduced": "22.0.0-next.0"
},
{
"fixed": "22.0.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/service-worker"
},
"ranges": [
{
"events": [
{
"introduced": "21.0.0-next.0"
},
{
"fixed": "21.2.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/service-worker"
},
"ranges": [
{
"events": [
{
"introduced": "20.0.0-next.0"
},
{
"fixed": "20.3.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/service-worker"
},
"ranges": [
{
"events": [
{
"introduced": "19.0.0-next.0"
},
{
"fixed": "19.2.23"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/service-worker"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "18.2.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50184"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T17:13:05Z",
"nvd_published_at": "2026-06-22T18:16:42Z",
"severity": "MODERATE"
},
"details": "An issue in the `@angular/service-worker` package compromises the integrity of request-policy enforcement during request reconstruction. When the Angular Service Worker intercepts network requests for matched assets, it reconstructs a new `Request` object using an internal helper function.\n\nDuring this reconstruction process, the helper function strips explicit client-defined safety parameters: the credentials configuration (such as `credentials: \u0027omit\u0027`) and the HTTP `cache` mode configuration (such as `cache: \u0027no-store\u0027`). These are reverted back to standard browser-default parameters (`credentials: \u0027same-origin\u0027` and default HTTP cache properties).\n\nThis causes the browser to include active credentials (such as cookies or Authorization headers) on outbound requests where the client-side developer explicitly instructed they should be omitted, leading to potential session leaks. Additionally, it causes private or non-cacheable resources to be cached by the service worker\u0027s engine, making private page states accessible or persistent inside the client\u0027s local cache post-logout.\n\n### Impact\nWeb applications registering the `@angular/service-worker` package are vulnerable to credential exposure or post-logout cache persistence if client-side code relies on fetch calls with explicit safety attributes (such as `{ credentials: \u0027omit\u0027 }` or `{ cache: \u0027no-store\u0027 }`) targeting paths matched by service worker asset groups. \n\nBy stripping these safety boundaries, the service worker exposes same-origin cookies and dynamic sensitive data to endpoints that should not receive them, or retains dynamic user sessions in cache storage where logout operations fail to fully evict user records.\n\n### Attack Preconditions\nTo successfully exploit this vulnerability, all of the following application states and parameters must concurrently exist:\n1. **Active Angular Service Worker:** The target application uses `@angular/service-worker` and has an active registration of `ngsw-worker.js` inside the client\u0027s browser context.\n2. **Asset Group Matching:** An `assetGroups` pattern in `ngsw-config.json` encompasses the target dynamic routing endpoint.\n3. **Established User Session:** The victim user currently has an active authentication state, such as valid same-origin session cookies or auth headers stored by the browser.\n4. **Client-Side Safe Fetch Call:** The application initiates an explicit fetch request to the route with safety parameters: `{ credentials: \u0027omit\u0027 }` or specific cache control parameters (e.g. `{ cache: \u0027no-store\u0027 }`).\n\n### Mitigations \u0026 Workarounds\nIf upgrading the `@angular/service-worker` package is not immediately feasible, developers should implement the following defensive measures:\n* **Strict Cookie Configuration:** Apply strict flags to session cookies (`SameSite=Strict; Secure; HttpOnly`) and ensure complete route isolation for credential-guarded secure resources.\n* **Exclude Secure Endpoints from SW Config:** Ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes in your `ngsw-config.json`.\n* **Post-Logout Cache Invalidation:** Programmatically purge the browser\u0027s Cache Storage API entries registered by the Angular Service Worker upon user logout:\n ```javascript\n if (\u0027caches\u0027 in window) {\n caches.keys().then(names =\u003e {\n for (let name of names) {\n if (name.startsWith(\u0027ngsw:\u0027)) {\n caches.delete(name);\n }\n }\n });\n }\n ```\n### Patches\n- 22.0.0-rc.2\n- 21.2.15\n- 20.3.22\n- 19.2.23",
"id": "GHSA-95qp-cmmw-mgqv",
"modified": "2026-07-15T22:05:21Z",
"published": "2026-06-15T17:13:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/angular/angular/security/advisories/GHSA-95qp-cmmw-mgqv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50184"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/pull/68904"
},
{
"type": "PACKAGE",
"url": "https://github.com/angular/angular"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "@angular/service-worker: Request Credential \u0026 Cache Policy Stripping"
}
GHSA-C2F9-4JMM-V45M
Vulnerability from github – Published: 2024-03-06 15:06 – Updated: 2026-02-17 22:02Impact
The Symfony Session Handler, pop's the Session Cookie and assign it to the Response. Since Shopware 6.5.8.0 the 404 pages, are cached, to improve the performance of 404 pages. So the cached Response, contains a Session Cookie when the Browser accessing the 404 page, has no cookies yet. The Symfony Session Handler is in use, when no explicit Session configuration has been done. When Redis is in use for Sessions using the PHP Redis extension, this exploiting code is not used.
Patches
Update to Shopware version 6.5.8.7
Workarounds
Using Redis for Sessions, as this does not trigger the exploit code. Example configuration for Redis
# php.ini
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"
Consequences
As an guest browser session has been cached on a 404 page, every missing image or directly reaching a 404 page will logout the customer or clear his cart.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/storefront"
},
"ranges": [
{
"events": [
{
"introduced": "6.5.8.0"
},
{
"fixed": "6.5.8.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "6.5.8.0"
},
{
"fixed": "6.5.8.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-27917"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-06T15:06:54Z",
"nvd_published_at": "2024-03-06T20:15:48Z",
"severity": "HIGH"
},
"details": "### Impact\n\nThe Symfony Session Handler, pop\u0027s the Session Cookie and assign it to the Response. Since Shopware 6.5.8.0 the 404 pages, are cached, to improve the performance of 404 pages. So the cached Response, contains a Session Cookie when the Browser accessing the 404 page, has no cookies yet. The Symfony Session Handler is in use, when no explicit Session configuration has been done.\nWhen Redis is in use for Sessions using the PHP Redis extension, this exploiting code is not used.\n\n### Patches\nUpdate to Shopware version 6.5.8.7\n\n### Workarounds\nUsing Redis for Sessions, as this does not trigger the exploit code. Example configuration for Redis\n\n```ini\n# php.ini\nsession.save_handler = redis\nsession.save_path = \"tcp://127.0.0.1:6379\"\n```\n\n## Consequences\n\nAs an guest browser session has been cached on a 404 page, every missing image or directly reaching a 404 page will logout the customer or clear his cart.",
"id": "GHSA-c2f9-4jmm-v45m",
"modified": "2026-02-17T22:02:24Z",
"published": "2024-03-06T15:06:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/security/advisories/GHSA-c2f9-4jmm-v45m"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/commit/7d9cb03225efca5f97e69b800d8747598dd15ce3"
},
{
"type": "WEB",
"url": "https://github.com/shopware/storefront/commit/3477e4a425d3c54b4bfae82d703fe3838dc21d3e"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopware/shopware"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/releases/tag/v6.5.8.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Shopware\u0027s session is persistent in Cache for 404 pages"
}
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.