Eclipse Vert.x CVE-2026-118489

Exploitation requires all of: (1) the application uses a single CachingWebClient shared across user principals - the documented per-user WebClientSession over a shared caching client; (2) the origin returns a user-specific response (e.g. one answering a request that carried an Authorization header, or one carrying Set-Cookie such as a session identifier) that is cacheable and NOT marked private or no-store - max-age/public/s-maxage alone is enough to trigger storage; and (3) the shared cache key omits any per-user marker, so a later session-private miss or anonymous request for the same URL is served the stored response. Limiting factors that reduce realistic exposure: if the app does not share one CachingWebClient across users, or the origin correctly marks user-specific responses private/no-store, the flaw is not triggered; no attacker authentication or user interaction is required. Affected versions are [4.0.0,4.5.35] and [5.0.0,5.2.2] only.

The CVSS 3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) presents this as a high-severity, network, unauthenticated confidentiality break, but the real-world risk is more conditional than that vector suggests. Exploitation requires a specific deployment pattern - a single CachingWebClient shared across user principals (the documented per-user WebClientSession over a shared caching client) - AND an origin that returns user-specific responses as cacheable without private/no-store; the advisory itself calls the missing restrictive origin directive a contributing condition. That combination of required conditions beyond the attacker's control argues for a higher attack complexity than the input's AC:L implies. Supporting signals are thin: no EPSS score is provided, there is no CISA KEV listing (not actively exploited), and no verified exploit code is present - only the Eclipse/GHSA advisory and the GitLab assignment work item. The vuln.today decision label is this_week rather than act_now/emergency. Net: a genuine cross-user disclosure flaw worth patching promptly for anyone using the shared CachingWebClient pattern, but not a drop-everything emergency, and likely lower prevalence of exploitable instances than the raw 7.5 suggests because of the stacked preconditions.

An application shares one CachingWebClient across users (per-user WebClientSession over a shared caching client) and fetches content from an origin that returns a user-specific response - for example one carrying Set-Cookie or gated by an Authorization header - marked cacheable without private/no-store. An authenticated user's response is stored in the client-level shared cache tier keyed only by URL, with no per-user marker. A later session-private miss or an anonymous caller requesting the same URL falls back to the shared tier and receives the earlier user's body, disclosing authenticated content or replaying a session cookie that enables session fixation or hijacking. No verified public exploit code is identified; only the vendor advisory exists.