CWE-524

{
  "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"
}

{
  "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"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-105752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-06T00:02:02Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Affected\n\n- **Ecosystem / package:** pip / `vllm`\n- **Affected versions:** vLLM \u2264 0.25.1 (confirmed on 0.25.1, commit [`752a3a504485`](https://github.com/vllm-project/vllm/tree/752a3a504485790a2e8491cacbb35c137339ad34)). The lower bound predates 0.25.1; maintainers can confirm how far back the tool-continuation re-submission has omitted the salt.\n\n## Summary\n\nOn the GPT-OSS \"Harmony\" path (`POST /v1/responses`), a request that uses a built-in or MCP tool runs as a multi-turn loop: after each tool call vLLM re-renders the full next-turn Harmony prompt and re-submits it to the engine. Turn 1 correctly carries `request.cache_salt`, but the tool-continuation re-submission rebuilds the engine input via `tokens_input(token_ids)` with **no** `cache_salt`. The continuation prefix is therefore cached in the global *unsalted* namespace even though the caller opted into salting. A second tenant who can guess the low-entropy post-tool history submits the reconstructed continuation (unsalted) and reads exact per-turn cached-token counts from the Responses usage \u2014 restoring the prompt-membership oracle that `cache_salt` is documented to prevent.\n\nSilently dropping a preserved salt *after* the supported tool workflow is enabled is a broken isolation control: the caller enabled salting and every turn should stay isolated, but continuation turns leak into the shared cache.\n\nThis is distinct from [GHSA-4qjh-9fv9-r85r](https://github.com/vllm-project/vllm/security/advisories/GHSA-4qjh-9fv9-r85r) ([CVE-2025-46570](https://nvd.nist.gov/vuln/detail/CVE-2025-46570)): that advisory is the prefix-cache membership oracle for which `cache_salt` is the documented mitigation, and its PR-17045 fix does not close this site \u2014 the Harmony tool continuation silently drops the preserved salt, caching in the unsalted namespace and leaking exact `cached_tokens_per_turn` counts from a different sink (the Responses serving continuation, not general TTFT timing).\n\n## Affected code\n\nLinks pinned to the confirmed commit [`752a3a504485`](https://github.com/vllm-project/vllm/tree/752a3a504485790a2e8491cacbb35c137339ad34) (v0.25.1):\n\n- **The drop (sink):** [`vllm/entrypoints/openai/responses/serving.py#L712-L713`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/openai/responses/serving.py#L712-L713) \u2014 `token_ids = context.render_for_completion()` then `engine_input = tokens_input(token_ids)`, with no `cache_salt`.\n- **Correct turn-1 call for contrast:** [`vllm/entrypoints/openai/responses/serving.py#L755`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/openai/responses/serving.py#L755) \u2014 `tokens_input(prompt_token_ids, cache_salt=request.cache_salt)`.\n- **`tokens_input` stores the salt only if passed:** [`vllm/inputs/engine.py#L51-L66`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/inputs/engine.py#L51-L66) (`if cache_salt is not None: inputs[\"cache_salt\"] = cache_salt`).\n- **The engine request copies only the current input\u0027s salt:** [`vllm/v1/engine/input_processor.py#L380`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/engine/input_processor.py#L380) (`cache_salt=decoder_inputs.get(\"cache_salt\")` \u2192 `None` for the continuation).\n- **Prefix-cache hashing keys on the salt only when present:** [`vllm/v1/core/kv_cache_utils.py#L560-L561`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/core/kv_cache_utils.py#L560-L561) (`[request.cache_salt] if (start_token_idx == 0 and request.cache_salt) else []`).\n- **The oracle the attacker reads:** [`vllm/entrypoints/openai/responses/serving.py#L909`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/openai/responses/serving.py#L909) (`cached_tokens_per_turn`).\n- **The documented control being defeated:** [`vllm/entrypoints/openai/responses/protocol.py#L235`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/openai/responses/protocol.py#L235) (`cache_salt` field).\n\nThe tool-continuation re-submission rebuilds the engine input with no `cache_salt`:\n\n```python\n# vllm/entrypoints/openai/responses/serving.py Lines 711-715\n            if isinstance(context, HarmonyContext):\n                token_ids = context.render_for_completion()\n                engine_input = tokens_input(token_ids)\n\n                sampling_params.max_tokens = max_model_len - len(token_ids)\n```\n\nContrast with the correct turn-1 call, which does preserve the caller\u0027s salt:\n\n```python\n# vllm/entrypoints/openai/responses/serving.py Lines 754-755\n        prompt_token_ids = render_for_completion(messages)\n        engine_input = tokens_input(prompt_token_ids, cache_salt=request.cache_salt)\n```\n\n`tokens_input` stores the salt on the engine input only when it is passed, so the continuation input carries none and lands in the unsalted namespace:\n\n```python\n# vllm/inputs/engine.py Lines 51-66\ndef tokens_input(\n    prompt_token_ids: list[int],\n    *,\n    prompt: str | None = None,\n    cache_salt: str | None = None,\n) -\u003e TokensInput:\n    \"\"\"\n    Construct [`TokensInput`][vllm.inputs.engine.TokensInput]\n    from optional values.\n    \"\"\"\n    inputs = TokensInput(type=\"token\", prompt_token_ids=prompt_token_ids)\n\n    if prompt is not None:\n        inputs[\"prompt\"] = prompt\n    if cache_salt is not None:\n        inputs[\"cache_salt\"] = cache_salt\n```\n\n## Impact\n\nAn authenticated tenant of a shared deployment can recover whether a guessed post-tool prompt or history was processed by another tenant, with exact cached-token counts rather than noisy latency \u2014 the exact prompt-membership oracle `cache_salt` is documented to prevent. It defeats the multi-user prefix-cache isolation guarantee for salted Harmony tool sessions.\n\nPreconditions: a GPT-OSS Harmony model on `/v1/responses`; prefix caching enabled (default); an operator-enabled built-in or MCP tool server; the victim sets `cache_salt` and triggers at least one tool continuation; and the attacker can reconstruct the post-tool history closely enough to match the token prefix. The `AC:H` metric reflects that guessable-history precondition.\n\n\n## Suggested Fix\n\nPropagate `request.cache_salt` into every Harmony (and Parsable) tool-continuation re-submission \u2014 at the continuation call site call `tokens_input(token_ids, cache_salt=request.cache_salt)`, mirroring the correct turn-1 call. Carry the salt on the `HarmonyContext` (thread the originating `request` into the context) so no continuation path can omit it:\n\n```diff\n# vllm/entrypoints/openai/responses/serving.py\n             if isinstance(context, HarmonyContext):\n                 token_ids = context.render_for_completion()\n-                engine_input = tokens_input(token_ids)\n+                engine_input = tokens_input(\n+                    token_ids,\n+                    cache_salt=(\n+                        context.request.cache_salt\n+                        if context.request is not None\n+                        else None\n+                    ),\n+                )\n```\n\nwith `HarmonyContext.__init__` gaining a `request: ResponsesRequest | None = None` parameter (stored as `self.request`) that `_create_responses` passes when constructing the context. The continuation prefix is then cached in the victim\u0027s salted namespace, mirroring turn 1.\n\nSuggested regression test: assert `cached_tokens_per_turn == 0` for a different-salt probe against a salted victim continuation (the four-way control from the proof of concept).\n\n## Credit\n\n**Reported by:** Patch the Planet (Trail of Bits + OpenAI collaboration)\n\nThis vulnerability was discovered using GPT-5.5-Cyber as part of the Patch the Planet security initiative.\n\n---\n\n**Proposed fix:** a fix for this issue is proposed in a public pull request: https://github.com/vllm-project/vllm/pull/51818",
  "id": "GHSA-935w-9g4m-p28p",
  "modified": "2026-10-06T00:02:03Z",
  "published": "2026-10-06T00:02:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-935w-9g4m-p28p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/50195"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/51818"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/6a2a2bb02b563b83f946012959fd3927984d072a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/releases/tag/v0.30.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vLLM: Harmony tool continuations drop `cache_salt` \u2014 restoring a cross-tenant prefix-cache membership oracle"
}

{
  "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"
}

{
  "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"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "12.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61836"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T21:48:15Z",
    "nvd_published_at": "2026-07-15T15:16:48Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nWhen response caching is enabled (`CACHE_ENABLED=true`), the cache-key derivation in `api/src/utils/get-cache-key.ts` includes only `version`, `path`, `query`, and `accountability.user` (plus a conditional `ip`). Authorization context beyond `user` (`share`, `role`, `roles`, `admin`, `app`, `policies`) is not part of the key.\n\nFor share tokens this is load-bearing. Directus\u0027s share-authentication flow (`api/src/services/shares.ts:100-105`) issues a JWT without an `id` claim, so `api/src/utils/get-accountability-for-token.ts` never assigns `accountability.user`, leaving it `null` (the default from `create-default-accountability.ts`). Every share token, and every anonymous request, therefore reduces to `user: null` in the cache-key input. Two different shares (or an anonymous request and a share token) requesting the same URL with the same query produce identical cache keys. The first request populates the bucket with a permission-filtered response; subsequent hits from unrelated shares or anonymous clients receive that payload without any permission re-evaluation.\n\nThis is the web-cache pattern \"authorization-dependent response cached under an unsegmented key\" (cache key collision / missing authorization context in cache key, CWE-524 and CWE-639). Two adjacent read populations collide:\n\n- **Share to share:** `Share A` populates the cache, `Share B` reads `Share A`\u0027s scoped response.\n- **Share to anonymous** (and the reverse): any unauthenticated client hitting the same URL retrieves cached share-scoped data without presenting any token.\n\n## Affected\n\n- Config required: `CACHE_ENABLED=true` (any store: memory, redis, memcached) plus at least one active `directus_shares` row. This is not a default-on bug: `CACHE_ENABLED` ships as `false`. The cache is documented as a production performance setting, so operators who enable it are the ones affected.\n\n## Vulnerability class\n\n- **CWE-524:** Use of Cache Containing Sensitive Information\n- **CWE-639:** Authorization Bypass Through User-Controlled Key (the key here is the derived cache key, not the URL)\n- **OWASP API3:2023:** Broken Object Property Level Authorization\n\n## Impact\n\n- **Cross-share confidentiality breach.** Any share\u0027s filtered response can be served to a holder of a different share token, or to an anonymous request, that hits the same URL and query. Shares are advertised as a mechanism to distribute scoped, read-only access to specific items; this bug makes every cached share response readable by any other share-token holder who can reach the URL (the item-detail admin UI uses a predictable pattern).\n- **Anonymous request can read share data.** Anonymous requests also compute `user=null`. An anonymous client hitting `/items/articles?fields=*` after a share request has populated the cache receives the share\u0027s scoped payload with zero authentication.\n- **Password-protected share, derivative effect.** Password protection lives only at `shares.login` (JWT issuance). Once any share has populated the cache for a URL, an anonymous or alternate-share request to that URL retrieves the cached payload without exchanging the share password. This is the same cache-key collision surfacing as a password-protection bypass symptom, not a distinct mechanism.\n- **Persistence.** The leak persists for the `CACHE_TTL` window (commonly 5 to 30 minutes). `CACHE_AUTO_PURGE` clears on mutating writes to cached collections but does not purge per-user or per-share. With `CACHE_STORE=redis` (common in production) the poisoned bucket survives server restarts.\n- **No write impact.** The bypass is read-only.\n\nScope of the leak depends on the share\u0027s permission surface. A share with no backing role (`directus_shares.role = null`, the default) collapses visibility to the primary key, so the cache leaks only PKs. A share backed by a role with broader field access (the intended production setup for distributing useful content) leaks the full content that role can see on the scoped item.",
  "id": "GHSA-c6w9-5g5j-jh2p",
  "modified": "2026-07-20T21:48:15Z",
  "published": "2026-07-20T21:48:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-c6w9-5g5j-jh2p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61836"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/pull/27707"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/7ba4efb97525d3af33570537c76e44baea767f13"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/releases/tag/v12.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Directus: Authorization-dependent response served from unsegmented cache key"
}

{
  "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"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "http-cache-semantics"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-93748"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-02T22:36:42Z",
    "nvd_published_at": "2026-09-18T18:18:33Z",
    "severity": "HIGH"
  },
  "details": "http-cache-semantics through 4.2.0 fails to properly validate security-zeroed cache entries when processing client max-stale directives, allowing unauthenticated attackers to retrieve cached responses belonging to other users. Attackers can request the same URL with a large max-stale value to obtain another user\u0027s Set-Cookie session credentials from shared-cache entries that were deliberately zeroed for security reasons.",
  "id": "GHSA-ch52-4w7c-c8xp",
  "modified": "2026-10-02T22:36:42Z",
  "published": "2026-09-18T18:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93748"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kornelski/http-cache-semantics/issues/56"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kornelski/http-cache-semantics"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kornelski/http-cache-semantics/blob/f01112e954b83cfa8765b633ba880e5e980aa54c/index.js#L425-L441"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kornelski/http-cache-semantics/blob/f01112e954b83cfa8765b633ba880e5e980aa54c/index.js#L603-L623"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/http-cache-semantics-through-4.2.0-cross-user-cache-disclosure-via-max-stale"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "http-cache-semantics max-stale handling can disclose cross-user cached responses"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-15743"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-20T19:16:48Z",
    "severity": "MODERATE"
  },
  "details": "Catalyst::Plugin::Static::Simple versions through 0.38 for Perl mark responses as publicly cacheable.\n\nThe _serve_static method always sets the Cache-Control header to \"public\", with no means of overriding it.  This advises proxies that the content may be stored in a shared cache, and may be reused in responses to requests from other users. (This includes requests with an Authorization header.)\n\nConfiguring the expires time to \"0\" to disable caching, as documented, is ignored.",
  "id": "GHSA-cj6v-gcgr-8wgg",
  "modified": "2026-08-28T18:31:22Z",
  "published": "2026-08-20T21:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15743"
    },
    {
      "type": "WEB",
      "url": "https://github.com/perl-catalyst/Catalyst-Plugin-Static-Simple/pull/3"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc9111"
    },
    {
      "type": "WEB",
      "url": "https://security.metacpan.org/patches/C/Catalyst-Plugin-Static-Simple/0.38/CVE-2026-15743-r1.patch"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/20/18"
    }
  ],
  "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"
    }
  ]
}

{
  "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"
    }
  ]
}