GHSA-xh2g-9hw9-mvp3: 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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Mark user-specific HTTP responses as private or no-store so they are not stored in the client-level shared cache tier and served to other users.
CachingWebClient HTTP response cache directives = private or no-store
Event History
Frequently Asked Questions
Which deployments are exposed to cross-user response disclosure?
Deployments are exposed when they share one CachingWebClient across users while using per-user WebClientSession instances, and an upstream response is user-specific, cacheable, and not marked private or no-store. Anonymous callers using that same client can also receive a previously cached user response.
Does exploitation require an authenticated attacker or user interaction?
No. The issue is network-reachable and requires no privileges or user interaction. An attacker needs to request the same URL through the shared caching client after a user-specific response has been placed in its shared cache.
What information could be exposed?
A later user may receive authenticated content belonging to an earlier user. If the cached response contains a session cookie, the exposure can enable session fixation or session hijacking.
How can I determine whether my application is affected?
Review whether the application uses a shared CachingWebClient with separate WebClientSession instances for different users. Then identify user-specific responses that can be cached without private or no-store directives and are requested at the same URL by different users or anonymous callers.