CVE-2026-118489: CachingWebClient shares user-specific HTTP responses across users via the shared cache tier
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.
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments are exposed when a single CachingWebClient is shared by multiple users, including the documented arrangement of per-user WebClientSession instances over a shared caching client. The affected client must receive user-specific responses that are cacheable and lack private or no-store cache directives.
What does an attacker need to exploit this issue?
An attacker needs only to request the same URL through the shared client after another user has caused a user-specific response to be cached. No authentication, user interaction, or special access is required according to the supplied CVSS vector.
What information could be exposed?
A later user or anonymous caller can receive an earlier user's cached response. This may disclose authenticated content or a session cookie; exposure of a session cookie can enable session fixation or hijacking.
What can be done before upgrading?
Avoid sharing a CachingWebClient across users, or ensure user-specific responses are not cached by marking them private or no-store. This prevents those responses from entering the client-level shared cache tier.
Which versions are affected?
Affected versions are Eclipse Vert.x 4.0.0 through 4.5.35 and 5.0.0 through 5.2.2, inclusive.