CWE-524
AllowedUse of Cache Containing Sensitive Information
Abstraction: Base · Status: Incomplete
The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.
115 vulnerabilities reference this CWE, most recent first.
GHSA-JR45-8VMC-QM54
Vulnerability from github – Published: 2026-08-03 19:32 – Updated: 2026-08-03 19:32Impact
Undici's cache interceptor mishandles optional whitespace (OWS) placed around the = of a qualified no-cache or private Cache-Control directive, such as no-cache ="authorization" (OWS before =) or no-cache= "authorization" (OWS after =). The parser either drops the directive entirely or stores a field name with literal quote characters, so the downstream cache decisions do not recognize the qualification 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. The impact class is identical to CVE-2026-9678 (GHSA-pr7r-676h-xcf6); this advisory covers the whitespace-around-= bypass that the earlier fix did not normalize.
Affected applications are those that explicitly enable the cache interceptor (interceptors.cache()) in shared mode, forward Authorization headers upstream, and receive cacheable responses with qualified private or no-cache directives whose field-name list is padded with OWS around the =.
Patches
Upgrade to undici v7.29.0 or v8.9.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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.29.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-14643"
],
"database_specific": {
"cwe_ids": [
"CWE-436",
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-03T19:32:12Z",
"nvd_published_at": "2026-07-29T22:16:52Z",
"severity": "MODERATE"
},
"details": "## Impact\n\nUndici\u0027s cache interceptor mishandles optional whitespace (OWS) placed around the `=` of a qualified `no-cache` or `private` Cache-Control directive, such as `no-cache =\"authorization\"` (OWS before `=`) or `no-cache= \"authorization\"` (OWS after `=`). The parser either drops the directive entirely or stores a field name with literal quote characters, so the downstream cache decisions do not recognize the qualification 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. The impact class is identical to CVE-2026-9678 (GHSA-pr7r-676h-xcf6); this advisory covers the whitespace-around-`=` bypass that the earlier fix did not normalize.\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 qualified `private` or `no-cache` directives whose field-name list is padded with OWS around the `=`.\n\n## Patches\n\nUpgrade to undici v7.29.0 or v8.9.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-jr45-8vmc-qm54",
"modified": "2026-08-03T19:32:12Z",
"published": "2026-08-03T19:32:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-jr45-8vmc-qm54"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14643"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/commit/85a240551c9feb8b8a0ecc56c84b2b3015add8a9"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/commit/cb105d7c79069150982fa11acada0dd94a60dbbc"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodejs/undici"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/releases/tag/v7.29.0"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/releases/tag/v8.9.0"
}
],
"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 whitespace around equals in Cache-Control directives"
}
GHSA-M36G-FVPC-HVM4
Vulnerability from github – Published: 2026-01-16 21:30 – Updated: 2026-01-17 00:30An issue was discovered in Chamillo LMS 1.11.2. The Social Network /personal_data endpoint exposes full sensitive user information even after logout because proper cache-control is missing. Using the browser back button restores all personal data, allowing unauthorized users on the same device to view confidential information. This leads to profiling, impersonation, targeted attacks, and significant privacy risks.
{
"affected": [],
"aliases": [
"CVE-2025-69581"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-16T20:15:49Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Chamillo LMS 1.11.2. The Social Network /personal_data endpoint exposes full sensitive user information even after logout because proper cache-control is missing. Using the browser back button restores all personal data, allowing unauthorized users on the same device to view confidential information. This leads to profiling, impersonation, targeted attacks, and significant privacy risks.",
"id": "GHSA-m36g-fvpc-hvm4",
"modified": "2026-01-17T00:30:24Z",
"published": "2026-01-16T21:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69581"
},
{
"type": "WEB",
"url": "https://github.com/Rivek619/CVE-2025-69581"
},
{
"type": "WEB",
"url": "https://github.com/chamilo/chamilo-lms"
}
],
"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-M52J-G5RM-PWW7
Vulnerability from github – Published: 2023-08-08 03:30 – Updated: 2024-09-29 00:30Under certain conditions SAP Commerce (OCC API) - versions HY_COM 2105, HY_COM 2205, COM_CLOUD 2211, endpoints allow an attacker to access information which would otherwise be restricted. On successful exploitation there could be a high impact on confidentiality with no impact on integrity and availability of the application.
{
"affected": [],
"aliases": [
"CVE-2023-37486"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-08T01:15:17Z",
"severity": "HIGH"
},
"details": "Under certain conditions\u00a0SAP Commerce\u00a0(OCC API) - versions HY_COM 2105, HY_COM 2205, COM_CLOUD 2211, endpoints allow an attacker to access information which would otherwise be restricted. On successful exploitation there could be a high impact on confidentiality with no impact on integrity and availability of the application.\n\n",
"id": "GHSA-m52j-g5rm-pww7",
"modified": "2024-09-29T00:30:57Z",
"published": "2023-08-08T03:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37486"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3341934"
},
{
"type": "WEB",
"url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
}
],
"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"
}
]
}
GHSA-M9W6-WP3H-VQ8G
Vulnerability from github – Published: 2024-04-25 18:30 – Updated: 2024-09-12 00:31A flaw was found in coredns. This issue could lead to invalid cache entries returning due to incorrectly implemented caching.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.11.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/coredns/coredns"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-0874"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-25T19:57:51Z",
"nvd_published_at": "2024-04-25T17:15:47Z",
"severity": "MODERATE"
},
"details": "A flaw was found in coredns. This issue could lead to invalid cache entries returning due to incorrectly implemented caching.",
"id": "GHSA-m9w6-wp3h-vq8g",
"modified": "2024-09-12T00:31:22Z",
"published": "2024-04-25T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0874"
},
{
"type": "WEB",
"url": "https://github.com/coredns/coredns/issues/6186"
},
{
"type": "WEB",
"url": "https://github.com/coredns/coredns/pull/6354"
},
{
"type": "WEB",
"url": "https://github.com/coredns/coredns/commit/997c7f953962d47c242273f0e41398fdfb5b0151"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:0041"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:4850"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:6009"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:6406"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-0874"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2219234"
},
{
"type": "PACKAGE",
"url": "https://github.com/coredns/coredns"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": " CoreDNS may return invalid cache entries"
}
GHSA-MCGQ-5C2Q-CHC3
Vulnerability from github – Published: 2025-11-04 03:30 – Updated: 2025-12-17 21:30The issue was addressed with improved handling of caches. This issue is fixed in Safari 26.1, visionOS 26.1, watchOS 26.1, iOS 26.1 and iPadOS 26.1, tvOS 26.1. A website may exfiltrate image data cross-origin.
{
"affected": [],
"aliases": [
"CVE-2025-43392"
],
"database_specific": {
"cwe_ids": [
"CWE-524",
"CWE-942"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-04T02:15:46Z",
"severity": "MODERATE"
},
"details": "The issue was addressed with improved handling of caches. This issue is fixed in Safari 26.1, visionOS 26.1, watchOS 26.1, iOS 26.1 and iPadOS 26.1, tvOS 26.1. A website may exfiltrate image data cross-origin.",
"id": "GHSA-mcgq-5c2q-chc3",
"modified": "2025-12-17T21:30:33Z",
"published": "2025-11-04T03:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43392"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125632"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125633"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125634"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125637"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125638"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125639"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125640"
}
],
"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-MQ64-J8F9-9GCJ
Vulnerability from github – Published: 2026-06-09 06:31 – Updated: 2026-07-30 15:24Spring MVC and WebFlux applications are vulnerable to Information Disclosure attacks when resolving static resources.
Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.2.18"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.2.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.2.18"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.2.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"last_affected": "6.1.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "6.1.0"
},
{
"last_affected": "6.1.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webmvc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.3.39"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-webflux"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.3.39"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41841"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-30T15:24:41Z",
"nvd_published_at": "2026-06-09T05:16:36Z",
"severity": "MODERATE"
},
"details": "Spring MVC and WebFlux applications are vulnerable to Information Disclosure attacks when resolving static resources.\n\nAffected versions:\nSpring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.",
"id": "GHSA-mq64-j8f9-9gcj",
"modified": "2026-07-30T15:24:41Z",
"published": "2026-06-09T06:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41841"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-framework"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-framework/releases/tag/v6.2.19"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-framework/releases/tag/v7.0.8"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-41841"
}
],
"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": "Spring Framework Information Disclosure via Static Resource Cache in Spring MVC and WebFlux"
}
GHSA-MVWP-XPR9-3MWJ
Vulnerability from github – Published: 2025-12-12 21:31 – Updated: 2025-12-17 21:30The issue was addressed with improved handling of caches. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2. An attacker with physical access may be able to view deleted notes.
{
"affected": [],
"aliases": [
"CVE-2025-43410"
],
"database_specific": {
"cwe_ids": [
"CWE-524"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-12T21:15:54Z",
"severity": "LOW"
},
"details": "The issue was addressed with improved handling of caches. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2. An attacker with physical access may be able to view deleted notes.",
"id": "GHSA-mvwp-xpr9-3mwj",
"modified": "2025-12-17T21:30:42Z",
"published": "2025-12-12T21:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43410"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125635"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125636"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125886"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P77J-G7H5-R2VW
Vulnerability from github – Published: 2026-08-19 19:22 – Updated: 2026-08-19 19:23GeoLens 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>/environand allowing CRLF header injection. - Unauthenticated STAC search DoS.
POST /searchdid not cap the size of GeoJSONintersectsgeometries (theGETsibling did). - API key written to access logs. The bundled reverse proxy logged the
api_keyquery-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_JSONlogging flag rather than an explicit environment setting, so a production deployment at the default could expose/docsand emit a non-Secure session cookie. - Missing Content-Security-Policy (defense-in-depth). The web application shipped no
script-src/default-srcCSP, 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
{
"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:35Summary
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.
{
"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:32In 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
{
"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"
}
Mitigation
Protect information stored in cache.
Mitigation
Do not store unnecessarily sensitive information in the cache.
Mitigation
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.