CWE-524

A cache configuration issue prior to WhatsApp for Android v2.21.4.18 and WhatsApp Business for Android v2.21.4.18 may have allowed a third party with access to the device’s external storage to read cached TLS material.

The implementations of SAE in hostapd and wpa_supplicant are vulnerable to side channel attacks as a result of observable timing differences and cache access patterns. An attacker may be able to gain leaked information from a side channel attack that can be used for full password recovery. Both hostapd with SAE support and wpa_supplicant with SAE support prior to and including version 2.7 are affected.

The implementations of EAP-PWD in hostapd and wpa_supplicant are vulnerable to side-channel attacks as a result of cache access patterns. All versions of hostapd and wpa_supplicant with EAP-PWD support are vulnerable. The ability to install and execute applications is necessary for a successful attack. Memory access patterns are visible in a shared cache. Weak passwords may be cracked. Versions of hostapd/wpa_supplicant 2.7 and newer, are not vulnerable to the timing attack described in CVE-2019-9494. Both hostapd with EAP-pwd support and wpa_supplicant with EAP-pwd support prior to and including version 2.7 are affected.

The AccessLogFilter class in Jira before version 8.4.0 allows remote anonymous attackers to learn details about other users, including their username, via an information expose through caching vulnerability when Jira is configured with a reverse Proxy and or a load balancer with caching or a CDN.

A flaw was found in coredns. This issue could lead to invalid cache entries returning due to incorrectly implemented caching.

Directus is a real-time API and App dashboard for managing SQL database content. An unauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include redirect query string. 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. This vulnerability is fixed in 10.13.3 and 11.1.0.

Shopware is an open commerce platform based on Symfony Framework and Vue. The Symfony Session Handler pops the Session Cookie and assigns it to the Response. Since Shopware 6.5.8.0, the 404 pages are cached to improve the performance of 404 pages. So the cached Response which contains a Session Cookie when the Browser accessing the 404 page, has no cookies yet. The Symfony Session Handler is in use, when no explicit Session configuration has been done. When Redis is in use for Sessions using the PHP Redis extension, this exploiting code is not used. Shopware version 6.5.8.7 contains a patch for this issue. As a workaround, use Redis for Sessions, as this does not trigger the exploit code.

An issue was discovered in MediaWiki before 1.35.5, 1.36.x before 1.36.3, and 1.37.x before 1.37.1. The REST API publicly caches results from private wikis.

Use of Cache Containing Sensitive Information in GitHub repository ikus060/rdiffweb prior to 2.4.8.

In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by --cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If --cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.11.7, Cache Middleware contains an information disclosure vulnerability caused by improper handling of HTTP cache control directives. The middleware does not respect standard cache control headers such as `Cache-Control: private` or `Cache-Control: no-store`, which may result in private or authenticated responses being cached and subsequently exposed to unauthorized users. Version 4.11.7 has a patch for the issue.

Sametime is impacted by sensitive fields with autocomplete enabled in the Legacy web chat client. By default, this allows user entered data to be stored by the browser.

Under 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.

A flaw was found in libsoup’s caching mechanism, SoupCache, where the HTTP Vary header is ignored when evaluating cached responses. This header ensures that responses vary appropriately based on request headers such as language or authentication. Without this check, cached content can be incorrectly reused across different requests, potentially exposing sensitive user information. While the issue is unlikely to affect everyday desktop use, it could result in confidentiality breaches in proxy or multi-user environments.

Mastodon is a free, open-source social network server based on ActivityPub. Prior to versions 4.3.19, 4.4.13, 4.5.6, Mastodon is vulnerable to web cache poisoning via `Rails.cache. When AUTHORIZED_FETCH is enabled, the ActivityPub endpoints for pinned posts and featured hashtags have contents that depend on the account that signed the HTTP request. However, these contents are stored in an internal cache and reused with no regards to the signing actor. As a result, an empty response generated for a blocked user account may be served to requests from legitimate non-blocked actors, or conversely, content intended for non-blocked actors may be returned to blocked actors. This issue has been patched in versions 4.3.19, 4.4.13, 4.5.6.

Flask is a web server gateway interface (WSGI) web application framework. In versions 3.1.2 and below, when the session object is accessed, Flask should set the Vary: Cookie header., resulting in a Use of Cache Containing Sensitive Information vulnerability. The logic instructs caches not to cache the response, as it may contain information specific to a logged in user. This is handled in most cases, but some forms of access such as the Python in operator were overlooked. The severity and risk depend on the application being hosted behind a caching proxy that doesn't ignore responses with cookies, not setting a Cache-Control header to mark pages as private or non-cacheable, and accessing the session in a way that only touches keys without reading values or mutating the session. The issue has been fixed in version 3.1.3.

In JetBrains Ktor before 2.3.13 improper caching in HttpCache Plugin could lead to response information disclosure

The AuthKit library for Next.js provides convenient helpers for authentication and session management using WorkOS & AuthKit with Next.js. 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. Patched in authkit-nextjs 2.11.1, which applies anti-caching headers to all responses behind authentication.

Next.js is a React framework for building full-stack web applications. In versions before 14.2.31 and from 15.0.0 to before 15.4.5, Next.js Image Optimization API routes are affected by cache key confusion. 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. This vulnerability has been fixed in Next.js versions 14.2.31 and 15.4.5. All users are encouraged to upgrade if they use API routes to serve images that depend on request headers and have image optimization enabled.

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.

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.

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.

An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14. `django.middleware.cache.UpdateCacheMiddleware` erroneously caches requests where the `Vary` header contained an asterisk (`'*'`). This can lead to private data being stored and served. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Ahmad Sadeddin for reporting this issue.

Axios Cache Interceptor is a cache interceptor for axios. Prior to version 1.11.1, when a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass. The cache key is generated only from the URL, ignoring request headers like `Authorization`. When the server responds with `Vary: Authorization` (indicating the response varies by auth token), the library ignores this, causing all requests to share the same cache regardless of authorization. Server-side applications (APIs, proxies, backend services) that use axios-cache-interceptor to cache requests to upstream services, handle requests from multiple users with different auth tokens, and upstream services replies on `Vary` to differentiate caches are affected. Browser/client-side applications (single user per browser session) are not affected. Services using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions. After `v1.11.1`, automatic `Vary` header support is now enabled by default. When server responds with `Vary: Authorization`, cache keys now include the authorization header value. Each user gets their own cache.

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

Fiber is a web framework for Go. In github.com/gofiber/fiber/v3 versions through 3.1.0, the default key generator in the cache middleware uses only the request path and does not include the query string. As a result, requests for the same path with different query parameters can share a cache key and receive the wrong cached response. This can cause response mix-up for query-dependent endpoints and may expose data intended for a different request. This issue is fixed after version 3.1.0.

Discourse is an open source discussion platform. Version before 3.6.2 and 3.6.0.beta2, default Cache-Control response header with value no-store, no-cache was missing from error responses. This may caused unintended caching of those responses by proxies potentially leading to cache poisoning attacks. This vulnerability is fixed in 3.6.2 and 3.6.0.beta2.

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

Spring MVC and WebFlux applications are vulnerable to cache poisoning when resolving static resources. More precisely, an application can be vulnerable when all the following are true: * the application is using Spring MVC or Spring WebFlux * the application is configuring the  resource chain support https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title  with caching enabled * the application adds support for encoded resources resolution * the resource cache must be empty when the attacker has access to the application When all the conditions above are met, the attacker can send malicious requests and poison the resource cache with resources using the wrong encoding. This can cause a denial of service by breaking the front-end application for clients.

Typesense is a fast, typo-tolerant search engine. Prior to versions 29.1 and 30.2, there is a cache isolation issue affecting search requests that use both server-side search result caching and Scoped Search API Keys. Under specific request ordering, cached search results could be reused across requests with different Scoped Search API Key constraints. This could result in a request receiving search results that should have been restricted by its Scoped Search API Key. This issue only affects search requests that use both server-side search result caching and Scoped Search API Keys with embedded filters to restrict access to search results within a collection. This vulnerability may result in unintended disclosure of search results across scoped authorization contexts. This issue has been patched in versions 29.1 and 30.2.

Discourse is an open-source discussion platform. In versions prior to 2026.1.4, 2026.3.1, 2026.4.1 and 2026.5.0-latest.1, outdated cached AI summaries can leak removed content to anonymous and unprivileged users who cannot regenerate summaries. This issue has been fixed in versions 2026.1.4, 2026.3.1, 2026.4.1 and 2026.5.0-latest.1. To work around this issue, restrict summary generation by tightening the allowed groups on the summarization Personas.

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.

The issue was addressed with improved handling of caches. This issue is fixed in iOS 16. An app may be able to access user-sensitive data.

The issue was addressed with improved handling of caches. This issue is fixed in macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.2. An attacker with physical access may be able to view deleted notes.

Spring 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.

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.

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.12.18, 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. This vulnerability is fixed in 4.12.18.

An issue was discovered in Overhang.IO (tutor-open-edx) (overhangio/tutor) 20.0.2 allowing local unauthorized attackers to gain access to sensitive information due to the absence of proper cache-control HTTP headers and client-side session checks.

Missing "no cache" headers in HCL Leap permits sensitive data to be cached.

An insufficient implementation of cache vulnerability in Palo Alto Networks Prisma® Access Browser enables users to bypass certain data control policies.

Missing "no cache" headers in HCL Leap permits user directory information to be cached.

Missing "no cache" headers in HCL Leap permits sensitive data to be cached.

A binary in the BoKS Server Agent component of Fortra's Core Privileged Access Manager (BoKS) on versions 7.2.0 (up to 7.2.0.17), 8.1.0 (up to 8.1.0.22), 8.1.1 (up to 8.1.1.7), 9.0.0 (up to 9.0.0.1) and also legacy tar installs of BoKS 7.2 without hotfix #0474 on Linux, AIX, and Solaris allows low privilege local users to dump data from the cache.

Android App "Brother iPrint&Scan" versions 6.13.7 and earlier improperly uses an external cache directory. If exploited, application-specific files may be accessed from other malicious applications.

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.

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 explicit client-defined safety parameters: the credentials configuration (such as `credentials: 'omit'`) and the HTTP `cache` mode configuration (such as `cache: 'no-store'`). These are reverted back to standard browser-default parameters (`credentials: 'same-origin'` and default HTTP cache properties). This causes the browser to include active credentials (such as cookies or Authorization headers) on outbound requests where the client-side developer explicitly instructed they should be omitted, leading to potential session leaks. Additionally, it causes private or non-cacheable resources to be cached by the service worker's engine, making private page states accessible or persistent inside the client's local cache post-logout. ### Impact Web applications registering the `@angular/service-worker` package are vulnerable to credential exposure or post-logout cache persistence if client-side code relies on fetch calls with explicit safety attributes (such as `{ credentials: 'omit' }` or `{ cache: 'no-store' }`) targeting paths matched by service worker asset groups. By stripping these safety boundaries, the service worker exposes same-origin cookies and dynamic sensitive data to endpoints that should not receive them, or retains dynamic user sessions in cache storage where logout operations fail to fully evict user records. ### 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. **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. 4. **Client-Side Safe Fetch Call:** The application initiates an explicit fetch request to the route with safety parameters: `{ credentials: 'omit' }` or specific cache control parameters (e.g. `{ cache: 'no-store' }`). ### Mitigations & Workarounds If upgrading the `@angular/service-worker` package is not immediately feasible, developers should implement the following defensive measures: * **Strict Cookie Configuration:** Apply strict flags to session cookies (`SameSite=Strict; Secure; HttpOnly`) and ensure complete route isolation for credential-guarded secure resources. * **Exclude Secure Endpoints from SW Config:** Ensure that patterns targeting dynamic, secure endpoints are explicitly excluded from automatic asset groups or caching scopes in your `ngsw-config.json`. * **Post-Logout Cache Invalidation:** Programmatically purge the browser's Cache Storage API entries registered by the Angular Service Worker upon user logout: ```javascript if ('caches' in window) { caches.keys().then(names => { for (let name of names) { if (name.startsWith('ngsw:')) { caches.delete(name); } } }); } ``` ### Patches - 22.0.0-rc.2 - 21.2.15 - 20.3.22 - 19.2.23

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

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