CWE-524

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Umbraco.Forms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "13.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Umbraco.Forms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.0.0-beta001"
            },
            {
              "fixed": "16.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Umbraco.Forms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "17.0.0-rc1"
            },
            {
              "fixed": "17.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-22T18:06:01Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\nProtected files uploaded through Umbraco Forms may be served to unauthenticated users when a CDN or caching layer is present and ImageSharp processes the request. ImageSharp sets aggressive cache headers by default, which can cause intermediary caches to store and serve files that should require authentication.\n\n### Patches\nThis issue affects all (supported) versions Umbraco Forms and is patched in 13.9.0, 16.4.0 and 17.1.0.\n\n### Workarounds\nAdd middleware to set cache headers for form uploads. Place the following code in your `Startup.cs` or `Program.cs` after `app.UseStaticFiles()` and any image processing middleware:\n\n```cs\napp.Use(async (context, next) =\u003e\n{\n    var path = context.Request.Path.Value;\n\n    if (!string.IsNullOrEmpty(path) \u0026\u0026 path.StartsWith(\"/media/forms/upload/\", StringComparison.OrdinalIgnoreCase))\n    {\n        context.Response.OnStarting(() =\u003e\n        {\n            context.Response.Headers[\"Cache-Control\"] = \"private, no-store, no-cache, must-revalidate\";\n            context.Response.Headers[\"Pragma\"] = \"no-cache\";\n            context.Response.Headers[\"Expires\"] = \"0\";\n            return Task.CompletedTask;\n        });\n    }\n\n    await next();\n});\n```\n\nAlternatively, configure your CDN to bypass caching for URLs matching `/media/forms/upload/*`.\n\n  Note: The vulnerability requires:\n  - A CDN in front of the website\n  - An authenticated user having previously requested the image\n  - Knowledge of the form GUID, entry GUID, and image filename\n\n  If no CDN is in use, this vulnerability does not apply.",
  "id": "GHSA-7jxj-rpx7-ph2c",
  "modified": "2026-01-22T18:06:01Z",
  "published": "2026-01-22T18:06:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/umbraco/Umbraco.Forms.Issues/security/advisories/GHSA-7jxj-rpx7-ph2c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/umbraco/Umbraco.Forms.Issues"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Umbraco.Forms CDN may cache sensitive form uploads when processed by ImageSharp"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-32909"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-01T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with improved handling of caches. This issue is fixed in iOS 16. An app may be able to access user-sensitive data.",
  "id": "GHSA-84ww-4wqp-3333",
  "modified": "2022-11-02T19:00:24Z",
  "published": "2022-11-02T12:00:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32909"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213446"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-65755"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-23T10:16:53Z",
    "severity": "HIGH"
  },
  "details": "Date-sensitive query cache keys did not retain a bounded time component. Cached results could remain active across future publication or expiry boundaries, potentially exposing content after it should become unavailable.",
  "id": "GHSA-88mr-69pq-px7w",
  "modified": "2026-07-28T18:32:43Z",
  "published": "2026-07-23T12:32:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65755"
    },
    {
      "type": "WEB",
      "url": "https://regularlabs.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.16.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.17.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.136.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.137.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59903"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T18:24:26Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nNetty\u0027s `CorsHandler` silently overwrites existing `Vary` headers, enabling cache poisoning and sensitive information disclosure.\n\n### Details\n`io.netty.handler.codec.http.cors.CorsHandler#setVaryHeader` overwrites any existing Vary headers set by backend applications. \n\n```java\n    private static void setVaryHeader(final HttpResponse response) {\n        response.headers().set(HttpHeaderNames.VARY, HttpHeaderNames.ORIGIN);\n    }\n```\n\nBecause `set()` replaces all existing values for the header, if a backend application sets a `Vary` header (such as `Vary: Authorization` or `Vary: Cookie`) to ensure that intermediate caches (like CDNs) cache responses separately per user, the `CorsHandler` will overwrite it with `Vary: origin`. This causes the caching proxy to ignore the authorization context and cache the response based solely on the URL and Origin, allowing an attacker to retrieve another user\u0027s cached sensitive data.\n\n### Impact\nThis is a Cache Poisoning vulnerability that leads to Information Disclosure. It impacts any Netty-based web application that uses the CorsHandler, sets its own Vary headers to manage caching of authenticated or user-specific responses (e.g., Vary: Authorization), and is deployed behind a caching proxy or CDN. The end-users of these applications are impacted, as their sensitive data may be leaked to unauthorized actors.",
  "id": "GHSA-8c42-7qj2-3j46",
  "modified": "2026-08-17T18:24:26Z",
  "published": "2026-08-17T18:24:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-8c42-7qj2-3j46"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/17213"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/17217"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.137.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.17.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty Vulnerable to Cache Poisoning and Information Disclosure via CORS Vary Header Overwrite"
}

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