CVE-2026-118489 in Vert.x
Summary
by MITRE • 11/03/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in Eclipse Vert.x versions ranging from 4.0.0 to 4.5.35 and 5.0.0 to 5.2.2 represents a critical flaw in how shared caching mechanisms interact with user-specific session data within the CachingWebClient component. This issue arises specifically when developers follow the documented best practice of sharing a single CachingWebClient instance across multiple users, while maintaining separate WebClientSession instances for each individual user context. The core technical failure lies in the cache key generation and storage logic, which fails to adequately distinguish between responses intended for specific authenticated sessions versus those that are truly public or universally applicable. When a response is deemed cacheable by standard HTTP criteria but lacks explicit directives such as Cache-Control: private or no-store, it is stored in the client-level shared cache tier rather than being isolated within the user-specific session scope. This architectural oversight allows any subsequent request made through the same CachingWebClient instance to retrieve this cached content regardless of the originating WebClientSession's identity.
From an operational perspective, this flaw leads directly to severe information disclosure and potential account takeover scenarios. An attacker or a different legitimate user accessing the same URL can receive a response that was originally generated for another authenticated user. If the cached response contains sensitive data such as personal identifiable information, financial details, or internal application state, it results in unauthorized access to confidential resources. More critically, if the cached response includes session cookies or authentication tokens, an attacker can exploit this mechanism to perform session fixation attacks. By forcing a victim's browser to accept a cookie value that was originally issued for another user, or by intercepting and reusing these credentials, the attacker can hijack existing sessions without needing to crack passwords or bypass multi-factor authentication controls. This effectively undermines the isolation guarantees provided by HTTP cookies and session management protocols.
This vulnerability aligns with CWE-201: Information Exposure Through Debug Information when considering the leakage of sensitive headers, but more accurately maps to CWE-640: Weakness in Cache Control Mechanisms and CWE-384: Session Fixation through Cookie Manipulation. In terms of the MITRE ATT&CK framework, this behavior facilitates Initial Access via Credential Stuffing or Account Hijacking techniques, specifically leveraging improper session management practices that allow an adversary to assume the identity of another user. The lack of proper cache isolation means that the application fails to enforce security boundaries between concurrent users sharing a common infrastructure component, violating fundamental principles of secure multi-tenancy and data segregation in web applications.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. For organizations using affected versions, upgrading to a patched version where this caching logic has been corrected is the primary recommendation. If an upgrade is not immediately feasible, developers should explicitly configure all WebClientSession instances with cache control directives that prevent sensitive responses from being stored in shared caches. This involves setting Cache-Control headers such as private, no-store, or max-age=0 on any response containing user-specific data before it enters the caching layer. Additionally, application code should be audited to ensure that CachingWebClient is not used for endpoints returning authenticated content unless strict isolation mechanisms are implemented at the application level rather than relying solely on HTTP cache semantics. Implementing a custom CacheKeyGenerator that incorporates unique session identifiers or user context data into the cache key can also serve as an effective workaround, ensuring that cached responses remain bound to their originating sessions and cannot be served to other users sharing the same client instance.