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-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-06-15 17:13An 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": null,
"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-06-15T17:13:06Z",
"published": "2026-06-15T17:13:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/angular/angular/security/advisories/GHSA-95qp-cmmw-mgqv"
},
{
"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: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"
}
GHSA-CFF8-X7JV-4FM8
Vulnerability from github – Published: 2024-09-10 19:43 – Updated: 2025-11-17 21:35Summary
Unauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include redirect query string.
For example:
- Project is configured with OpenID or OAuth2
- Project is configured with cache enabled
- User tries to login via SSO link, but without redirect query string
- After successful login, credentials are cached
- If an unauthenticated user tries to login via SSO link, it will return the credentials of the other last user
The SSO link is something like https://directus.example.com/auth/login/openid/callback, where openid is the name of the OpenID provider configured in Directus
Details
This happens because on that endpoint for both OpenId and Oauth2 Directus is using the respond middleware, which by default will try to cache GET requests that met some conditions. Although, those conditions do not include this scenario, when an unauthenticated request returns user credentials.
For OpenID, this can be seen here:
https://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459
And for OAuth2 can be seen here
https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428
PoC
- Create a new Directus project
- Set
CACHE_ENABLEDto true - Set
CACHE_STOREtoredisfor reliable results (if using memory with multiple nodes, it may only happen sometimes, due to cache being different for different nodes) - Configure
REDISwith redis string or redis host, port, user, etc. - Set
AUTH_PROVIDERStoopenid - Set
PUBLIC_URLto the the main URL of your project . For example,PUBLIC_URL: http://localhost:8055 - Configure
AUTH_OPENID_CLIENT_ID,AUTH_OPENID_CLIENT_SECRET,AUTH_OPENID_ISSUER_URLwith proper OpenID configurations - Be sure that on OpenID external app you have configured Redirect URI to
http://localhost:8055/auth/login/openid/callback - Run Directus
- Open the SSO link like
http://localhost:8055/auth/login/openid/callback - Do the authentication on the OpenID external webpage
- Verify that it you got redirected to a page with a JSON including
access_tokenproperty - Be sure all anonymous mode windows are closed
- Open an anonymous window and go to the SSO Link
http://localhost:8055/auth/login/openid/callbackand see you have the same credentials, even though you don't have any session because you are in anonymous mode
Impact
All projects using OpenID or OAuth 2, that does not include redirect query string on loggin in users.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.13.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-rc.1"
},
{
"fixed": "11.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@directus/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "21.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@directus/api"
},
"ranges": [
{
"events": [
{
"introduced": "22.0.0"
},
{
"fixed": "22.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-45596"
],
"database_specific": {
"cwe_ids": [
"CWE-384",
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-10T19:43:00Z",
"nvd_published_at": "2024-09-10T19:15:22Z",
"severity": "HIGH"
},
"details": "### Summary\nUnauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include `redirect` query string.\n\nFor example:\n- Project is configured with OpenID or OAuth2\n- Project is configured with cache enabled\n- User tries to login via SSO link, but without `redirect` query string\n- After successful login, credentials are cached\n- If an unauthenticated user tries to login via SSO link, it will return the credentials of the other last user\n\nThe SSO link is something like `https://directus.example.com/auth/login/openid/callback`, where `openid` is the name of the OpenID provider configured in Directus\n\n### Details\nThis happens because on that endpoint for both OpenId and Oauth2 Directus is using the `respond` middleware, which by default will try to cache GET requests that met some conditions. Although, those conditions do not include this scenario, when an unauthenticated request returns user credentials.\nFor OpenID, this can be seen here:\nhttps://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459\nAnd for OAuth2 can be seen here\nhttps://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428\n\n### PoC\n- Create a new Directus project\n- Set `CACHE_ENABLED` to true\n- Set `CACHE_STORE` to `redis` for reliable results (if using memory with multiple nodes, it may only happen sometimes, due to cache being different for different nodes)\n- Configure `REDIS` with redis string or redis host, port, user, etc.\n- Set `AUTH_PROVIDERS` to `openid`\n- Set `PUBLIC_URL` to the the main URL of your project . \tFor example, `PUBLIC_URL: http://localhost:8055`\n- Configure `AUTH_OPENID_CLIENT_ID`, `AUTH_OPENID_CLIENT_SECRET`, `AUTH_OPENID_ISSUER_URL` with proper OpenID configurations\n- Be sure that on OpenID external app you have configured Redirect URI to `http://localhost:8055/auth/login/openid/callback`\n- Run Directus\n- Open the SSO link like `http://localhost:8055/auth/login/openid/callback`\n- Do the authentication on the OpenID external webpage\n- Verify that it you got redirected to a page with a JSON including `access_token` property\n- Be sure all anonymous mode windows are closed\n- Open an anonymous window and go to the SSO Link `http://localhost:8055/auth/login/openid/callback` and see you have the same credentials, even though you don\u0027t have any session because you are in anonymous mode\n\n### Impact\nAll projects using OpenID or OAuth 2, that does not include `redirect` query string on loggin in users.",
"id": "GHSA-cff8-x7jv-4fm8",
"modified": "2025-11-17T21:35:30Z",
"published": "2024-09-10T19:43:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/directus/directus/security/advisories/GHSA-cff8-x7jv-4fm8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45596"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/commit/4aace0bbe57232e38cd6a287ee475293e46dc91b"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/commit/769fa22797bff5a9231599883b391e013f122e52"
},
{
"type": "PACKAGE",
"url": "https://github.com/directus/directus"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Session is cached for OpenID and OAuth2 if `redirect` is not used"
}
GHSA-F957-W8WH-R29F
Vulnerability from github – Published: 2024-08-13 09:30 – Updated: 2024-08-13 09:30A vulnerability has been identified in SINEC Traffic Analyzer (6GK8822-1BG01-0BA0) (All versions < V2.0). The affected application does not properly handle cacheable HTTP responses in the web service. This could allow an attacker to read and modify data stored in the local cache.
{
"affected": [],
"aliases": [
"CVE-2024-41906"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T08:15:13Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been identified in SINEC Traffic Analyzer (6GK8822-1BG01-0BA0) (All versions \u003c V2.0). The affected application does not properly handle cacheable HTTP responses in the web service. This could allow an attacker to read and modify data stored in the local cache.",
"id": "GHSA-f957-w8wh-r29f",
"modified": "2024-08-13T09:30:52Z",
"published": "2024-08-13T09:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41906"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-716317.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:L/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-FMVV-F47M-6C7P
Vulnerability from github – Published: 2026-06-25 15:32 – Updated: 2026-06-25 15:32ECS zero scoped answers are stored in the packet cache while they should not. This impacts only configurations that have ECS enabled;
{
"affected": [],
"aliases": [
"CVE-2026-40012"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T14:16:38Z",
"severity": "MODERATE"
},
"details": "ECS zero scoped answers are stored in the packet cache while they should not. This impacts only configurations that have ECS enabled;",
"id": "GHSA-fmvv-f47m-6c7p",
"modified": "2026-06-25T15:32:00Z",
"published": "2026-06-25T15:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40012"
},
{
"type": "WEB",
"url": "https://docs.powerdns.com/recursor/security-advisories/powerdns-advisory-powerdns-2026-08.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FWJ3-7PPR-QCV6
Vulnerability from github – Published: 2026-03-18 00:30 – Updated: 2026-03-18 00:30IBM Planning Analytics Local 2.1.0 through 2.1.17 could allow an attacker to trick the caching mechanism into storing and serving sensitive, user-specific responses as publicly cacheable resources.
{
"affected": [],
"aliases": [
"CVE-2025-14806"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-17T22:16:13Z",
"severity": "MODERATE"
},
"details": "IBM Planning Analytics Local 2.1.0 through 2.1.17 could allow an attacker to trick the caching mechanism into storing and serving sensitive, user-specific responses as publicly cacheable resources.",
"id": "GHSA-fwj3-7ppr-qcv6",
"modified": "2026-03-18T00:30:54Z",
"published": "2026-03-18T00:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14806"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7263581"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G5QG-72QW-GW5V
Vulnerability from github – Published: 2025-08-29 22:06 – Updated: 2025-09-03 13:00A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. When images returned from API routes vary based on request headers (such as Cookie or Authorization), these responses could be incorrectly cached and served to unauthorized users due to a cache key confusion bug.
All users are encouraged to upgrade if they use API routes to serve images that depend on request headers and have image optimization enabled.
More details at Vercel Changelog
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.9"
},
{
"fixed": "14.2.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 15.4.4"
},
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.0.0"
},
{
"fixed": "15.4.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-57752"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-29T22:06:22Z",
"nvd_published_at": "2025-08-29T22:15:31Z",
"severity": "MODERATE"
},
"details": "A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. When images returned from API routes vary based on request headers (such as `Cookie` or `Authorization`), these responses could be incorrectly cached and served to unauthorized users due to a cache key confusion bug.\n\nAll users are encouraged to upgrade if they use API routes to serve images that depend on request headers and have image optimization enabled.\n\nMore details at [Vercel Changelog](https://vercel.com/changelog/cve-2025-57752)",
"id": "GHSA-g5qg-72qw-gw5v",
"modified": "2025-09-03T13:00:52Z",
"published": "2025-08-29T22:06:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/security/advisories/GHSA-g5qg-72qw-gw5v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57752"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/pull/82114"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/commit/6b12c60c61ee80cb0443ccd20de82ca9b4422ddd"
},
{
"type": "PACKAGE",
"url": "https://github.com/vercel/next.js"
},
{
"type": "WEB",
"url": "https://vercel.com/changelog/cve-2025-57752"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Next.js Affected by Cache Key Confusion for Image Optimization API Routes"
}
GHSA-GV2Q-MQQV-365M
Vulnerability from github – Published: 2026-06-15 16:44 – Updated: 2026-06-15 16:44An 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 the strict, client-defined request redirect policy configuration (such as redirect: 'error'), falling back to the browser's default 'follow' strategy.
If the target web application makes client-side requests with a strict policy (e.g., expecting a network error instead of automatically following redirects), the service worker will bypass this instruction and automatically follow HTTP 3xx redirects to other destinations. This acts as an unintended proxy/intermediary ("Confused Deputy") and can result in cookie/credential exposure or same-origin session-restricted data leakage if public dynamic routes redirect to sensitive routes.
Impact
Web applications registering the @angular/service-worker package are vulnerable to this redirect-policy bypass if they make safe client-side fetch calls (such as { redirect: 'error' }) to paths matched by a service worker asset group (such as lazy-loaded JavaScript bundles or dynamic public assets) that can return HTTP redirects to authenticated same-origin secure endpoints.
By stripping developer-defined safety boundaries, the service worker allows the browser to transparently query and return data from credentials-guarded resources that should have been blocked at the network barrier.
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. Same-Origin Dynamic Redirection: The server routes a public matched asset route to a service that returns an HTTP 3xx redirect pointing to a sensitive, session-restricted same-origin private route (e.g., /private/account-summary.json).
4. 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.
5. Client-Side Safe Fetch Call: The application initiates an explicit fetch request to the route with safety parameters: { redirect: 'error' }.
Mitigations & Workarounds
If upgrading the @angular/service-worker package is not immediately feasible, developers should implement the following defensive measures:
* Avoid Public-to-Private Dynamic Redirection: Refactor the server architecture so that public paths matched by service worker asset groups never issue HTTP 3xx redirects to authenticated same-origin secure endpoints.
* Strict Cookie Configuration: Apply strict flags to session cookies (SameSite=Strict; Secure; HttpOnly) and consider explicit route isolations (such as subdomains) for credential-guarded private resources.
* Exclude Secure Endpoints from SW Config: Verify your ngsw-config.json settings and ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes.
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": "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"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/service-worker"
},
"ranges": [
{
"events": [
{
"introduced": "21.0.0-next.0"
},
{
"fixed": "21.2.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50169"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-441",
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T16:44:21Z",
"nvd_published_at": null,
"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 the strict, client-defined request redirect policy configuration (such as `redirect: \u0027error\u0027`), falling back to the browser\u0027s default `\u0027follow\u0027` strategy.\n\nIf the target web application makes client-side requests with a strict policy (e.g., expecting a network error instead of automatically following redirects), the service worker will bypass this instruction and automatically follow HTTP 3xx redirects to other destinations. This acts as an unintended proxy/intermediary (\"Confused Deputy\") and can result in cookie/credential exposure or same-origin session-restricted data leakage if public dynamic routes redirect to sensitive routes.\n\n### Impact\nWeb applications registering the `@angular/service-worker` package are vulnerable to this redirect-policy bypass if they make safe client-side fetch calls (such as `{ redirect: \u0027error\u0027 }`) to paths matched by a service worker asset group (such as lazy-loaded JavaScript bundles or dynamic public assets) that can return HTTP redirects to authenticated same-origin secure endpoints. \n\nBy stripping developer-defined safety boundaries, the service worker allows the browser to transparently query and return data from credentials-guarded resources that should have been blocked at the network barrier.\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. **Same-Origin Dynamic Redirection:** The server routes a public matched asset route to a service that returns an HTTP 3xx redirect pointing to a sensitive, session-restricted same-origin private route (e.g., `/private/account-summary.json`).\n4. **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.\n5. **Client-Side Safe Fetch Call:** The application initiates an explicit fetch request to the route with safety parameters: `{ redirect: \u0027error\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* **Avoid Public-to-Private Dynamic Redirection:** Refactor the server architecture so that public paths matched by service worker asset groups never issue HTTP 3xx redirects to authenticated same-origin secure endpoints.\n* **Strict Cookie Configuration:** Apply strict flags to session cookies (`SameSite=Strict; Secure; HttpOnly`) and consider explicit route isolations (such as subdomains) for credential-guarded private resources.\n* **Exclude Secure Endpoints from SW Config:** Verify your `ngsw-config.json` settings and ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes.\n\n### Patches\n- 22.0.0-rc.2\n- 21.2.15\n- 20.3.22\n- 19.2.23",
"id": "GHSA-gv2q-mqqv-365m",
"modified": "2026-06-15T16:44:21Z",
"published": "2026-06-15T16:44:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/angular/angular/security/advisories/GHSA-gv2q-mqqv-365m"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/pull/67494"
},
{
"type": "PACKAGE",
"url": "https://github.com/angular/angular"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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 Policy-Bypass \u0026 Credential-Stripping Vulnerabilities"
}
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.