A vulnerability in undici HTTP client for Node.js versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3 allows a shared cache to serve an authenticated response to an unauthenticated caller due to improper origin validation during redirect and cache revalidation. This occurs when a cached response is revalidated with a 304 Not Modified status from a different origin, causing undici to incorrectly treat the response as valid. The issue is fixed in versions 7.30.2 and 8.12.4. Users should upgrade to these versions or later or apply recommended workarounds to mitigate the risk.
undici, an HTTP client for Node.js, has a vulnerability in versions 7.30.1 and 8.12.2 through 8.12.3 where origin validation during caching of redirected responses is flawed. This allows an attacker controlling a redirect target from a trusted URL to poison cached entries or cause private responses to be served to other users. The issue arises because the client inspects only the final redirect hop for caching decisions, ignoring intermediate hops that may affect cache validity. The vulnerability is fixed in versions 7.30.2 and 8.12.4.
A vulnerability in undici HTTP client versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3 allows cross-user disclosure of cached private responses. When using the redirect interceptor with a shared response cache, an authenticated redirected request's final response is cached under the original request's key, which lacks credential and Vary header information. This can cause private response data to be served to unauthorized users. The issue is fixed in versions 7.30.2 and 8.12.4.
Use of Cache Containing Sensitive Information (CWE-524) in Elasticsearch can lead to information disclosure and incorrect search results via specially crafted search requests. For some query types, Elasticsearch can share cached query results between users who have field-level security restrictions and users who do not. A user restricted by field-level security can learn which documents match a value in a field that they cannot read. A restricted user can also cause users with full access to receive incomplete search results. Disclosure is only possible when a user with full access ran the same query on the same shard recently.
CVE-2026-113593 is a vulnerability in Django versions prior to 6.1.3, 6.0.10, and 5.2.19 where the cache middleware and cache_page decorator generate identical cache keys for requests that omit a header listed in the response's Vary header and requests that include that header with an empty value. This can allow remote attackers to access cached private data from other requests.
In Eclipse Vert.x versions [4.0.0,4.5.35] or [5.0.0,5.2.2], when one `CachingWebClient` is shared across users — the documented pattern of a per-user `WebClientSession` over a shared caching client — a response that is specific to one user but is cacheable and not marked `private`/`no-store` is stored in the client-level shared cache tier and served to other users requesting the same URL. A later user's session, or an anonymous caller through the same client, can receive an earlier user's response. Depending on the response this discloses authenticated content or a session cookie, the latter enabling session fixation or hijacking.
The WP Fastest Cache plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.5.3. The plugin caches the response of Core’s wp-activate.php without honoring its no-store/no-cache headers, the wp-activate-* cookie, or the WP_INSTALLING state, writing the credential-bearing activation response to a publicly accessible cache file. This makes it possible for unauthenticated attackers to retrieve the plaintext username and twelve-character password of the most recently activated Multisite registrant from that cached wp-activate.php response. Exploitation requires a Multisite subdirectory installation with public user and site registration enabled, and the credentials are only exposed after a genuine registrant follows their activation link.
The PDF Invoices & Packing Slips for WooCommerce plugin for WordPress versions up to 5.16.5 has a vulnerability that allows unauthenticated attackers to access complete invoice PDFs of other customers. This occurs via the 'invoice_number' parameter in the document filename when the plugin's yearly invoice number reset option is enabled. Exploitation requires the attacker to place a guest-checkout order triggering a processing email within 60 seconds of a victim's order sharing the same yearly-reset invoice number. The exposed invoice contains sensitive information including billing identity, shipping address, private order notes, line items, prices, dates, order ID, and invoice number.
CVE-2026-94386 is a vulnerability in Apache Camel's OAuth component affecting versions from 4.19.0 up to but not including 4.22.2. The issue arises because OAuth tokens are cached in a static cache keyed only by token endpoint and client ID, ignoring client secret and requested scope. This can cause tokens issued for one profile's scope or client secret to be incorrectly reused by another profile, potentially granting broader or unintended access. The vulnerability is fixed in Apache Camel version 4.22.2 and later.
A vulnerability in GitLab CE/EE versions from 15.0 up to but not including 19.3.6, 19.4 up to 19.4.3, and 19.5 up to 19.5.1 allowed authenticated users without project membership to read confidential issue titles. This occurred when a merge request in a public project referenced a confidential issue from a private project due to improper caching of rendered content shared across users.
Apache Cocoon contains a vulnerability involving the use of cache containing sensitive information. In multi-user environments, cached data from one user could be served to another, potentially exposing sensitive information. This affects all versions of Apache Cocoon. The project is retired and no fixes will be released. Users are advised to migrate to alternatives or restrict access to trusted users only.
Use of Cache Containing Sensitive Information vulnerability in Apache Camel HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The OAuth2 client token cache is global to the JVM, and its key omitted several of the fields that determine what a token actually authorises: the requested scope, the resource indicator, and the token endpoint the token was obtained from. Two endpoints differing only in those fields therefore shared a cache entry, and an endpoint could be served a token minted for a different scope, a different resource, or by a different authorization server. The consequence is a request carrying broader authority than the endpoint was configured for, or a token presented to a party it was not issued for. Reaching it requires a deployment that configures more than one OAuth2 endpoint differing in exactly those fields, which is why the severity is assessed low.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them. For deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache.
The SpeedyCache – Cache, Optimization, Performance WordPress plugin up to version 1.4.2 has a vulnerability that allows unauthenticated attackers to extract sensitive information such as the full name and email address of returning commenters. This occurs because the plugin caches pages containing pre-filled comment form fields with commenter data, and the cache write path does not properly validate requests, enabling cache poisoning. The vulnerability is classified as sensitive information exposure with a low CVSS score of 3.7.
vLLM is an inference and serving engine for large language models. Prior to 0.30.0, Harmony tool continuations submitted through "POST /v1/responses" requests rebuild the next-turn engine input without preserving the cache_salt value, placing the continuation prefix in the global unsalted cache namespace even when the caller enabled salting. On deployments with prefix caching enabled, which is the default, an authenticated tenant who can reconstruct a victim's low-entropy post-tool history can submit the same continuation and use the cached_tokens_per_turn count to determine whether the prefix was previously processed, defeating the intended tenant isolation of salted prefix caching. This issue is fixed in version 0.30.0.
Next.js versions from 15.0.0 up to but not including 15.5.27, and from 16.0.0 up to but not including 16.3.8, contain a vulnerability where a shared response cache key is insufficiently scoped. This allows an unauthenticated attacker to poison the cache via a crafted request, potentially causing cross-user content substitution or persistent denial of service until the cache entry is refreshed. The issue is fixed in versions 15.5.27 and 16.3.8.
Next.js versions from 15.0.0 up to but not including 15.5.27, and from 16.0.0 up to but not including 16.3.8, contain a vulnerability where the response cache for statically generated or Incremental Static Regeneration pages using the Pages Router can be incorrectly keyed. This allows a request to replace one page's cached content with that of another route, causing incorrect content to be served to visitors until the cache is revalidated. Applications deployed on Vercel are not affected. The issue is fixed in versions 15.5.27 and 16.3.8.
CVE-2026-94544 is a medium severity vulnerability in Vercel's Next.js framework affecting versions >=16.3.0 and <16.3.8. It involves the use of a shared cache for pending `use cache` fills that does not distinguish between Draft Mode and regular requests. This can cause unpublished draft content to be served to unauthenticated users or published content to be served in draft previews. Additionally, if a regular request prerenders a page during this overlap, unpublished content may be persisted and served to all visitors until the page is revalidated.
Next.js versions from 16.3.0 to 16.3.7 warm `use cache` handlers using `next/root-params` and can leak their return value to pages with different root params. With Cache Components enabled (cacheComponents: true), a 'use cache' function that calls another 'use cache' function that reads a root param can be keyed incorrectly when the inner call is served from an existing entry: the enclosing function's cache key then omits that root param. The enclosing entry is written once and reused for all root param values, so a response for one root param value can serve content produced for a different value — whether the page is prerendered at build time or at runtime, or rendered dynamically. Shared cache headers let downstream caches redistribute the content further.
What values are leaked cannot be attacker controlled. Which value's content is served depends only on which invocation wrote the entry first.
This has been patched in 16.3.8.
A caching flaw in the toolbox-core package of the mcp-toolbox-sdk-python SDK causes the same Google ID token to be cached and reused across different audiences. If an application uses the SDK to authenticate to two or more different audiences within the same process, the module-level token cache fails to key its cached tokens by the requested audience. Consequently, a valid, unexpired token minted for a sensitive service (Service A) can be retrieved from the cache and sent to a secondary service (Service B). An attacker who operates, compromises, or monitors traffic to Service B can capture this token and replay it to impersonate the victim application against Service A.
Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.
MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.
This issue affects mpp: from 0.1.0 before 0.16.2.