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-P77J-G7H5-R2VW

Vulnerability from github – Published: 2026-08-19 19:22 – Updated: 2026-08-19 19:23
VLAI
Summary
GeoLens's authorization and cache-scope flaws disclose private dataset data and metadata to unauthorized users (fixed in 1.2.4)
Details

GeoLens 1.2.4 fixes a set of vulnerabilities, the most serious of which allow authenticated or anonymous users to obtain data and metadata for datasets they are not authorized to access.

Impact

  • Private record metadata disclosure. Record contact, keyword, and distribution sub-resource endpoints did not re-authorize the backing dataset, so any authenticated user could read a private record's contact details (PII), keywords, and distributions. (Runtime-proven.)
  • Private tile data via shared caches. Private raster and vector tiles were served with shared-cache (Cache-Control: public) headers, so a shared cache (a CDN or the bundled reverse proxy) could retain private tile bytes and replay them to later unauthenticated requests, including unpublished public-dataset previews.
  • Private dataset title enumeration. The map visibility-check endpoint did not authorize read access to the map, allowing any editor to enumerate the titles of non-public datasets in any map by ID — including private maps owned by other users.
  • SSRF via DNS rebinding. URL validation for user-supplied service URLs (probes, STAC/OGC API sources, manifest downloads) resolved DNS once and then let the HTTP client re-resolve at connect time, allowing a low-TTL domain to pass validation as a public address and connect to an internal/metadata address.
  • Token leak + header injection in service preview. The remote-service preview path passed the authorization token to GDAL via the process environment without sanitization, leaking it through /proc/<pid>/environ and allowing CRLF header injection.
  • Unauthenticated STAC search DoS. POST /search did not cap the size of GeoJSON intersects geometries (the GET sibling did).
  • API key written to access logs. The bundled reverse proxy logged the api_key query-string credential in cleartext.
  • Security posture coupled to a logging flag. API documentation exposure and the Secure flag on the OAuth session cookie were keyed off the LOG_JSON logging flag rather than an explicit environment setting, so a production deployment at the default could expose /docs and emit a non-Secure session cookie.
  • Missing Content-Security-Policy (defense-in-depth). The web application shipped no script-src/default-src CSP, leaving no containment for token exfiltration if an XSS issue were introduced.
  • Weak default install credentials. The installer kept the published default database password and could silently retain the default admin password on a headless install.

Patches

Upgrade to GeoLens 1.2.4. No configuration changes are required for the authorization and cache fixes. Operators on a public, TLS-terminated deployment should additionally set ENVIRONMENT=production to make the production security posture explicit; deployments that do not set it retain their prior behavior.

Workarounds

None for the authorization/cache disclosure flaws — upgrading is required. The SSRF and STAC-DoS surfaces can be partially mitigated at the network/proxy layer (egress filtering to block link-local metadata addresses; a request-size limit on POST /search), but the code fix is the durable remedy.

References

  • Release: https://github.com/geolens-io/geolens/releases/tag/v1.2.4
  • Pull request: https://github.com/geolens-io/geolens/pull/243
  • Prior related advisory: GHSA-p23g-mvhj-jh3j
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "geolens"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1021",
      "CWE-1392",
      "CWE-200",
      "CWE-285",
      "CWE-400",
      "CWE-524",
      "CWE-532",
      "CWE-918",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-19T19:22:59Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "GeoLens 1.2.4 fixes a set of vulnerabilities, the most serious of which allow authenticated or anonymous users to obtain data and metadata for datasets they are not authorized to access.\n\n### Impact\n\n- **Private record metadata disclosure.** Record contact, keyword, and distribution sub-resource endpoints did not re-authorize the backing dataset, so any authenticated user could read a private record\u0027s contact details (PII), keywords, and distributions. (Runtime-proven.)\n- **Private tile data via shared caches.** Private raster and vector tiles were served with shared-cache (`Cache-Control: public`) headers, so a shared cache (a CDN or the bundled reverse proxy) could retain private tile bytes and replay them to later unauthenticated requests, including unpublished public-dataset previews.\n- **Private dataset title enumeration.** The map visibility-check endpoint did not authorize read access to the map, allowing any editor to enumerate the titles of non-public datasets in any map by ID \u2014 including private maps owned by other users.\n- **SSRF via DNS rebinding.** URL validation for user-supplied service URLs (probes, STAC/OGC API sources, manifest downloads) resolved DNS once and then let the HTTP client re-resolve at connect time, allowing a low-TTL domain to pass validation as a public address and connect to an internal/metadata address.\n- **Token leak + header injection in service preview.** The remote-service preview path passed the authorization token to GDAL via the process environment without sanitization, leaking it through `/proc/\u003cpid\u003e/environ` and allowing CRLF header injection.\n- **Unauthenticated STAC search DoS.** `POST /search` did not cap the size of GeoJSON `intersects` geometries (the `GET` sibling did).\n- **API key written to access logs.** The bundled reverse proxy logged the `api_key` query-string credential in cleartext.\n- **Security posture coupled to a logging flag.** API documentation exposure and the Secure flag on the OAuth session cookie were keyed off the `LOG_JSON` logging flag rather than an explicit environment setting, so a production deployment at the default could expose `/docs` and emit a non-Secure session cookie.\n- **Missing Content-Security-Policy (defense-in-depth).** The web application shipped no `script-src`/`default-src` CSP, leaving no containment for token exfiltration if an XSS issue were introduced.\n- **Weak default install credentials.** The installer kept the published default database password and could silently retain the default admin password on a headless install.\n\n### Patches\n\nUpgrade to **GeoLens 1.2.4**. No configuration changes are required for the authorization and cache fixes. Operators on a public, TLS-terminated deployment should additionally set `ENVIRONMENT=production` to make the production security posture explicit; deployments that do not set it retain their prior behavior.\n\n### Workarounds\n\nNone for the authorization/cache disclosure flaws \u2014 upgrading is required. The SSRF and STAC-DoS surfaces can be partially mitigated at the network/proxy layer (egress filtering to block link-local metadata addresses; a request-size limit on `POST /search`), but the code fix is the durable remedy.\n\n### References\n\n- Release: https://github.com/geolens-io/geolens/releases/tag/v1.2.4\n- Pull request: https://github.com/geolens-io/geolens/pull/243\n- Prior related advisory: GHSA-p23g-mvhj-jh3j",
  "id": "GHSA-p77j-g7h5-r2vw",
  "modified": "2026-08-19T19:23:00Z",
  "published": "2026-08-19T19:22:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/geolens-io/geolens/security/advisories/GHSA-p77j-g7h5-r2vw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geolens-io/geolens/pull/243"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-p23g-mvhj-jh3j"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/geolens-io/geolens"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geolens-io/geolens/releases/tag/v1.2.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "GeoLens\u0027s authorization and cache-scope flaws disclose private dataset data and metadata to unauthorized users (fixed in 1.2.4)"
}

GHSA-P77W-8QQV-26RM

Vulnerability from github – Published: 2026-05-09 00:28 – Updated: 2026-05-14 20:35
VLAI
Summary
Hono's Cache Middleware ignores Vary: Authorization / Vary: Cookie leading to cross-user cache leakage
Details

Summary

Cache Middleware does not skip caching for responses that declare per-user variance via Vary: Authorization or Vary: Cookie. As a result, a response cached for one authenticated user may be served to subsequent requests from different users.

Details

The Cache Middleware skips caching when a response carries Vary: *, certain Cache-Control directives (private, no-store, no-cache), or Set-Cookie. However, Vary: Authorization and Vary: Cookie — the standard signals defined in RFC 9110 / RFC 9111 to indicate per-user responses — are not treated as cache-skip reasons.

This issue arises when applications use the Cache Middleware on endpoints that return user-specific data and rely on Vary: Authorization or Vary: Cookie to scope the response per user, without also setting Cache-Control: private.

Impact

A user may receive a cached response that was originally generated for a different authenticated user. This may lead to:

  • Disclosure of personally identifiable information or other user-specific data present in the response body
  • Inconsistent or incorrect behavior in user-specific endpoints

This issue affects applications that use the Cache Middleware on endpoints whose responses vary by Authorization or Cookie and that do not also set Cache-Control: private.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "hono"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.12.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44457"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-09T00:28:46Z",
    "nvd_published_at": "2026-05-13T16:16:57Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nCache Middleware does not skip caching for responses that declare per-user variance via `Vary: Authorization` or `Vary: Cookie`. As a result, a response cached for one authenticated user may be served to subsequent requests from different users.\n\n### Details\n\nThe Cache Middleware skips caching when a response carries `Vary: *`, certain `Cache-Control` directives (`private`, `no-store`, `no-cache`), or `Set-Cookie`. However, `Vary: Authorization` and `Vary: Cookie` \u2014 the standard signals defined in RFC 9110 / RFC 9111 to indicate per-user responses \u2014 are not treated as cache-skip reasons.\n\nThis issue arises when applications use the Cache Middleware on endpoints that return user-specific data and rely on `Vary: Authorization` or `Vary: Cookie` to scope the response per user, without also setting `Cache-Control: private`.\n\n### Impact\n\nA user may receive a cached response that was originally generated for a different authenticated user. This may lead to:\n\n- Disclosure of personally identifiable information or other user-specific data present in the response body\n- Inconsistent or incorrect behavior in user-specific endpoints\n\nThis issue affects applications that use the Cache Middleware on endpoints whose responses vary by `Authorization` or `Cookie` and that do not also set `Cache-Control: private`.",
  "id": "GHSA-p77w-8qqv-26rm",
  "modified": "2026-05-14T20:35:40Z",
  "published": "2026-05-09T00:28:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/security/advisories/GHSA-p77w-8qqv-26rm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44457"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/honojs/hono"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Hono\u0027s Cache Middleware ignores Vary: Authorization / Vary: Cookie leading to cross-user cache leakage"
}

GHSA-P8PF-44FF-93GF

Vulnerability from github – Published: 2025-11-20 21:29 – Updated: 2025-11-21 15:32
VLAI
Summary
authkit-nextjs may let session cookies be cached in CDNs
Details

In authkit-nextjs version 2.11.0 and below, authenticated responses do not defensively apply anti-caching headers. In environments where CDN caching is enabled, this can result in session tokens being included in cached responses and subsequently served to multiple users.

Next.js applications deployed on Vercel are unaffected unless they manually enable CDN caching by setting cache headers on authenticated paths.

Impact

This vulnerability may lead to session caching, potentially allowing unauthorized users to obtain another user’s session token. The severity depends on deployment configuration, caching policy, and whether authenticated routes are inadvertently cached.

Patches

Patched in authkit-nextjs 2.11.1, which applies anti-caching headers to all responses behind authentication.

Notes

Authentication middleware should set anti-caching headers for authenticated routes as a defense in depth measure, but cannot guarantee these headers will not be overwritten elsewhere in the application. We recommend the following: - Review your application code, middleware, and infrastructure configuration to ensure the Cache-Control headers set for authenticated paths prevent inappropriate caching - For application paths that require caching, do not allow user-specific or sensitive authenticated information to be included in the response data or headers

Severity
8.0 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.11.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@workos-inc/authkit-nextjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64762"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-20T21:29:16Z",
    "nvd_published_at": "2025-11-21T02:15:44Z",
    "severity": "HIGH"
  },
  "details": "In `authkit-nextjs` version 2.11.0 and below, authenticated responses do not defensively apply anti-caching headers. In environments where CDN caching is enabled, this can result in session tokens being included in cached responses and subsequently served to multiple users.\n\nNext.js applications deployed on Vercel are unaffected **unless** they manually enable CDN caching by setting cache headers on authenticated paths.\n\n### Impact\nThis vulnerability may lead to session caching, potentially allowing unauthorized users to obtain another user\u2019s session token. The severity depends on deployment configuration, caching policy, and whether authenticated routes are inadvertently cached.\n\n### Patches\nPatched in `authkit-nextjs` 2.11.1, which applies anti-caching headers to all responses behind authentication.\n\n### Notes\nAuthentication middleware should set anti-caching headers for authenticated routes as a defense in depth measure, but cannot guarantee these headers will not be overwritten elsewhere in the application. We recommend the following:\n  - Review your application code, middleware, and infrastructure configuration to ensure the Cache-Control headers set for authenticated paths prevent inappropriate caching\n  - For application paths that require caching, do not allow user-specific or sensitive authenticated information to be included in the response data or headers",
  "id": "GHSA-p8pf-44ff-93gf",
  "modified": "2025-11-21T15:32:21Z",
  "published": "2025-11-20T21:29:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/workos/authkit-nextjs/security/advisories/GHSA-p8pf-44ff-93gf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64762"
    },
    {
      "type": "WEB",
      "url": "https://github.com/workos/authkit-nextjs/commit/94cf438124993abb0e7c19dac64c3cb5724a15ea"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/workos/authkit-nextjs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/workos/authkit-nextjs/releases/tag/v2.11.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "authkit-nextjs may let session cookies be cached in CDNs"
}

GHSA-PHF8-W34Q-995J

Vulnerability from github – Published: 2026-05-26 18:31 – Updated: 2026-05-28 15:39
VLAI
Details

The InputFilter::getInstance() method omitted a security sensitive parameter from the instance cache key.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-48901"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-26T17:16:54Z",
    "severity": "HIGH"
  },
  "details": "The InputFilter::getInstance() method omitted a security sensitive parameter from the instance cache key.",
  "id": "GHSA-phf8-w34q-995j",
  "modified": "2026-05-28T15:39:41Z",
  "published": "2026-05-26T18:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48901"
    },
    {
      "type": "WEB",
      "url": "https://developer.joomla.org/security-centre/1049-20260517-core-incorrect-cache-key-construction-for-inputfilter-objects.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PJHX-3C3W-9V23

Vulnerability from github – Published: 2026-07-10 14:32 – Updated: 2026-07-10 14:32
VLAI
Summary
API Platform Core vulnerable to cross-user attribute leak in JSON:API and HAL item normalizers due to missing isCacheKeySafe gate
Details

Impact

#[ApiProperty(security: ...)] is evaluated per request to decide whether a property is exposed. The componentsCache arrays in ApiPlatform\JsonApi\Serializer\ItemNormalizer and ApiPlatform\Hal\Serializer\ItemNormalizer are keyed on $context['cache_key'], which is set unconditionally before delegating to the parent normalizer. The component structure (attributes, relationships, links) computed for one request can therefore be reused for a subsequent request whose user has a different set of accessible properties. A user with lower privileges may end up seeing the structure of properties that the security predicate would otherwise have hidden for them.

This is the same vulnerability class as GHSA-428q-q3vv-3fq3 / CVE-2025-31485, which fixed only the GraphQL ItemNormalizer. The JSON:API and HAL paths were not addressed at the time.

Exploitation conditions

Exploitation requires all of the following to coincide:

  • The application exposes a resource via the JSON:API and/or HAL formats.
  • At least one property of that resource uses #[ApiProperty(security: ...)] with a predicate whose result depends on the current user (or on per-request state).
  • A request from a user for whom the predicate evaluates to true populates componentsCache before a request from a user for whom the predicate evaluates to false, within the lifetime of the same PHP process.
  • The deployment uses a long-running PHP runtime that keeps the normalizer instance alive across requests (FrankenPHP worker mode, RoadRunner, Swoole, ReactPHP, etc.). With classic php-fpm workers the cache only survives the duration of a single request, which makes the issue much harder to observe in practice.

Patches

  • 4.1.29
  • 4.2.25
  • 4.3.8

All three branches receive patched releases of api-platform/core, api-platform/json-api, and api-platform/hal.

Workarounds

Override the JSON:API and HAL ItemNormalizer services to gate $context['cache_key'] with a resource-class security check, or avoid #[ApiProperty(security: ...)] on resources served as JSON:API or HAL until the patch is applied. Pinning the deployment to classic php-fpm workers also limits exposure since the cache does not survive across requests.

Credits

  • Tillmann Baumgart (@tillmon) — originally identified the broader cache-key gap and proposed moving isCacheKeySafe to AbstractItemNormalizer.
  • Antoine Bluchet (@soyuka) — extended the gate to JSON:API and HAL normalizers.
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "4.1.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/json-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/json-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/json-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/hal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/hal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "api-platform/hal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T14:32:01Z",
    "nvd_published_at": "2026-07-01T20:17:10Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`#[ApiProperty(security: ...)]` is evaluated per request to decide whether a property is exposed. The `componentsCache` arrays in `ApiPlatform\\JsonApi\\Serializer\\ItemNormalizer` and `ApiPlatform\\Hal\\Serializer\\ItemNormalizer` are keyed on `$context[\u0027cache_key\u0027]`, which is set unconditionally before delegating to the parent normalizer. The component structure (attributes, relationships, links) computed for one request can therefore be reused for a subsequent request whose user has a different set of accessible properties. A user with lower privileges may end up seeing the structure of properties that the security predicate would otherwise have hidden for them.\n\nThis is the same vulnerability class as [GHSA-428q-q3vv-3fq3](https://github.com/api-platform/core/security/advisories/GHSA-428q-q3vv-3fq3) / CVE-2025-31485, which fixed only the GraphQL `ItemNormalizer`. The JSON:API and HAL paths were not addressed at the time.\n\n### Exploitation conditions\n\nExploitation requires all of the following to coincide:\n\n- The application exposes a resource via the JSON:API and/or HAL formats.\n- At least one property of that resource uses `#[ApiProperty(security: ...)]` with a predicate whose result depends on the current user (or on per-request state).\n- A request from a user for whom the predicate evaluates to `true` populates `componentsCache` before a request from a user for whom the predicate evaluates to `false`, within the lifetime of the same PHP process.\n- The deployment uses a long-running PHP runtime that keeps the normalizer instance alive across requests (FrankenPHP worker mode, RoadRunner, Swoole, ReactPHP, etc.). With classic `php-fpm` workers the cache only survives the duration of a single request, which makes the issue much harder to observe in practice.\n\n### Patches\n\n- 4.1.29\n- 4.2.25\n- 4.3.8\n\nAll three branches receive patched releases of `api-platform/core`, `api-platform/json-api`, and `api-platform/hal`.\n\n### Workarounds\n\nOverride the JSON:API and HAL `ItemNormalizer` services to gate `$context[\u0027cache_key\u0027]` with a resource-class security check, or avoid `#[ApiProperty(security: ...)]` on resources served as JSON:API or HAL until the patch is applied. Pinning the deployment to classic `php-fpm` workers also limits exposure since the cache does not survive across requests.\n\n### Credits\n\n- Tillmann Baumgart (@tillmon) \u2014 originally identified the broader cache-key gap and proposed moving `isCacheKeySafe` to `AbstractItemNormalizer`.\n- Antoine Bluchet (@soyuka) \u2014 extended the gate to JSON:API and HAL normalizers.",
  "id": "GHSA-pjhx-3c3w-9v23",
  "modified": "2026-07-10T14:32:01Z",
  "published": "2026-07-10T14:32:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/api-platform/core/security/advisories/GHSA-pjhx-3c3w-9v23"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49858"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/api-platform/core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "API Platform Core vulnerable to cross-user attribute leak in JSON:API and HAL item normalizers due to missing isCacheKeySafe gate"
}

GHSA-PP8H-HGQ9-WFRJ

Vulnerability from github – Published: 2025-02-18 06:35 – Updated: 2025-02-18 06:35
VLAI
Details

The Rapid Cache plugin for WordPress is vulnerable to Cache Poisoning in all versions up to, and including, 1.2.3. This is due to plugin storing HTTP headers in the cached data. This makes it possible for unauthenticated attackers to poison the cache with custom HTTP headers that may be unsanitized which can lead to Cross-Site Scripting.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-12314"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-18T05:15:09Z",
    "severity": "HIGH"
  },
  "details": "The Rapid Cache plugin for WordPress is vulnerable to Cache Poisoning in all versions up to, and including, 1.2.3. This is due to plugin storing HTTP headers in the cached data. This makes it possible for unauthenticated attackers to poison the cache with custom HTTP headers that may be unsanitized which can lead to Cross-Site Scripting.",
  "id": "GHSA-pp8h-hgq9-wfrj",
  "modified": "2025-02-18T06:35:38Z",
  "published": "2025-02-18T06:35:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12314"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/rapid-cache"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/72b777ac-1870-4588-82fe-da96a784ec81?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PR7R-676H-XCF6

Vulnerability from github – Published: 2026-06-18 14:28 – Updated: 2026-06-18 14:28
VLAI
Summary
undici vulnerable to cross-user information disclosure via shared cache whitespace bypass
Details

Impact

Undici's cache interceptor incorrectly classifies some responses as cacheable when the upstream Cache-Control header uses whitespace-padded qualified private or no-cache field names such as private=" authorization" or no-cache="\tauthorization". The parser preserves the surrounding whitespace, so later comparisons against the literal authorization field name fail and the response is stored.

In shared-cache mode, this allows a response containing one user's authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key.

Affected applications are those that explicitly enable the cache interceptor (interceptors.cache()) in shared mode, forward Authorization headers upstream, and receive cacheable responses with non-canonical qualified private or no-cache directives.

Patches

Upgrade to undici v7.28.0 or v8.5.0.

Workarounds

If upgrade is not immediately possible, disable shared-cache mode for traffic that includes Authorization headers, avoid caching responses to authenticated requests, or add Vary: Authorization upstream.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "undici"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.28.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "undici"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-9678"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:28:13Z",
    "nvd_published_at": "2026-06-17T18:18:06Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nUndici\u0027s cache interceptor incorrectly classifies some responses as cacheable when the upstream `Cache-Control` header uses whitespace-padded qualified `private` or `no-cache` field names such as `private=\" authorization\"` or `no-cache=\"\\tauthorization\"`. The parser preserves the surrounding whitespace, so later comparisons against the literal `authorization` field name fail and the response is stored.\n\nIn shared-cache mode, this allows a response containing one user\u0027s authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key.\n\nAffected applications are those that explicitly enable the cache interceptor (`interceptors.cache()`) in shared mode, forward `Authorization` headers upstream, and receive cacheable responses with non-canonical qualified `private` or `no-cache` directives.\n\n## Patches\n\nUpgrade to undici v7.28.0 or v8.5.0.\n\n## Workarounds\n\nIf upgrade is not immediately possible, disable shared-cache mode for traffic that includes `Authorization` headers, avoid caching responses to authenticated requests, or add `Vary: Authorization` upstream.",
  "id": "GHSA-pr7r-676h-xcf6",
  "modified": "2026-06-18T14:28:13Z",
  "published": "2026-06-18T14:28:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/security/advisories/GHSA-pr7r-676h-xcf6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9678"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodejs/undici"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "undici vulnerable to cross-user information disclosure via shared cache whitespace bypass"
}

GHSA-Q6F4-QQRG-JV6X

Vulnerability from github – Published: 2026-06-15 16:51 – Updated: 2026-07-15 22:05
VLAI
Summary
@angular/common: Information Leak via Default Caching of Credentialed Requests in HttpTransferCache
Details

A vulnerability was discovered in @angular/common when Server-Side Rendering (SSR) and hydration are enabled. The HttpTransferCache utility optimizes hydration by caching outgoing HTTP requests performed during SSR and transferring the cached state to the client-side application via TransferState.

However, the caching mechanism fails to inspect the withCredentials flag or the Cookie header of outgoing requests. As a result, credentialed, user-specific responses may be cached by default in the shared TransferState payload. When these responses are serialized into the HTML, any caching layer (such as a CDN, reverse proxy, or shared server cache) that caches the SSR-rendered HTML page could inadvertently cache and leak one user's private data to other users, leading to a high-severity information disclosure vulnerability.

Impact

Successful exploitation allows an unauthenticated attacker to obtain sensitive, user-specific information of other authenticated users. This occurs when:

  • The SSR-rendered HTML containing the cached private data is stored in a shared cache (e.g., CDN, reverse proxy).
  • Subsequent requests for the same page receive the cached HTML containing the first user's private data.

Attack Preconditions

  • SSR and Hydration Enabled: The Angular application must be configured to use Server-Side Rendering and hydration (e.g., using provideClientHydration()).
  • Credentialed Requests during SSR: The application must perform HTTP requests that require user-specific authentication (using cookies or withCredentials: true) during the initial server-side render.
  • Shared Caching: The application's HTML responses must be cached by a shared caching layer (CDN, reverse proxy, or server-side cache) without proper cache-control headers to distinguish authenticated users.

Patches

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0-next.0"
            },
            {
              "fixed": "22.0.0-rc.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "20.0.0-next.0"
            },
            {
              "fixed": "20.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0-next.0"
            },
            {
              "fixed": "19.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "18.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "21.0.0-next.0"
            },
            {
              "fixed": "21.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50170"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T16:51:53Z",
    "nvd_published_at": "2026-06-22T18:16:42Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was discovered in `@angular/common` when Server-Side Rendering (SSR) and hydration are enabled. The `HttpTransferCache` utility optimizes hydration by caching outgoing HTTP requests performed during SSR and transferring the cached state to the client-side application via `TransferState`.\n\nHowever, the caching mechanism fails to inspect the `withCredentials` flag or the `Cookie` header of outgoing requests. As a result, credentialed, user-specific responses may be cached by default in the shared `TransferState` payload. When these responses are serialized into the HTML, any caching layer (such as a CDN, reverse proxy, or shared server cache) that caches the SSR-rendered HTML page could inadvertently cache and leak one user\u0027s private data to other users, leading to a high-severity information disclosure vulnerability.\n\n### Impact\n\nSuccessful exploitation allows an unauthenticated attacker to obtain sensitive, user-specific information of other authenticated users. This occurs when:\n\n* The SSR-rendered HTML containing the cached private data is stored in a shared cache (e.g., CDN, reverse proxy).  \n* Subsequent requests for the same page receive the cached HTML containing the first user\u0027s private data.\n\n### Attack Preconditions\n\n* **SSR and Hydration Enabled:** The Angular application must be configured to use Server-Side Rendering and hydration (e.g., using `provideClientHydration()`).  \n* **Credentialed Requests during SSR:** The application must perform HTTP requests that require user-specific authentication (using cookies or `withCredentials: true`) during the initial server-side render.  \n* **Shared Caching:** The application\u0027s HTML responses must be cached by a shared caching layer (CDN, reverse proxy, or server-side cache) without proper cache-control headers to distinguish authenticated users.\n\n### Patches\n- 22.0.0-rc.2\n- 21.2.15\n- 20.3.22\n- 19.2.23",
  "id": "GHSA-q6f4-qqrg-jv6x",
  "modified": "2026-07-15T22:05:10Z",
  "published": "2026-06-15T16:51:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/security/advisories/GHSA-q6f4-qqrg-jv6x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50170"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/pull/67964"
    },
    {
      "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:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@angular/common: Information Leak via Default Caching of Credentialed Requests in HttpTransferCache"
}

GHSA-QPC8-7FXC-CM4P

Vulnerability from github – Published: 2026-06-03 15:30 – Updated: 2026-08-07 19:55
VLAI
Summary
Django: UpdateCacheMiddleware may disclose private cached responses by omitting Authorization from Vary
Details

An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6. django.middleware.cache.UpdateCacheMiddleware in Django does not add Authorization to the Vary response header for requests bearing that header without Cache-Control: public, which allows remote attackers to read private cached responses via unauthenticated requests to the same URL. 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 Shai Berger 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": "5.2.0"
            },
            {
              "fixed": "5.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-07T19:55:18Z",
    "nvd_published_at": "2026-06-03T14:16:41Z",
    "severity": "LOW"
  },
  "details": "An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6.\n`django.middleware.cache.UpdateCacheMiddleware` in Django does not add `Authorization` to the `Vary` response header for requests bearing that header without `Cache-Control: public`, which allows remote attackers to read private cached responses via unauthenticated requests to the same URL.\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 Shai Berger for reporting this issue.",
  "id": "GHSA-qpc8-7fxc-cm4p",
  "modified": "2026-08-07T19:55:18Z",
  "published": "2026-06-03T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35193"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/050a3dc276f9142067260e990e4d8d42d5e32863"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/664652f1a2dd80d8a4cd491b4313cad915ae6669"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/a2faa8e895926ac5d63f72879b5ccf671b5b4ba9"
    },
    {
      "type": "WEB",
      "url": "https://docs.djangoproject.com/en/dev/releases/security"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2026-197.yaml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/django-announce"
    },
    {
      "type": "WEB",
      "url": "https://www.djangoproject.com/weblog/2026/jun/03/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: UpdateCacheMiddleware may disclose private cached responses by omitting Authorization from Vary"
}

GHSA-R77M-QPX3-MPGM

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 user directory information 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-37516"
  ],
  "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 user directory information to be cached.",
  "id": "GHSA-r77m-qpx3-mpgm",
  "modified": "2025-04-24T21:31:47Z",
  "published": "2025-04-24T21:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37516"
    },
    {
      "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