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.
138 vulnerabilities reference this CWE, most recent first.
GHSA-5974-GFQC-WRCM
Vulnerability from github – Published: 2026-10-09 20:53 – Updated: 2026-10-09 20:53Due to a caching defect in the security voter that governs table-level access to Contao's Data Container (DCA) backend, a low-privileged, non-admin backend user can obtain unauthorized read, create, update, and delete access to database tables outside their assigned module permissions. This includes tables containing sensitive personal data, such as frontend member records and newsletter subscriber e-mail addresses.
Vulnerability Details
In plain terms: Contao's backend is organized into modules (e.g. "News", "Members"). Every backend user is assigned to a group, and that group decides which modules, and therefore which database tables, they are allowed to work with. Before Contao lets a user touch a table, it is supposed to check: "does this user's group actually include this table?"
To avoid doing that check over and over, Contao remembers the answer for the rest of the request. The problem is that it remembers the answer under the wrong label. Instead of remembering "is this user allowed to access table X", it only remembers "is this user allowed to access something", without recording which table the answer was actually about.
So if a request first checks a table the user IS allowed to see, and then checks a second, completely different table the user is NOT allowed to see, Contao reuses the first answer for the second table too. The user ends up with access to a table their group was never given permission for.
Technical detail
Contao's backend enforces per-table access control through a chain of Symfony security voters. The relevant one is
TableAccessVoter::hasAccessToModule(), in core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php:
```php private array $canAccessTable = []; private array $canReadAccessTable = [];
private function hasAccessToModule(TokenInterface $token, ...): bool
{
$tokenHash = hash('xxh128', serialize($token));
if (isset($this->canAccessTable[$tokenHash]) || (...)) {
return $this->canAccessTable[$tokenHash] ?? $this->canReadAccessTable[$tokenHash];
}
$table = $subject->getDataSource();
foreach ($GLOBALS['BE_MOD'] as $modules) {
...
return $this->canAccessTable[$tokenHash] = true; // or false
}
}
```
The cache key, $tokenHash, is built only from the current user's security token. It does not include the table being checked. Because TableAccessVoter is a normal, shared Symfony service, this cache stays alive for the whole duration of one HTTP request. So the first table checked for a user in a request decides the cached answer for every other table checked afterwards in that same request, whether or not that answer is actually correct for the second table.
This is made worse by DefaultDataContainerVoter, a low-priority, permissive fallback voter that grants access to any table-related permission unless another voter explicitly denies it. When TableAccessVoter gives a wrong "no opinion" answer because of the stale cache, this fallback voter turns that into a full grant.
Most database tables in Contao have no second, table-specific check to catch this. Only tl_content, tl_favorites, tl_form, tl_form_field, tl_module, tl_image_size(_item), tl_job, tl_layout, tl_page, tl_preview_link, tl_undo, and tl_user have one. Tables such as tl_member (website member data), tl_newsletter_recipients (subscriber e-mail addresses), tl_news, tl_calendar_events, tl_faq, and tl_comments rely only on the defective check described above.
Credits
This security vulnerability was found by Sven Jäger of SySS GmbH.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "contao/core-bundle"
},
"ranges": [
{
"events": [
{
"introduced": "5.7.0"
},
{
"fixed": "5.7.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107851"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:53:42Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Due to a caching defect in the security voter that governs table-level access to Contao\u0027s Data Container (DCA) backend, a low-privileged, non-admin backend user can obtain unauthorized read, create, update, and delete access to database tables outside their assigned module permissions. This includes tables containing sensitive personal data, such as frontend member records and newsletter subscriber e-mail addresses.\n\n### Vulnerability Details\n\nIn plain terms: Contao\u0027s backend is organized into modules (e.g. \"News\", \"Members\"). Every backend user is assigned to a group, and that group decides which modules, and therefore which database tables, they are allowed to work with. Before Contao lets a user touch a table, it is supposed to check: \"does this user\u0027s group actually include this table?\"\n\nTo avoid doing that check over and over, Contao remembers the answer for the rest of the request. The problem is that it remembers the answer under the wrong label. Instead of remembering \"is this user allowed to access table X\", it only remembers \"is this user allowed to access something\", without recording which table the answer was actually about.\n \nSo if a request first checks a table the user IS allowed to see, and then checks a second, completely different table the user is NOT allowed to see, Contao reuses the first answer for the second table too. The user ends up with access to a table their group was never given permission for.\n \n### Technical detail\n \nContao\u0027s backend enforces per-table access control through a chain of Symfony security voters. The relevant one is\n`TableAccessVoter::hasAccessToModule()`, in `core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php`:\n \n```php\n private array $canAccessTable = [];\n private array $canReadAccessTable = [];\n \n private function hasAccessToModule(TokenInterface $token, ...): bool\n {\n $tokenHash = hash(\u0027xxh128\u0027, serialize($token));\n \n if (isset($this-\u003ecanAccessTable[$tokenHash]) || (...)) {\n return $this-\u003ecanAccessTable[$tokenHash] ?? $this-\u003ecanReadAccessTable[$tokenHash];\n }\n \n $table = $subject-\u003egetDataSource();\n \n foreach ($GLOBALS[\u0027BE_MOD\u0027] as $modules) {\n ...\n return $this-\u003ecanAccessTable[$tokenHash] = true; // or false\n }\n }\n ```\n\nThe cache key, `$tokenHash`, is built only from the current user\u0027s security token. It does not include the table being checked. Because `TableAccessVoter` is a normal, shared Symfony service, this cache stays alive for the whole duration of one HTTP request. So the first table checked for a user in a request decides the cached answer for every other table checked afterwards in that same request, whether or not that answer is actually correct for the second table.\n \nThis is made worse by `DefaultDataContainerVoter`, a low-priority, permissive fallback voter that grants access to any table-related permission unless another voter explicitly denies it. When `TableAccessVoter` gives a wrong \"no opinion\" answer because of the stale cache, this fallback voter turns that into a full grant.\n \nMost database tables in Contao have no second, table-specific check to catch this. Only `tl_content`, `tl_favorites`, `tl_form`, `tl_form_field`, `tl_module`, `tl_image_size(_item)`, `tl_job`, `tl_layout`, `tl_page`, `tl_preview_link`, `tl_undo`, and `tl_user` have one. Tables such as `tl_member` (website member data), `tl_newsletter_recipients` (subscriber e-mail addresses), `tl_news`, `tl_calendar_events`, `tl_faq`, and `tl_comments` rely only on the defective check described above.\n\n### Credits\n\nThis security vulnerability was found by Sven J\u00e4ger of SySS GmbH.",
"id": "GHSA-5974-gfqc-wrcm",
"modified": "2026-10-09T20:53:42Z",
"published": "2026-10-09T20:53:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/contao/contao/security/advisories/GHSA-5974-gfqc-wrcm"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/commit/9d6f582a4cc6a758ce11d1043fc9c0ba62c5f4c9"
},
{
"type": "PACKAGE",
"url": "https://github.com/contao/contao"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/releases/tag/5.7.12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Contao: Improper access control in the table access voter"
}
GHSA-5HRC-GVXJ-W55P
Vulnerability from github – Published: 2026-05-05 18:33 – Updated: 2026-06-06 00:27An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14. django.middleware.cache.UpdateCacheMiddleware erroneously caches requests where the Vary header contained an asterisk ('*'). This can lead to private data being stored and served. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django thanks Ahmad Sadeddin for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Django"
},
"ranges": [
{
"events": [
{
"introduced": "6.0"
},
{
"fixed": "6.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "Django"
},
"ranges": [
{
"events": [
{
"introduced": "5.2"
},
{
"fixed": "5.2.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-6907"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T22:15:17Z",
"nvd_published_at": "2026-05-05T16:16:18Z",
"severity": "LOW"
},
"details": "An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14. `django.middleware.cache.UpdateCacheMiddleware` erroneously caches requests where the `Vary` header contained an asterisk (`\u0027*\u0027`). This can lead to private data being stored and served. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.\n\nDjango thanks Ahmad Sadeddin for reporting this issue.",
"id": "GHSA-5hrc-gvxj-w55p",
"modified": "2026-06-06T00:27:52Z",
"published": "2026-05-05T18:33:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6907"
},
{
"type": "WEB",
"url": "https://docs.djangoproject.com/en/dev/releases/security"
},
{
"type": "PACKAGE",
"url": "https://github.com/django/django"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2026-55.yaml"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/django-announce"
},
{
"type": "WEB",
"url": "https://www.djangoproject.com/weblog/2026/may/05/security-releases"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Django Uses Cache Containing Sensitive Information"
}
GHSA-62Q6-4HV4-VJRW
Vulnerability from github – Published: 2026-07-01 21:58 – Updated: 2026-07-01 21:58Impact
When Ghost is behind a shared caching layer that results in cached content being shared between different visitors (e.g., Fastly, Cloudflare, nginx proxy_cache, and others), an unauthenticated user could send an x-ghost-preview header that altered the rendered frontend response. In affected cache configurations, that response could be stored and served to subsequent visitors requesting the same page, allowing cache poisoning of request-specific preview output.
When running Ghost's frontend and admin panel on the same domain this could be used to take over staff user accounts. When running these on different domains staff accounts have no exposure.
Vulnerable versions
This vulnerability is present in Ghost from v4.0 up to v6.36.0.
Patches
v6.37.0 contains a fix for this issue.
How to update
For self-hosters using Docker, find Docker's official Ghost image here. Updating a Docker-based Ghost instance is documented here.
If your Ghost is a Ghost-CLI install see our documentation on updating it to the latest version here.
If you suspect a credential compromise, use the “Reset all authentication” dialogue under Settings / Danger Zone. This is available starting with Ghost v6.41.0.
Workarounds
At the caching layer, bypass the cache for x-ghost-preview requests.
References
Ghost thanks CryptoCat for disclosing this vulnerability responsibly.
For more information
If you have any questions or comments about this advisory, email us at security@ghost.org.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.36.0"
},
"package": {
"ecosystem": "npm",
"name": "ghost"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "6.37.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53943"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T21:58:32Z",
"nvd_published_at": "2026-06-24T19:17:11Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nWhen Ghost is behind a shared caching layer that results in cached content being shared between different visitors (e.g., Fastly, Cloudflare, nginx proxy_cache, and others), an unauthenticated user could send an `x-ghost-preview` header that altered the rendered frontend response. In affected cache configurations, that response could be stored and served to subsequent visitors requesting the same page, allowing cache poisoning of request-specific preview output. \n\nWhen running Ghost\u0027s frontend and admin panel on the same domain this could be used to take over staff user accounts. When running these on different domains staff accounts have no exposure. \n\n### Vulnerable versions\n\nThis vulnerability is present in Ghost from v4.0 up to v6.36.0.\n\n### Patches\n\nv6.37.0 contains a fix for this issue.\n\n### How to update\n\nFor self-hosters using Docker, find [Docker\u0027s official Ghost image here](https://hub.docker.com/_/ghost). Updating a Docker-based Ghost instance [is documented here](https://docs.ghost.org/install/docker#updating-ghost).\n\nIf your Ghost is a Ghost-CLI install see our documentation on [updating it to the latest version here](https://docs.ghost.org/update).\n\nIf you suspect a credential compromise, use the \u201cReset all authentication\u201d dialogue under Settings / Danger Zone. This is available starting with Ghost v6.41.0. \n\n### Workarounds\n\nAt the caching layer, bypass the cache for `x-ghost-preview` requests. \n\n### References\n\nGhost thanks [CryptoCat](https://linkedin.com/in/cryptocat) for disclosing this vulnerability responsibly.\n\n### For more information\n\nIf you have any questions or comments about this advisory, email us at [security@ghost.org](mailto:security@ghost.org).",
"id": "GHSA-62q6-4hv4-vjrw",
"modified": "2026-07-01T21:58:32Z",
"published": "2026-07-01T21:58:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/TryGhost/Ghost/security/advisories/GHSA-62q6-4hv4-vjrw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53943"
},
{
"type": "PACKAGE",
"url": "https://github.com/TryGhost/Ghost"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Ghost: Cache-poisoning XSS in Ghost frontend via x-ghost-preview header"
}
GHSA-68G3-V927-F742
Vulnerability from github – Published: 2026-07-22 23:08 – Updated: 2026-07-22 23:08Impact
A server-side fetch with a request body may return a cached response body from a different request to the same URL but different body. Confidential data in the POST's response body would then leak to unauthorized requests. Though the request itself will not be deduped.
This only applies to fetch calls with a request that has a different init than the one passed to fetch.
Safe: fetch(new Request(init), init)
Unsafe: fetch(new Request(init), aDifferentInit)
Workarounds
No workaround exists besides upgrading. Applications using Pages Router are not vulnerable.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0"
},
{
"fixed": "15.5.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0"
},
{
"fixed": "16.2.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-64648"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T23:08:17Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Impact\n\nA server-side `fetch` with a request body may return a cached **response** body from a different request to the same URL but different body. Confidential data in the `POST`\u0027s **response** body would then leak to unauthorized requests. Though the request itself will not be deduped.\n\nThis only applies to `fetch` calls with a request that has a different init than the one passed to `fetch`.\nSafe: `fetch(new Request(init), init)`\nUnsafe: `fetch(new Request(init), aDifferentInit)`\n\n## Workarounds\n\nNo workaround exists besides upgrading. Applications using Pages Router are not vulnerable.",
"id": "GHSA-68g3-v927-f742",
"modified": "2026-07-22T23:08:17Z",
"published": "2026-07-22T23:08:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/security/advisories/GHSA-68g3-v927-f742"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/commit/062f66700b52a5d6bba2c0605d55577ab7ad262c"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/commit/73b94872bc343d09494b50394d8c08eb9fc8e56a"
},
{
"type": "PACKAGE",
"url": "https://github.com/vercel/next.js"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/releases/tag/v15.5.21"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/releases/tag/v16.2.11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Next.js: Cache confusion of response bodies for requests with bodies"
}
GHSA-68RP-WP8R-4726
Vulnerability from github – Published: 2026-02-19 20:45 – Updated: 2026-02-23 22:28When the session object is accessed, Flask should set the Vary: Cookie header. This instructs caches not to cache the response, as it may contain information specific to a logged in user. This is handled in most cases, but some forms of access such as the Python in operator were overlooked.
The severity depends on the application's use of the session, and the cache's behavior regarding cookies. The risk depends on all these conditions being met.
- The application must be hosted behind a caching proxy that does not ignore responses with cookies.
- The application does not set a
Cache-Controlheader to indicate that a page is private or should not be cached. - The application accesses the session in a way that does not access the values, only the keys, and does not mutate the session.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "flask"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27205"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-19T20:45:41Z",
"nvd_published_at": "2026-02-21T06:17:00Z",
"severity": "LOW"
},
"details": "When the `session` object is accessed, Flask should set the `Vary: Cookie` header. This instructs caches not to cache the response, as it may contain information specific to a logged in user. This is handled in most cases, but some forms of access such as the Python `in` operator were overlooked.\n\nThe severity depends on the application\u0027s use of the session, and the cache\u0027s behavior regarding cookies. The risk depends on all these conditions being met.\n\n1. The application must be hosted behind a caching proxy that does not ignore responses with cookies.\n2. The application does not set a `Cache-Control` header to indicate that a page is private or should not be cached.\n3. The application accesses the session in a way that does not access the values, only the keys, and does not mutate the session.",
"id": "GHSA-68rp-wp8r-4726",
"modified": "2026-02-23T22:28:03Z",
"published": "2026-02-19T20:45:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pallets/flask/security/advisories/GHSA-68rp-wp8r-4726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27205"
},
{
"type": "WEB",
"url": "https://github.com/pallets/flask/commit/089cb86dd22bff589a4eafb7ab8e42dc357623b4"
},
{
"type": "PACKAGE",
"url": "https://github.com/pallets/flask"
},
{
"type": "WEB",
"url": "https://github.com/pallets/flask/releases/tag/3.1.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Flask session does not add `Vary: Cookie` header when accessed in some ways"
}
GHSA-6WQW-2P9W-4VW4
Vulnerability from github – Published: 2026-01-27 19:04 – Updated: 2026-01-29 03:39Summary
Cache Middleware contains an information disclosure vulnerability caused by improper handling of HTTP cache control directives. The middleware does not respect standard cache control headers such as Cache-Control: private or Cache-Control: no-store, which may result in private or authenticated responses being cached and subsequently exposed to unauthorized users.
Details
The vulnerability exists in the cache decision logic of Cache Middleware. When determining whether a response should be cached, the middleware does not take HTTP cache control semantics into account and may cache responses that are explicitly marked as private by the application. While some runtimes, such as Cloudflare Workers, enforce cache control restrictions at the platform level, other runtimes including Deno, Bun, and Node.js rely on the middleware’s behavior. As a result, applications running on these runtimes may unintentionally cache sensitive responses.
Impact
This issue can lead to Web Cache Deception and information disclosure. If an authenticated user accesses an endpoint that returns user-specific or sensitive data and the response is cached despite being marked as private, subsequent unauthenticated requests may receive the cached response. This may result in the exposure of personally identifiable information or session-related data. The impact is limited to applications that use the hono/cache middleware and rely on it to correctly honor HTTP cache control directives.
Affected Components
- Cache Middleware
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "hono"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.11.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24472"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-27T19:04:17Z",
"nvd_published_at": "2026-01-27T20:16:22Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nCache Middleware contains an information disclosure vulnerability caused by improper handling of HTTP cache control directives. The middleware does not respect standard cache control headers such as `Cache-Control: private` or `Cache-Control: no-store`, which may result in private or authenticated responses being cached and subsequently exposed to unauthorized users.\n\n## Details\n\nThe vulnerability exists in the cache decision logic of Cache Middleware. When determining whether a response should be cached, the middleware does not take HTTP cache control semantics into account and may cache responses that are explicitly marked as private by the application. While some runtimes, such as Cloudflare Workers, enforce cache control restrictions at the platform level, other runtimes including Deno, Bun, and Node.js rely on the middleware\u2019s behavior. As a result, applications running on these runtimes may unintentionally cache sensitive responses.\n\n## Impact\n\nThis issue can lead to Web Cache Deception and information disclosure. If an authenticated user accesses an endpoint that returns user-specific or sensitive data and the response is cached despite being marked as private, subsequent unauthenticated requests may receive the cached response. This may result in the exposure of personally identifiable information or session-related data. The impact is limited to applications that use the hono/cache middleware and rely on it to correctly honor HTTP cache control directives.\n\n## Affected Components\n\n* Cache Middleware",
"id": "GHSA-6wqw-2p9w-4vw4",
"modified": "2026-01-29T03:39:36Z",
"published": "2026-01-27T19:04:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-6wqw-2p9w-4vw4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24472"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/commit/12c511745b3f1e7a3f863a23ce5f921c7fa805d1"
},
{
"type": "PACKAGE",
"url": "https://github.com/honojs/hono"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/releases/tag/v4.11.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Hono cache middleware ignores \"Cache-Control: private\" leading to Web Cache Deception"
}
GHSA-7FQM-JM52-F9VC
Vulnerability from github – Published: 2022-09-29 00:00 – Updated: 2024-10-16 21:36rdiffweb prior to version 2.4.9 is vulnerable to Use of Cache Containing Sensitive Information. Due to improper cache control, an attacker can view sensitive information even if they are not logged into an account. Version 2.4.9 contains a patch for this issue.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "rdiffweb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3292"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T05:37:28Z",
"nvd_published_at": "2022-09-28T21:15:00Z",
"severity": "MODERATE"
},
"details": "rdiffweb prior to version 2.4.9 is vulnerable to Use of Cache Containing Sensitive Information. Due to improper cache control, an attacker can view sensitive information even if they are not logged into an account. Version 2.4.9 contains a patch for this issue.",
"id": "GHSA-7fqm-jm52-f9vc",
"modified": "2024-10-16T21:36:40Z",
"published": "2022-09-29T00:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3292"
},
{
"type": "WEB",
"url": "https://github.com/ikus060/rdiffweb/commit/2406780831618405a13113377a784f3102465f40"
},
{
"type": "PACKAGE",
"url": "https://github.com/ikus060/rdiffweb"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/rdiffweb/PYSEC-2022-296.yaml"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/e9309018-e94f-4e15-b7d1-5d38b6021c5d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "rdiffweb vulnerable to Use of Cache Containing Sensitive Information"
}
GHSA-7JXJ-RPX7-PH2C
Vulnerability from github – Published: 2026-01-22 18:06 – Updated: 2026-01-22 18:06Impact
Protected files uploaded through Umbraco Forms may be served to unauthenticated users when a CDN or caching layer is present and ImageSharp processes the request. ImageSharp sets aggressive cache headers by default, which can cause intermediary caches to store and serve files that should require authentication.
Patches
This issue affects all (supported) versions Umbraco Forms and is patched in 13.9.0, 16.4.0 and 17.1.0.
Workarounds
Add middleware to set cache headers for form uploads. Place the following code in your Startup.cs or Program.cs after app.UseStaticFiles() and any image processing middleware:
app.Use(async (context, next) =>
{
var path = context.Request.Path.Value;
if (!string.IsNullOrEmpty(path) && path.StartsWith("/media/forms/upload/", StringComparison.OrdinalIgnoreCase))
{
context.Response.OnStarting(() =>
{
context.Response.Headers["Cache-Control"] = "private, no-store, no-cache, must-revalidate";
context.Response.Headers["Pragma"] = "no-cache";
context.Response.Headers["Expires"] = "0";
return Task.CompletedTask;
});
}
await next();
});
Alternatively, configure your CDN to bypass caching for URLs matching /media/forms/upload/*.
Note: The vulnerability requires: - A CDN in front of the website - An authenticated user having previously requested the image - Knowledge of the form GUID, entry GUID, and image filename
If no CDN is in use, this vulnerability does not apply.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Umbraco.Forms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "13.9.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Umbraco.Forms"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0-beta001"
},
{
"fixed": "16.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Umbraco.Forms"
},
"ranges": [
{
"events": [
{
"introduced": "17.0.0-rc1"
},
{
"fixed": "17.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-22T18:06:01Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nProtected files uploaded through Umbraco Forms may be served to unauthenticated users when a CDN or caching layer is present and ImageSharp processes the request. ImageSharp sets aggressive cache headers by default, which can cause intermediary caches to store and serve files that should require authentication.\n\n### Patches\nThis issue affects all (supported) versions Umbraco Forms and is patched in 13.9.0, 16.4.0 and 17.1.0.\n\n### Workarounds\nAdd middleware to set cache headers for form uploads. Place the following code in your `Startup.cs` or `Program.cs` after `app.UseStaticFiles()` and any image processing middleware:\n\n```cs\napp.Use(async (context, next) =\u003e\n{\n var path = context.Request.Path.Value;\n\n if (!string.IsNullOrEmpty(path) \u0026\u0026 path.StartsWith(\"/media/forms/upload/\", StringComparison.OrdinalIgnoreCase))\n {\n context.Response.OnStarting(() =\u003e\n {\n context.Response.Headers[\"Cache-Control\"] = \"private, no-store, no-cache, must-revalidate\";\n context.Response.Headers[\"Pragma\"] = \"no-cache\";\n context.Response.Headers[\"Expires\"] = \"0\";\n return Task.CompletedTask;\n });\n }\n\n await next();\n});\n```\n\nAlternatively, configure your CDN to bypass caching for URLs matching `/media/forms/upload/*`.\n\n Note: The vulnerability requires:\n - A CDN in front of the website\n - An authenticated user having previously requested the image\n - Knowledge of the form GUID, entry GUID, and image filename\n\n If no CDN is in use, this vulnerability does not apply.",
"id": "GHSA-7jxj-rpx7-ph2c",
"modified": "2026-01-22T18:06:01Z",
"published": "2026-01-22T18:06:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/umbraco/Umbraco.Forms.Issues/security/advisories/GHSA-7jxj-rpx7-ph2c"
},
{
"type": "PACKAGE",
"url": "https://github.com/umbraco/Umbraco.Forms.Issues"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Umbraco.Forms CDN may cache sensitive form uploads when processed by ImageSharp"
}
GHSA-84WW-4WQP-3333
Vulnerability from github – Published: 2022-11-02 12:00 – Updated: 2022-11-02 19:00The issue was addressed with improved handling of caches. This issue is fixed in iOS 16. An app may be able to access user-sensitive data.
{
"affected": [],
"aliases": [
"CVE-2022-32909"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-01T20:15:00Z",
"severity": "MODERATE"
},
"details": "The issue was addressed with improved handling of caches. This issue is fixed in iOS 16. An app may be able to access user-sensitive data.",
"id": "GHSA-84ww-4wqp-3333",
"modified": "2022-11-02T19:00:24Z",
"published": "2022-11-02T12:00:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32909"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213446"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-88MR-69PQ-PX7W
Vulnerability from github – Published: 2026-07-23 12:32 – Updated: 2026-07-28 18:32Date-sensitive query cache keys did not retain a bounded time component. Cached results could remain active across future publication or expiry boundaries, potentially exposing content after it should become unavailable.
{
"affected": [],
"aliases": [
"CVE-2026-65755"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T10:16:53Z",
"severity": "HIGH"
},
"details": "Date-sensitive query cache keys did not retain a bounded time component. Cached results could remain active across future publication or expiry boundaries, potentially exposing content after it should become unavailable.",
"id": "GHSA-88mr-69pq-px7w",
"modified": "2026-07-28T18:32:43Z",
"published": "2026-07-23T12:32:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65755"
},
{
"type": "WEB",
"url": "https://regularlabs.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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.