GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-524

Allowed

Use of Cache Containing Sensitive Information

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.

115 vulnerabilities reference this CWE, most recent first.

GHSA-3WP3-XXJ9-5JQQ

Vulnerability from github – Published: 2026-07-24 17:03 – Updated: 2026-07-24 17:03
VLAI
Summary
Open WebUI: Cross-user model-list exposure via static cache key in get_all_models (aiocache key= vs key_builder= misuse)
Details

Summary

The get_all_models handlers in routers/openai.py and routers/ollama.py intended to cache their permission-filtered model lists per user, but the @cached decorator was misconfigured: it passed a key= lambda instead of key_builder=. In aiocache 0.12.3 (the pinned version), key= is a static cache key — a callable passed there is used as a constant object, not invoked per call. As a result the per-user key was never computed, and all callers collided onto a single shared cache entry within the TTL window. During that window, one user's permission-filtered model list could be served to a different authenticated user, crossing the per-user authorization boundary.

Impact

  • Boundary crossed: Confidentiality (cross-user). A caller can receive the model list scoped to a different security principal than themselves.
  • A user (or admin, or — depending on endpoint reachability — anonymous caller) who populates the cache causes the next caller within the TTL to receive that list rather than their own permission-filtered one.
  • What's disclosed is the set of models another principal can access, including potentially the existence and naming of models restricted from the receiving user.
  • Exposure is incidental and timing-dependent, not attacker-controlled: the leaked entry is whatever the most recent caller populated within MODELS_CACHE_TTL (default 1 second), and the attacker cannot select the victim or force a target's list into the cache.

Affected component

  • backend/open_webui/routers/openai.py — get_all_models (~line 488)
  • backend/open_webui/routers/ollama.py — get_all_models (~line 302)

Both decorated with @cached(ttl=MODELS_CACHE_TTL, key=lambda ...). No other @cached(... key=lambda ...) misuse was found elsewhere in the backend.

Root cause

aiocache 0.12's @cached treats key= as a static key; the per-call hook is key_builder= with signature key_builder(func, *args, **kwargs). Passing a callable to key= uses the callable object itself as a constant key, so every invocation resolved to the same entry and the intended per-user.id namespacing never occurred.

Reproduction (default config)

  1. On a default deployment, configure at least two users with different model-access permissions (e.g. one model restricted to user A).
  2. As user A, request the model list (populates the shared cache entry).
  3. Within MODELS_CACHE_TTL (default 1s), as user B, request the model list.
  4. User B receives user A's permission-filtered list, including models B is not permitted to see.

Remediation

Replace key= with key_builder= at both call sites and adjust the lambda to take the function as its first argument:

@cached(
    ttl=MODELS_CACHE_TTL,
    key_builder=lambda _func, request, user=None: (
        f'openai_all_models_{user.id}' if user else 'openai_all_models'
    ),
)
Severity
3.5 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.27"
            },
            {
              "fixed": "0.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59213"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T17:03:21Z",
    "nvd_published_at": "2026-07-09T17:17:02Z",
    "severity": "LOW"
  },
  "details": "## Summary\n\nThe `get_all_models` handlers in `routers/openai.py` and `routers/ollama.py` intended to cache their **permission-filtered** model lists per user, but the `@cached` decorator was misconfigured: it passed a `key=` lambda instead of `key_builder=`. In aiocache 0.12.3 (the pinned version), `key=` is a **static** cache key \u2014 a callable passed there is used as a constant object, not invoked per call. As a result the per-user key was never computed, and all callers collided onto a single shared cache entry within the TTL window. During that window, one user\u0027s permission-filtered model list could be served to a different authenticated user, crossing the per-user authorization boundary.\n\n## Impact\n\n- **Boundary crossed:** Confidentiality (cross-user). A caller can receive the model list scoped to a *different* security principal than themselves.\n- A user (or admin, or \u2014 depending on endpoint reachability \u2014 anonymous caller) who populates the cache causes the next caller within the TTL to receive *that* list rather than their own permission-filtered one.\n- What\u0027s disclosed is the set of models another principal can access, including potentially the existence and naming of models restricted from the receiving user.\n- Exposure is **incidental and timing-dependent**, not attacker-controlled: the leaked entry is whatever the most recent caller populated within `MODELS_CACHE_TTL` (default 1 second), and the attacker cannot select the victim or force a target\u0027s list into the cache.\n\n## Affected component\n\n- `backend/open_webui/routers/openai.py` \u2014 `get_all_models` (~line 488)\n- `backend/open_webui/routers/ollama.py` \u2014 `get_all_models` (~line 302)\n\nBoth decorated with `@cached(ttl=MODELS_CACHE_TTL, key=lambda ...)`. No other `@cached(... key=lambda ...)` misuse was found elsewhere in the backend.\n\n## Root cause\n\naiocache 0.12\u0027s `@cached` treats `key=` as a static key; the per-call hook is `key_builder=` with signature `key_builder(func, *args, **kwargs)`. Passing a callable to `key=` uses the callable object itself as a constant key, so every invocation resolved to the same entry and the intended per-`user.id` namespacing never occurred.\n\n## Reproduction (default config)\n\n1. On a default deployment, configure at least two users with *different* model-access permissions (e.g. one model restricted to user A).\n2. As user A, request the model list (populates the shared cache entry).\n3. Within `MODELS_CACHE_TTL` (default 1s), as user B, request the model list.\n4. User B receives user A\u0027s permission-filtered list, including models B is not permitted to see.\n\n## Remediation\n\nReplace `key=` with `key_builder=` at both call sites and adjust the lambda to take the function as its first argument:\n\n```python\n@cached(\n    ttl=MODELS_CACHE_TTL,\n    key_builder=lambda _func, request, user=None: (\n        f\u0027openai_all_models_{user.id}\u0027 if user else \u0027openai_all_models\u0027\n    ),\n)\n```",
  "id": "GHSA-3wp3-xxj9-5jqq",
  "modified": "2026-07-24T17:03:21Z",
  "published": "2026-07-24T17:03:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-3wp3-xxj9-5jqq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59213"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/pull/25783"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/0fc630b34b2899599dabffffa012afd47599aa75"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.10.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Cross-user model-list exposure via static cache key in get_all_models (aiocache key= vs key_builder= misuse)"
}

GHSA-545H-7G69-QC2H

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30
VLAI
Details

Android App "Brother iPrint&Scan" versions 6.13.7 and earlier improperly uses an external cache directory. If exploited, application-specific files may be accessed from other malicious applications.

Severity
3.3 (Low)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
4.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-64696"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:18:17Z",
    "severity": "MODERATE"
  },
  "details": "Android App \"Brother iPrint\u0026Scan\" versions 6.13.7 and earlier improperly uses an external cache directory. If exploited, application-specific files may be accessed from other malicious applications.",
  "id": "GHSA-545h-7g69-qc2h",
  "modified": "2025-12-09T18:30:40Z",
  "published": "2025-12-09T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64696"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU99973778"
    },
    {
      "type": "WEB",
      "url": "https://support.brother.com/g/s/security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-55VG-3HCG-W78F

Vulnerability from github – Published: 2025-06-13 00:33 – Updated: 2025-06-13 00:33
VLAI
Details

An insufficient implementation of cache vulnerability in Palo Alto Networks Prisma® Access Browser enables users to bypass certain data control policies.

Severity
5.1 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/AU:N/R:U/V:D/RE:M/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-4233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-12T23:15:21Z",
    "severity": "MODERATE"
  },
  "details": "An insufficient implementation of cache vulnerability in Palo Alto Networks Prisma\u00ae Access Browser enables users to bypass certain data control policies.",
  "id": "GHSA-55vg-3hcg-w78f",
  "modified": "2025-06-13T00:33:18Z",
  "published": "2025-06-13T00:33:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4233"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2025-4233"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/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:N/R:U/V:D/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-583R-5M7H-H9QF

Vulnerability from github – Published: 2025-04-24 21:31 – Updated: 2025-04-24 21:31
VLAI
Details

Missing "no cache" headers in HCL Leap permits sensitive data to be cached.

Severity
3.2 (Low)
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-30127"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-24T21:15:21Z",
    "severity": "LOW"
  },
  "details": "Missing \"no cache\" headers in HCL Leap permits sensitive data to be cached.",
  "id": "GHSA-583r-5m7h-h9qf",
  "modified": "2025-04-24T21:31:48Z",
  "published": "2025-04-24T21:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30127"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0119900"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5HRC-GVXJ-W55P

Vulnerability from github – Published: 2026-05-05 18:33 – Updated: 2026-06-06 00:27
VLAI
Summary
Django Uses Cache Containing Sensitive Information
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 ('*'). 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.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
2.3 (Low)
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
Show details on source website
To clipboard 

{
  "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:58
VLAI
Summary
Ghost: Cache-poisoning XSS in Ghost frontend via x-ghost-preview header
Details

Impact

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.

Severity
9.6 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "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:08
VLAI
Summary
Next.js: Cache confusion of response bodies for requests with bodies
Details

Impact

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.

Severity
6.0 (Medium)
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
Show details on source website
To clipboard 

{
  "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:28
VLAI
Summary
Flask session does not add `Vary: Cookie` header when accessed in some ways
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.

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.

  1. The application must be hosted behind a caching proxy that does not ignore responses with cookies.
  2. The application does not set a Cache-Control header to indicate that a page is private or should not be cached.
  3. The application accesses the session in a way that does not access the values, only the keys, and does not mutate the session.
Severity
2.3 (Low)
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
Show details on source website
To clipboard 

{
  "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:39
VLAI
Summary
Hono cache middleware ignores "Cache-Control: private" leading to Web Cache Deception
Details

Summary

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
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "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:36
VLAI
Summary
rdiffweb vulnerable to Use of Cache Containing Sensitive Information
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.

Severity
4.6 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
5.1 (Medium)
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
Show details on source website
To clipboard 

{
  "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"
}
Mitigation
Architecture and Design

Protect information stored in cache.

Mitigation
Architecture and Design

Do not store unnecessarily sensitive information in the cache.

Mitigation
Architecture and Design

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.

← Back to the CWE list