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.

138 vulnerabilities reference this CWE, most recent first.

GHSA-35HP-HQMV-8QG8

Vulnerability from github – Published: 2026-04-28 22:28 – Updated: 2026-05-08 13:42
VLAI
Summary
Fiber's cache middleware default key generator ignores query string, causing response mix-up across distinct query parameters
Details

Summary

Fiber cache middleware's default key generator uses only c.Path() and does not include the query string. As a result, requests like /?id=1 and /?id=2 can map to the same cache key and share the same cached response.

This can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.

Details

Default configuration in cache middleware:

  • KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }

References: - https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92 - https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621

The existing test demonstrates that when handler output depends on query parameter id, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.

PoC

Minimal PoC:

package main

import (
    "log"

    "github.com/gofiber/fiber/v3"
    "github.com/gofiber/fiber/v3/middleware/cache"
)

func main() {
    app := fiber.New()
    app.Use(cache.New()) // default config

    app.Get("/", func(c fiber.Ctx) error {
        return c.SendString(c.Query("id", "1"))
    })

    log.Fatal(app.Listen(":3000"))
}

Reproduction:

  1. GET /?id=1
  2. Cache miss
  3. Response body: 1
  4. GET /?id=2
  5. Cache hit
  6. Response body: 1 (expected 2)

Local verification command used:

go test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1

Observed result: test passes, confirming this is current behavior.

Impact

  • Responses that should vary by query parameters can be mixed between requests.
  • In real deployments, this may leak or corrupt user/tenant-specific content if query parameters influence context or data selection.
  • This is deployment-dependent but security-relevant, and not safe-by-default for query-variant responses.

Suggested remediation

  • Change default cache key generation to include path + normalized query string (or canonicalized original URL).
  • Keep ability for custom key generators.
  • Add explicit documentation warning that path-only keying is unsafe for query-dependent responses.
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gofiber/fiber/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-436",
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-28T22:28:14Z",
    "nvd_published_at": "2026-05-05T13:16:28Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nFiber cache middleware\u0027s default key generator uses only `c.Path()` and does not include the query string.\nAs a result, requests like `/?id=1` and `/?id=2` can map to the same cache key and share the same cached response.\n\nThis can cause response mix-up (cache poisoning-like behavior) for endpoints where response content depends on query parameters.\n\n### Details\nDefault configuration in cache middleware:\n\n- `KeyGenerator: func(c fiber.Ctx) string { return utils.CopyString(c.Path()) }`\n\nReferences:\n- https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92\n- https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621\n\nThe existing test demonstrates that when handler output depends on query parameter `id`, a second request with a different query still returns the first cached response (cache hit), confirming query is not part of the default cache key.\n\n### PoC\nMinimal PoC:\n\n```go\npackage main\n\nimport (\n    \"log\"\n\n    \"github.com/gofiber/fiber/v3\"\n    \"github.com/gofiber/fiber/v3/middleware/cache\"\n)\n\nfunc main() {\n    app := fiber.New()\n    app.Use(cache.New()) // default config\n\n    app.Get(\"/\", func(c fiber.Ctx) error {\n        return c.SendString(c.Query(\"id\", \"1\"))\n    })\n\n    log.Fatal(app.Listen(\":3000\"))\n}\n```\n\nReproduction:\n\n1. `GET /?id=1`\n   - Cache miss\n   - Response body: `1`\n2. `GET /?id=2`\n   - Cache hit\n   - Response body: `1` (expected `2`)\n\nLocal verification command used:\n\n```bash\ngo test ./middleware/cache -run Test_Cache_WithNoCacheRequestDirective -count=1\n```\n\nObserved result: test passes, confirming this is current behavior.\n\n### Impact\n- Responses that should vary by query parameters can be mixed between requests.\n- In real deployments, this may leak or corrupt user/tenant-specific content if query parameters influence context or data selection.\n- This is deployment-dependent but security-relevant, and not safe-by-default for query-variant responses.\n\n### Suggested remediation\n- Change default cache key generation to include path + normalized query string (or canonicalized original URL).\n- Keep ability for custom key generators.\n- Add explicit documentation warning that path-only keying is unsafe for query-dependent responses.",
  "id": "GHSA-35hp-hqmv-8qg8",
  "modified": "2026-05-08T13:42:45Z",
  "published": "2026-04-28T22:28:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/security/advisories/GHSA-35hp-hqmv-8qg8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30246"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/commit/050ff1ff18511c1475b8ec627460216aaecddd4e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/commit/9a0d12c07ed895b84c72987f9288b04137afe5de"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gofiber/fiber"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/blob/main/middleware/cache/cache_test.go#L599-L621"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/blob/main/middleware/cache/config.go#L90-L92"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fiber\u0027s cache middleware default key generator ignores query string, causing response mix-up across distinct query parameters"
}

GHSA-3H9F-R86X-QVJX

Vulnerability from github – Published: 2026-07-07 15:32 – Updated: 2026-08-07 20:00
VLAI
Summary
Django: cache middleware may expose private responses when unrelated request cookies are present
Details

An issue was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16. UpdateCacheMiddleware and the cache_page() decorator cache responses that vary on cookies when the incoming request carries unrelated cookies, which allows remote attackers to read private data from the shared cache. 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 would like to thank Chris Whyland for reporting this issue.

Severity
3.1 (Low)
CVSS:3.1/AV:N/AC:H/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": "0"
            },
            {
              "fixed": "5.2.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48588"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-07T20:00:57Z",
    "nvd_published_at": "2026-07-07T15:16:47Z",
    "severity": "LOW"
  },
  "details": "An issue was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16.\n`UpdateCacheMiddleware` and the `cache_page()` decorator cache responses that vary on cookies when the incoming request carries unrelated cookies, which allows remote attackers to read private data from the shared cache.\nEarlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.\nDjango would like to thank Chris Whyland for reporting this issue.",
  "id": "GHSA-3h9f-r86x-qvjx",
  "modified": "2026-08-07T20:00:57Z",
  "published": "2026-07-07T15:32:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48588"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/64f9a2b2283fde3ec69fb0dfe441cf0f6f411ba3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/6e365f8d01f2ba0bbd90968d76a42600fb8bc4b1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/721685aa7799cc9327bd202cd1f70bd012ca95a7"
    },
    {
      "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-2090.yaml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/django-announce"
    },
    {
      "type": "WEB",
      "url": "https://www.djangoproject.com/weblog/2026/jul/07/security-releases"
    }
  ],
  "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"
    },
    {
      "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: cache middleware may expose private responses when unrelated request cookies are present"
}

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