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.

134 vulnerabilities reference this CWE, most recent first.

GHSA-3M6R-3GW2-H96X

Vulnerability from github – Published: 2024-05-14 18:31 – Updated: 2024-05-14 18:31
VLAI
Details

SAP Business Objects Business Intelligence Platform is vulnerable to Insecure Storage as dynamic web pages are getting cached even after logging out. On successful exploitation, the attacker can see the sensitive information through cache and can open the pages causing limited impact on Confidentiality, Integrity and Availability of the application.

Severity
4.3 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-33004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524",
      "CWE-922"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-14T16:17:13Z",
    "severity": "MODERATE"
  },
  "details": "SAP Business Objects Business Intelligence Platform is vulnerable to Insecure Storage as dynamic web pages are getting cached even after logging out. On successful exploitation, the attacker can see the sensitive information through cache and can open the pages causing limited impact on Confidentiality, Integrity and Availability of the application.",
  "id": "GHSA-3m6r-3gw2-h96x",
  "modified": "2024-05-14T18:31:01Z",
  "published": "2024-05-14T18:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33004"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3449093"
    },
    {
      "type": "WEB",
      "url": "https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3W37-WQ28-93X7

Vulnerability from github – Published: 2026-10-07 20:32 – Updated: 2026-10-07 20:32
VLAI
Summary
Next.js: Pending `use cache` fill can leak Draft Mode content into regular responses and persisted pages
Details

Pending use cache fills are shared across requests for the same key without distinguishing Draft Mode requests from regular requests. When two such requests overlap, the second request receives the first request's fill:

  • A regular request that overlaps an editor's Draft Mode request receives unpublished content, without any authentication.
  • A Draft Mode request that overlaps a regular request receives published content instead of the draft.

If the overlapping regular request prerenders a page — for example an on-demand prerender of a route that was not prerendered at build time — the unpublished content can be persisted into the generated page and served to all later visitors of that route until the page is revalidated. Since cached functions can be shared across routes, the poisoned page does not need to be the page the editor is previewing.

Sites are affected if they enable Cache Components (or experimental.useCache) and serve Draft Mode previews whose cached functions return draft-dependent content.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "16.3.0"
            },
            {
              "fixed": "16.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-94544"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T20:32:13Z",
    "nvd_published_at": "2026-10-02T16:16:52Z",
    "severity": "MODERATE"
  },
  "details": "Pending `use cache` fills are shared across requests for the same key without distinguishing Draft Mode requests from regular requests. When two such requests overlap, the second request receives the first request\u0027s fill:\n\n- A regular request that overlaps an editor\u0027s Draft Mode request receives unpublished content, without any authentication.\n- A Draft Mode request that overlaps a regular request receives published content instead of the draft.\n\nIf the overlapping regular request prerenders a page \u2014 for example an on-demand prerender of a route that was not prerendered at build time \u2014 the unpublished content can be persisted into the generated page and served to all later visitors of that route until the page is revalidated. Since cached functions can be shared across routes, the poisoned page does not need to be the page the editor is previewing.\n\nSites are affected if they enable Cache Components (or `experimental.useCache`) and serve Draft Mode previews whose cached functions return draft-dependent content.",
  "id": "GHSA-3w37-wq28-93x7",
  "modified": "2026-10-07T20:32:13Z",
  "published": "2026-10-07T20:32:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-3w37-wq28-93x7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94544"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/bd9214f9a32854a011bf5fe58e481dffe1bbf598"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/next.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/releases/tag/v16.3.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Next.js: Pending `use cache` fill can leak Draft Mode content into regular responses and persisted pages"
}

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-4H6W-PVRH-G28P

Vulnerability from github – Published: 2026-09-16 09:30 – Updated: 2026-09-16 09:30
VLAI
Details

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-89186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-16T09:17:07Z",
    "severity": "MODERATE"
  },
  "details": "Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.\n\nMPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.\n\nThis issue affects mpp: from 0.1.0 before 0.16.2.",
  "id": "GHSA-4h6w-pvrh-g28p",
  "modified": "2026-09-16T09:30:29Z",
  "published": "2026-09-16T09:30:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-82qh-vrvm-gqvc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89186"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZenHive/mpp/commit/2d4d1d94aae7790ae0623063961adbeef171fa71"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZenHive/mpp/commit/2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-89186.html"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-89186"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/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-4JQV-MC3X-M676

Vulnerability from github – Published: 2026-10-07 20:32 – Updated: 2026-10-07 20:32
VLAI
Summary
Next.js has cache poisoning of SSG and ISR pages in self-hosted applications
Details

Self-hosted Next.js applications that use the Pages Router with statically generated (SSG) or incrementally regenerated (ISR) pages can have a page's cache entry replaced with content from a different route, causing the affected page to serve wrong content to every visitor until the entry is revalidated. Applications deployed on Vercel are not affected.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.0"
            },
            {
              "fixed": "15.5.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "16.0.0"
            },
            {
              "fixed": "16.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-94543"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T20:32:06Z",
    "nvd_published_at": "2026-10-02T16:16:52Z",
    "severity": "MODERATE"
  },
  "details": "Self-hosted Next.js applications that use the Pages Router with statically generated (SSG) or incrementally regenerated (ISR) pages can have a page\u0027s cache entry replaced with content from a different route, causing the affected page to serve wrong content to every visitor until the entry is revalidated. Applications deployed on Vercel are not affected.",
  "id": "GHSA-4jqv-mc3x-m676",
  "modified": "2026-10-07T20:32:07Z",
  "published": "2026-10-07T20:32:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-4jqv-mc3x-m676"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94543"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/52c94abdd2ea5f416f5e8353ea8a2edd3fe311b8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/719e4c67d6e92df60246f95e1d96e2dd60789a52"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/next.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/releases/tag/v15.5.27"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/releases/tag/v16.3.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Next.js has cache poisoning of SSG and ISR pages in self-hosted applications"
}

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