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.

118 vulnerabilities reference this CWE, most recent first.

GHSA-C6W9-5G5J-JH2P

Vulnerability from github – Published: 2026-07-20 21:48 – Updated: 2026-07-20 21:48
VLAI
Summary
Directus: Authorization-dependent response served from unsegmented cache key
Details

Summary

When response caching is enabled (CACHE_ENABLED=true), the cache-key derivation in api/src/utils/get-cache-key.ts includes only version, path, query, and accountability.user (plus a conditional ip). Authorization context beyond user (share, role, roles, admin, app, policies) is not part of the key.

For share tokens this is load-bearing. Directus's share-authentication flow (api/src/services/shares.ts:100-105) issues a JWT without an id claim, so api/src/utils/get-accountability-for-token.ts never assigns accountability.user, leaving it null (the default from create-default-accountability.ts). Every share token, and every anonymous request, therefore reduces to user: null in the cache-key input. Two different shares (or an anonymous request and a share token) requesting the same URL with the same query produce identical cache keys. The first request populates the bucket with a permission-filtered response; subsequent hits from unrelated shares or anonymous clients receive that payload without any permission re-evaluation.

This is the web-cache pattern "authorization-dependent response cached under an unsegmented key" (cache key collision / missing authorization context in cache key, CWE-524 and CWE-639). Two adjacent read populations collide:

  • Share to share: Share A populates the cache, Share B reads Share A's scoped response.
  • Share to anonymous (and the reverse): any unauthenticated client hitting the same URL retrieves cached share-scoped data without presenting any token.

Affected

  • Config required: CACHE_ENABLED=true (any store: memory, redis, memcached) plus at least one active directus_shares row. This is not a default-on bug: CACHE_ENABLED ships as false. The cache is documented as a production performance setting, so operators who enable it are the ones affected.

Vulnerability class

  • CWE-524: Use of Cache Containing Sensitive Information
  • CWE-639: Authorization Bypass Through User-Controlled Key (the key here is the derived cache key, not the URL)
  • OWASP API3:2023: Broken Object Property Level Authorization

Impact

  • Cross-share confidentiality breach. Any share's filtered response can be served to a holder of a different share token, or to an anonymous request, that hits the same URL and query. Shares are advertised as a mechanism to distribute scoped, read-only access to specific items; this bug makes every cached share response readable by any other share-token holder who can reach the URL (the item-detail admin UI uses a predictable pattern).
  • Anonymous request can read share data. Anonymous requests also compute user=null. An anonymous client hitting /items/articles?fields=* after a share request has populated the cache receives the share's scoped payload with zero authentication.
  • Password-protected share, derivative effect. Password protection lives only at shares.login (JWT issuance). Once any share has populated the cache for a URL, an anonymous or alternate-share request to that URL retrieves the cached payload without exchanging the share password. This is the same cache-key collision surfacing as a password-protection bypass symptom, not a distinct mechanism.
  • Persistence. The leak persists for the CACHE_TTL window (commonly 5 to 30 minutes). CACHE_AUTO_PURGE clears on mutating writes to cached collections but does not purge per-user or per-share. With CACHE_STORE=redis (common in production) the poisoned bucket survives server restarts.
  • No write impact. The bypass is read-only.

Scope of the leak depends on the share's permission surface. A share with no backing role (directus_shares.role = null, the default) collapses visibility to the primary key, so the cache leaks only PKs. A share backed by a role with broader field access (the intended production setup for distributing useful content) leaks the full content that role can see on the scoped item.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "12.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61836"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T21:48:15Z",
    "nvd_published_at": "2026-07-15T15:16:48Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nWhen response caching is enabled (`CACHE_ENABLED=true`), the cache-key derivation in `api/src/utils/get-cache-key.ts` includes only `version`, `path`, `query`, and `accountability.user` (plus a conditional `ip`). Authorization context beyond `user` (`share`, `role`, `roles`, `admin`, `app`, `policies`) is not part of the key.\n\nFor share tokens this is load-bearing. Directus\u0027s share-authentication flow (`api/src/services/shares.ts:100-105`) issues a JWT without an `id` claim, so `api/src/utils/get-accountability-for-token.ts` never assigns `accountability.user`, leaving it `null` (the default from `create-default-accountability.ts`). Every share token, and every anonymous request, therefore reduces to `user: null` in the cache-key input. Two different shares (or an anonymous request and a share token) requesting the same URL with the same query produce identical cache keys. The first request populates the bucket with a permission-filtered response; subsequent hits from unrelated shares or anonymous clients receive that payload without any permission re-evaluation.\n\nThis is the web-cache pattern \"authorization-dependent response cached under an unsegmented key\" (cache key collision / missing authorization context in cache key, CWE-524 and CWE-639). Two adjacent read populations collide:\n\n- **Share to share:** `Share A` populates the cache, `Share B` reads `Share A`\u0027s scoped response.\n- **Share to anonymous** (and the reverse): any unauthenticated client hitting the same URL retrieves cached share-scoped data without presenting any token.\n\n## Affected\n\n- Config required: `CACHE_ENABLED=true` (any store: memory, redis, memcached) plus at least one active `directus_shares` row. This is not a default-on bug: `CACHE_ENABLED` ships as `false`. The cache is documented as a production performance setting, so operators who enable it are the ones affected.\n\n## Vulnerability class\n\n- **CWE-524:** Use of Cache Containing Sensitive Information\n- **CWE-639:** Authorization Bypass Through User-Controlled Key (the key here is the derived cache key, not the URL)\n- **OWASP API3:2023:** Broken Object Property Level Authorization\n\n## Impact\n\n- **Cross-share confidentiality breach.** Any share\u0027s filtered response can be served to a holder of a different share token, or to an anonymous request, that hits the same URL and query. Shares are advertised as a mechanism to distribute scoped, read-only access to specific items; this bug makes every cached share response readable by any other share-token holder who can reach the URL (the item-detail admin UI uses a predictable pattern).\n- **Anonymous request can read share data.** Anonymous requests also compute `user=null`. An anonymous client hitting `/items/articles?fields=*` after a share request has populated the cache receives the share\u0027s scoped payload with zero authentication.\n- **Password-protected share, derivative effect.** Password protection lives only at `shares.login` (JWT issuance). Once any share has populated the cache for a URL, an anonymous or alternate-share request to that URL retrieves the cached payload without exchanging the share password. This is the same cache-key collision surfacing as a password-protection bypass symptom, not a distinct mechanism.\n- **Persistence.** The leak persists for the `CACHE_TTL` window (commonly 5 to 30 minutes). `CACHE_AUTO_PURGE` clears on mutating writes to cached collections but does not purge per-user or per-share. With `CACHE_STORE=redis` (common in production) the poisoned bucket survives server restarts.\n- **No write impact.** The bypass is read-only.\n\nScope of the leak depends on the share\u0027s permission surface. A share with no backing role (`directus_shares.role = null`, the default) collapses visibility to the primary key, so the cache leaks only PKs. A share backed by a role with broader field access (the intended production setup for distributing useful content) leaks the full content that role can see on the scoped item.",
  "id": "GHSA-c6w9-5g5j-jh2p",
  "modified": "2026-07-20T21:48:15Z",
  "published": "2026-07-20T21:48:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-c6w9-5g5j-jh2p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61836"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/pull/27707"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/7ba4efb97525d3af33570537c76e44baea767f13"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/releases/tag/v12.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Directus: Authorization-dependent response served from unsegmented cache key"
}

GHSA-CFF8-X7JV-4FM8

Vulnerability from github – Published: 2024-09-10 19:43 – Updated: 2025-11-17 21:35
VLAI
Summary
Session is cached for OpenID and OAuth2 if `redirect` is not used
Details

Summary

Unauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include redirect query string.

For example: - Project is configured with OpenID or OAuth2 - Project is configured with cache enabled - User tries to login via SSO link, but without redirect query string - After successful login, credentials are cached - If an unauthenticated user tries to login via SSO link, it will return the credentials of the other last user

The SSO link is something like https://directus.example.com/auth/login/openid/callback, where openid is the name of the OpenID provider configured in Directus

Details

This happens because on that endpoint for both OpenId and Oauth2 Directus is using the respond middleware, which by default will try to cache GET requests that met some conditions. Although, those conditions do not include this scenario, when an unauthenticated request returns user credentials. For OpenID, this can be seen here: https://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459 And for OAuth2 can be seen here https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428

PoC

  • Create a new Directus project
  • Set CACHE_ENABLED to true
  • Set CACHE_STORE to redis for reliable results (if using memory with multiple nodes, it may only happen sometimes, due to cache being different for different nodes)
  • Configure REDIS with redis string or redis host, port, user, etc.
  • Set AUTH_PROVIDERS to openid
  • Set PUBLIC_URL to the the main URL of your project . For example, PUBLIC_URL: http://localhost:8055
  • Configure AUTH_OPENID_CLIENT_ID, AUTH_OPENID_CLIENT_SECRET, AUTH_OPENID_ISSUER_URL with proper OpenID configurations
  • Be sure that on OpenID external app you have configured Redirect URI to http://localhost:8055/auth/login/openid/callback
  • Run Directus
  • Open the SSO link like http://localhost:8055/auth/login/openid/callback
  • Do the authentication on the OpenID external webpage
  • Verify that it you got redirected to a page with a JSON including access_token property
  • Be sure all anonymous mode windows are closed
  • Open an anonymous window and go to the SSO Link http://localhost:8055/auth/login/openid/callback and see you have the same credentials, even though you don't have any session because you are in anonymous mode

Impact

All projects using OpenID or OAuth 2, that does not include redirect query string on loggin in users.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.13.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-rc.1"
            },
            {
              "fixed": "11.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@directus/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "21.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@directus/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0"
            },
            {
              "fixed": "22.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45596"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-384",
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-10T19:43:00Z",
    "nvd_published_at": "2024-09-10T19:15:22Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nUnauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include `redirect` query string.\n\nFor example:\n- Project is configured with OpenID or OAuth2\n- Project is configured with cache enabled\n- User tries to login via SSO link, but without `redirect` query string\n- After successful login, credentials are cached\n- If an unauthenticated user tries to login via SSO link, it will return the credentials of the other last user\n\nThe SSO link is something like `https://directus.example.com/auth/login/openid/callback`, where `openid` is the name of the OpenID provider configured in Directus\n\n### Details\nThis happens because on that endpoint for both OpenId and Oauth2 Directus is using the `respond` middleware, which by default will try to cache GET requests that met some conditions. Although, those conditions do not include this scenario, when an unauthenticated request returns user credentials.\nFor OpenID, this can be seen here:\nhttps://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459\nAnd for OAuth2 can be seen here\nhttps://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428\n\n### PoC\n- Create a new Directus project\n- Set `CACHE_ENABLED` to true\n- Set `CACHE_STORE` to `redis` for reliable results (if using memory with multiple nodes, it may only happen sometimes, due to cache being different for different nodes)\n- Configure `REDIS` with redis string or redis host, port, user, etc.\n- Set `AUTH_PROVIDERS` to `openid`\n- Set `PUBLIC_URL` to the the main URL of your project . \tFor example, `PUBLIC_URL: http://localhost:8055`\n- Configure `AUTH_OPENID_CLIENT_ID`, `AUTH_OPENID_CLIENT_SECRET`, `AUTH_OPENID_ISSUER_URL` with proper OpenID configurations\n- Be sure that on OpenID external app you have configured Redirect URI to `http://localhost:8055/auth/login/openid/callback`\n- Run Directus\n- Open the SSO link like `http://localhost:8055/auth/login/openid/callback`\n- Do the authentication on the OpenID external webpage\n- Verify that it you got redirected to a page with a JSON including `access_token` property\n- Be sure all anonymous mode windows are closed\n- Open an anonymous window and go to the SSO Link `http://localhost:8055/auth/login/openid/callback` and see you have the same credentials, even though you don\u0027t have any session because you are in anonymous mode\n\n### Impact\nAll projects using OpenID or OAuth 2, that does not include `redirect` query string on loggin in users.",
  "id": "GHSA-cff8-x7jv-4fm8",
  "modified": "2025-11-17T21:35:30Z",
  "published": "2024-09-10T19:43:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-cff8-x7jv-4fm8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45596"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/4aace0bbe57232e38cd6a287ee475293e46dc91b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/769fa22797bff5a9231599883b391e013f122e52"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Session is cached for OpenID and OAuth2 if `redirect` is not used"
}

GHSA-CJ6V-GCGR-8WGG

Vulnerability from github – Published: 2026-08-20 21:31 – Updated: 2026-08-28 18:31
VLAI
Details

Catalyst::Plugin::Static::Simple versions through 0.38 for Perl mark responses as publicly cacheable.

The _serve_static method always sets the Cache-Control header to "public", with no means of overriding it. This advises proxies that the content may be stored in a shared cache, and may be reused in responses to requests from other users. (This includes requests with an Authorization header.)

Configuring the expires time to "0" to disable caching, as documented, is ignored.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-15743"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-20T19:16:48Z",
    "severity": "MODERATE"
  },
  "details": "Catalyst::Plugin::Static::Simple versions through 0.38 for Perl mark responses as publicly cacheable.\n\nThe _serve_static method always sets the Cache-Control header to \"public\", with no means of overriding it.  This advises proxies that the content may be stored in a shared cache, and may be reused in responses to requests from other users. (This includes requests with an Authorization header.)\n\nConfiguring the expires time to \"0\" to disable caching, as documented, is ignored.",
  "id": "GHSA-cj6v-gcgr-8wgg",
  "modified": "2026-08-28T18:31:22Z",
  "published": "2026-08-20T21:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15743"
    },
    {
      "type": "WEB",
      "url": "https://github.com/perl-catalyst/Catalyst-Plugin-Static-Simple/pull/3"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc9111"
    },
    {
      "type": "WEB",
      "url": "https://security.metacpan.org/patches/C/Catalyst-Plugin-Static-Simple/0.38/CVE-2026-15743-r1.patch"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/20/18"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F957-W8WH-R29F

Vulnerability from github – Published: 2024-08-13 09:30 – Updated: 2024-08-13 09:30
VLAI
Details

A vulnerability has been identified in SINEC Traffic Analyzer (6GK8822-1BG01-0BA0) (All versions < V2.0). The affected application does not properly handle cacheable HTTP responses in the web service. This could allow an attacker to read and modify data stored in the local cache.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/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:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-41906"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-13T08:15:13Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SINEC Traffic Analyzer (6GK8822-1BG01-0BA0) (All versions \u003c V2.0). The affected application does not properly handle cacheable HTTP responses in the web service. This could allow an attacker to read and modify data stored in the local cache.",
  "id": "GHSA-f957-w8wh-r29f",
  "modified": "2024-08-13T09:30:52Z",
  "published": "2024-08-13T09:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41906"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-716317.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/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:L/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-FMVV-F47M-6C7P

Vulnerability from github – Published: 2026-06-25 15:32 – Updated: 2026-06-25 15:32
VLAI
Details

ECS zero scoped answers are stored in the packet cache while they should not. This impacts only configurations that have ECS enabled;

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": [],
  "aliases": [
    "CVE-2026-40012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T14:16:38Z",
    "severity": "MODERATE"
  },
  "details": "ECS zero scoped answers are stored in the packet cache while they should not. This impacts only configurations that have ECS enabled;",
  "id": "GHSA-fmvv-f47m-6c7p",
  "modified": "2026-06-25T15:32:00Z",
  "published": "2026-06-25T15:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40012"
    },
    {
      "type": "WEB",
      "url": "https://docs.powerdns.com/recursor/security-advisories/powerdns-advisory-powerdns-2026-08.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-FWJ3-7PPR-QCV6

Vulnerability from github – Published: 2026-03-18 00:30 – Updated: 2026-03-18 00:30
VLAI
Details

IBM Planning Analytics Local 2.1.0 through 2.1.17 could allow an attacker to trick the caching mechanism into storing and serving sensitive, user-specific responses as publicly cacheable resources.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-14806"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-17T22:16:13Z",
    "severity": "MODERATE"
  },
  "details": "IBM Planning Analytics Local 2.1.0 through 2.1.17 could allow an attacker to trick the caching mechanism into storing and serving sensitive, user-specific responses as publicly cacheable resources.",
  "id": "GHSA-fwj3-7ppr-qcv6",
  "modified": "2026-03-18T00:30:54Z",
  "published": "2026-03-18T00:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14806"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7263581"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FWJF-M4QW-9F2X

Vulnerability from github – Published: 2026-08-24 20:09 – Updated: 2026-08-24 20:09
VLAI
Summary
django CMS: Page cache ignores plugin-declared Vary headers (disclosure & poisoning)
Details

Summary

The CMS page cache key ignores the request headers that plugins declare via get_vary_cache_on(). The header is added to the response Vary header, but the CMS's own cache key does not incorporate the header values, so the first visitor's variant is served to all subsequent visitors regardless of their header values.

Details

_page_cache_key (in cms/cache/page.py) keys only on cache prefix, site, language, path and timezone. set_page_cache collects the plugin-declared vary headers and calls patch_vary_headers(response, ...) (affecting only the emitted Vary header), but stores and retrieves the cached page under the header-agnostic key. get_page_cache therefore returns whichever variant was cached first.

Impact

  • Information disclosure: when a plugin varies its output on a request header (e.g. Country-Code), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users.
  • Cache poisoning: an unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors.

Applies only when CMS_PAGE_CACHE is enabled and at least one plugin implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values implements get_vary_cache_on().

Patches

Fixed in 5.0.8: the page cache now folds the request's values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django's learn_cache_key/get_cache_key); a missing header-list entry degrades to a cache miss, never a wrong-variant hit.

Workarounds

Disable CMS_PAGE_CACHE, or avoid plugins that rely on get_vary_cache_on(), until upgraded.

Credits

Reported by the security team at the University of Sydney ([@reporter]).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "django-cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54625"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349",
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-24T20:09:51Z",
    "nvd_published_at": "2026-08-20T18:16:28Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe CMS page cache key ignores the request headers that plugins declare via `get_vary_cache_on()`. The header is added to the response `Vary` header, but the CMS\u0027s own cache key does not incorporate the header values, so the first visitor\u0027s variant is served to all subsequent visitors regardless of their header values.\n\n### Details\n`_page_cache_key` (in `cms/cache/page.py`) keys only on cache prefix, site, language, path and timezone. `set_page_cache` collects the plugin-declared vary headers and calls `patch_vary_headers(response, ...)` (affecting only the emitted `Vary` header), but stores and retrieves the cached page under the header-agnostic key. `get_page_cache` therefore returns whichever variant was cached first.\n\n### Impact\n- **Information disclosure:** when a plugin varies its output on a request  header (e.g. `Country-Code`), the variant rendered for the first anonymous visitor is served to everyone until the entry expires, leaking request-specific content across users.\n- **Cache poisoning:** an unauthenticated attacker can prime the anonymous page cache with content rendered from attacker-chosen header values, which is then served to subsequent visitors.\n\nApplies only when `CMS_PAGE_CACHE` is enabled and at least one plugin implements `get_vary_cache_on()`.\n\n### Patches\nFixed in 5.0.8: the page cache now folds the request\u0027s values implements `get_vary_cache_on()`.\n\n### Patches\nFixed in 5.0.8: the page cache now folds the request\u0027s values for plugin-declared vary headers into the content key. The set of vary headers is persisted on write and looked up first on read (mirroring Django\u0027s  `learn_cache_key`/`get_cache_key`); a missing header-list entry degrades to a cache miss, never a wrong-variant hit.\n\n### Workarounds\nDisable `CMS_PAGE_CACHE`, or avoid plugins that rely on `get_vary_cache_on()`, until upgraded.\n\n### Credits\nReported by the security team at the University of Sydney ([@reporter]).",
  "id": "GHSA-fwjf-m4qw-9f2x",
  "modified": "2026-08-24T20:09:52Z",
  "published": "2026-08-24T20:09:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/django-cms/django-cms/security/advisories/GHSA-fwjf-m4qw-9f2x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54625"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django-cms/django-cms/pull/8646"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django-cms/django-cms/pull/8647"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django-cms/django-cms/commit/8758714b865ffa79c6bcd0e5c503958ea48885aa"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django-cms/django-cms/commit/d5dc1efa18d157445491c4b12c2dd1efd56f439f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/django-cms/django-cms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django-cms/django-cms/releases/tag/5.0.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django-cms/django-cms/releases/tag/5.1.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "django CMS: Page cache ignores plugin-declared Vary headers (disclosure \u0026 poisoning)"
}

GHSA-G5QG-72QW-GW5V

Vulnerability from github – Published: 2025-08-29 22:06 – Updated: 2025-09-03 13:00
VLAI
Summary
Next.js Affected by Cache Key Confusion for Image Optimization API Routes
Details

A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. When images returned from API routes vary based on request headers (such as Cookie or Authorization), these responses could be incorrectly cached and served to unauthorized users due to a cache key confusion bug.

All users are encouraged to upgrade if they use API routes to serve images that depend on request headers and have image optimization enabled.

More details at Vercel Changelog

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.9"
            },
            {
              "fixed": "14.2.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 15.4.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.0"
            },
            {
              "fixed": "15.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-57752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-29T22:06:22Z",
    "nvd_published_at": "2025-08-29T22:15:31Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. When images returned from API routes vary based on request headers (such as `Cookie` or `Authorization`), these responses could be incorrectly cached and served to unauthorized users due to a cache key confusion bug.\n\nAll users are encouraged to upgrade if they use API routes to serve images that depend on request headers and have image optimization enabled.\n\nMore details at [Vercel Changelog](https://vercel.com/changelog/cve-2025-57752)",
  "id": "GHSA-g5qg-72qw-gw5v",
  "modified": "2025-09-03T13:00:52Z",
  "published": "2025-08-29T22:06:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-g5qg-72qw-gw5v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57752"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/pull/82114"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/6b12c60c61ee80cb0443ccd20de82ca9b4422ddd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/next.js"
    },
    {
      "type": "WEB",
      "url": "https://vercel.com/changelog/cve-2025-57752"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Next.js Affected by Cache Key Confusion for Image Optimization API Routes"
}

GHSA-GV2Q-MQQV-365M

Vulnerability from github – Published: 2026-06-15 16:44 – Updated: 2026-07-15 22:05
VLAI
Summary
Angular Service Worker Policy-Bypass & Credential-Stripping Vulnerabilities
Details

An issue in the @angular/service-worker package compromises the integrity of request-policy enforcement during request reconstruction. When the Angular Service Worker intercepts network requests for matched assets, it reconstructs a new Request object using an internal helper function.

During this reconstruction process, the helper function strips the strict, client-defined request redirect policy configuration (such as redirect: 'error'), falling back to the browser's default 'follow' strategy.

If the target web application makes client-side requests with a strict policy (e.g., expecting a network error instead of automatically following redirects), the service worker will bypass this instruction and automatically follow HTTP 3xx redirects to other destinations. This acts as an unintended proxy/intermediary ("Confused Deputy") and can result in cookie/credential exposure or same-origin session-restricted data leakage if public dynamic routes redirect to sensitive routes.

Impact

Web applications registering the @angular/service-worker package are vulnerable to this redirect-policy bypass if they make safe client-side fetch calls (such as { redirect: 'error' }) to paths matched by a service worker asset group (such as lazy-loaded JavaScript bundles or dynamic public assets) that can return HTTP redirects to authenticated same-origin secure endpoints.

By stripping developer-defined safety boundaries, the service worker allows the browser to transparently query and return data from credentials-guarded resources that should have been blocked at the network barrier.

Attack Preconditions

To successfully exploit this vulnerability, all of the following application states and parameters must concurrently exist: 1. Active Angular Service Worker: The target application uses @angular/service-worker and has an active registration of ngsw-worker.js inside the client's browser context. 2. Asset Group Matching: An assetGroups pattern in ngsw-config.json encompasses the target dynamic routing endpoint. 3. Same-Origin Dynamic Redirection: The server routes a public matched asset route to a service that returns an HTTP 3xx redirect pointing to a sensitive, session-restricted same-origin private route (e.g., /private/account-summary.json). 4. Established User Session: The victim user currently has an active authentication state, such as valid same-origin session cookies or auth headers stored by the browser. 5. Client-Side Safe Fetch Call: The application initiates an explicit fetch request to the route with safety parameters: { redirect: 'error' }.

Mitigations & Workarounds

If upgrading the @angular/service-worker package is not immediately feasible, developers should implement the following defensive measures: * Avoid Public-to-Private Dynamic Redirection: Refactor the server architecture so that public paths matched by service worker asset groups never issue HTTP 3xx redirects to authenticated same-origin secure endpoints. * Strict Cookie Configuration: Apply strict flags to session cookies (SameSite=Strict; Secure; HttpOnly) and consider explicit route isolations (such as subdomains) for credential-guarded private resources. * Exclude Secure Endpoints from SW Config: Verify your ngsw-config.json settings and ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes.

Patches

  • 22.0.0-rc.2
  • 21.2.15
  • 20.3.22
  • 19.2.23
Severity
6.1 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
5.7 (Medium)
CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/service-worker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0-next.0"
            },
            {
              "fixed": "22.0.0-rc.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/service-worker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "20.0.0-next.0"
            },
            {
              "fixed": "20.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/service-worker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0-next.0"
            },
            {
              "fixed": "19.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/service-worker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "18.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/service-worker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "21.0.0-next.0"
            },
            {
              "fixed": "21.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50169"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-441",
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T16:44:21Z",
    "nvd_published_at": "2026-06-22T18:16:42Z",
    "severity": "MODERATE"
  },
  "details": "An issue in the `@angular/service-worker` package compromises the integrity of request-policy enforcement during request reconstruction. When the Angular Service Worker intercepts network requests for matched assets, it reconstructs a new `Request` object using an internal helper function. \n\nDuring this reconstruction process, the helper function strips the strict, client-defined request redirect policy configuration (such as `redirect: \u0027error\u0027`), falling back to the browser\u0027s default `\u0027follow\u0027` strategy.\n\nIf the target web application makes client-side requests with a strict policy (e.g., expecting a network error instead of automatically following redirects), the service worker will bypass this instruction and automatically follow HTTP 3xx redirects to other destinations. This acts as an unintended proxy/intermediary (\"Confused Deputy\") and can result in cookie/credential exposure or same-origin session-restricted data leakage if public dynamic routes redirect to sensitive routes.\n\n### Impact\nWeb applications registering the `@angular/service-worker` package are vulnerable to this redirect-policy bypass if they make safe client-side fetch calls (such as `{ redirect: \u0027error\u0027 }`) to paths matched by a service worker asset group (such as lazy-loaded JavaScript bundles or dynamic public assets) that can return HTTP redirects to authenticated same-origin secure endpoints. \n\nBy stripping developer-defined safety boundaries, the service worker allows the browser to transparently query and return data from credentials-guarded resources that should have been blocked at the network barrier.\n\n### Attack Preconditions\nTo successfully exploit this vulnerability, all of the following application states and parameters must concurrently exist:\n1. **Active Angular Service Worker:** The target application uses `@angular/service-worker` and has an active registration of `ngsw-worker.js` inside the client\u0027s browser context.\n2. **Asset Group Matching:** An `assetGroups` pattern in `ngsw-config.json` encompasses the target dynamic routing endpoint.\n3. **Same-Origin Dynamic Redirection:** The server routes a public matched asset route to a service that returns an HTTP 3xx redirect pointing to a sensitive, session-restricted same-origin private route (e.g., `/private/account-summary.json`).\n4. **Established User Session:** The victim user currently has an active authentication state, such as valid same-origin session cookies or auth headers stored by the browser.\n5. **Client-Side Safe Fetch Call:** The application initiates an explicit fetch request to the route with safety parameters: `{ redirect: \u0027error\u0027 }`.\n\n### Mitigations \u0026 Workarounds\nIf upgrading the `@angular/service-worker` package is not immediately feasible, developers should implement the following defensive measures:\n* **Avoid Public-to-Private Dynamic Redirection:** Refactor the server architecture so that public paths matched by service worker asset groups never issue HTTP 3xx redirects to authenticated same-origin secure endpoints.\n* **Strict Cookie Configuration:** Apply strict flags to session cookies (`SameSite=Strict; Secure; HttpOnly`) and consider explicit route isolations (such as subdomains) for credential-guarded private resources.\n* **Exclude Secure Endpoints from SW Config:** Verify your `ngsw-config.json` settings and ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes.\n\n### Patches\n- 22.0.0-rc.2\n- 21.2.15\n- 20.3.22\n- 19.2.23",
  "id": "GHSA-gv2q-mqqv-365m",
  "modified": "2026-07-15T22:05:03Z",
  "published": "2026-06-15T16:44:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/security/advisories/GHSA-gv2q-mqqv-365m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50169"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/pull/67494"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/angular/angular"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Angular Service Worker Policy-Bypass \u0026 Credential-Stripping Vulnerabilities"
}

GHSA-HVXF-R5RG-WQF7

Vulnerability from github – Published: 2025-05-01 00:32 – Updated: 2025-05-01 00:32
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-2023-37517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-30T22:15:15Z",
    "severity": "LOW"
  },
  "details": "Missing \"no cache\" headers in HCL Leap permits sensitive data to be cached.",
  "id": "GHSA-hvxf-r5rg-wqf7",
  "modified": "2025-05-01T00:32:29Z",
  "published": "2025-05-01T00:32:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37517"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0120722"
    }
  ],
  "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