CVE Watch3 de nov. de 2026

CVE-2026-85317

Use of Cache Containing Sensitive Information vulnerability in Apache Camel HTTP component. This issue affects Apache Camel: from 4.0.0 bef

CVSS

4.8

Média

EPSS

0.5%

p44

KEV

—

Exploit Today

0-100

Publicado: 19 de out. de 2026 · Última mod.: 3 de nov. de 2026 · CWE-524

EPSS · 30d

0.3%EPSS · 30 dias0.5%

2026-10-202026-11-06

Descrição técnica

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.

Referências oficiais

CVEs relacionados

CVECVSSEPSSKEVRExploitTítuloMod.

CVE-2026-1166305.9 MÉD

—

——0undici is an HTTP client for Node.js. In versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3, when an Agent composes the redirect and shared cache interceptors, a cached response that is revalidated with a conditional request can be validated by a 304 Not Modified from a different origin. When the origin that stored the response redirects the conditional revalidation request to another origin, the redirect handler strips origin-bound credential headers but not the cache-generated If-None-Match or If-Modified-Since validators, so the redirect destination receives the original origin's validator and undici treats its 304 as successful revalidation of the stored representation. As a result, a shared cache can serve the original origin's stored authenticated response, including one gated by Authorization, to a later unauthenticated caller. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later. As a workaround, compose the interceptors as cache then redirect, use per-origin dispatchers and cache stores, or disable shared caching on redirect-capable requests.22h CVE-2026-1204746.5 MÉD

21.4%

——6undici is an HTTP client for Node.js. In versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3, when the redirect interceptor and a shared response cache are used together, an authenticated request that is redirected to a same-origin target has the final response stored under the original request's cache key. That key omits the credential and carries no Vary header, so a later anonymous or different user can be served the first user's private response body. This results in cross-user disclosure of cached private responses. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later.22h CVE-2026-1165927.4 ALT

—

——0undici is an HTTP client for Node.js. In versions 7.30.1 and 8.12.2 through 8.12.3, when an originless Agent composes the redirect and shared cache interceptors, undici decides whether to store the final response under the original request key by inspecting only the final redirect hop, which bypasses the earlier fix for CVE-2026-109829 that compared only the initial and final origins. A redirect that bounces through an untrusted origin and returns to the trusted origin is still cached under the trusted key, an intermediate hop's Vary is dropped so a response that varies on Authorization or Cookie can be served to a different user, and an intermediate hop's no-cache or default-uncacheable status is ignored so a non-storable redirect is laundered into a cacheable entry. An attacker who controls a redirect target from a trusted URL can poison the cached entry for that URL or have a private, per-user response served to a later caller. The issue is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to one of those versions or later. As a workaround, compose the interceptors as cache then redirect, use per-origin dispatchers and cache stores, or disable shared caching on redirect-capable requests.22h CVE-2026-1157104.2 MÉD

6.4%

——2Use 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.4d CVE-2026-1135933.1 BAI

40.4%

——12An issue was discovered in Django 6.1 before 6.1.3, 6.0 before 6.0.10, and 5.2 before 5.2.19. The `django.middleware.cache.UpdateCacheMiddleware` and the `django.views.decorators.cache.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, potentially allowing remote attackers to access private data cached for another request. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Andrew Gonzalez for reporting this issue.4d CVE-2026-1184897.5 ALT

27.8%

——8In 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.4d