Bug 2565923 (CVE-2026-118489)

Summary: CVE-2026-118489 io.vertx/vertx-web-client: vertx-web-client: Information disclosure via shared web client cache
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: ant, aschwart, aszczucz, boliveir, ccranfor, cescoffi, cmah, dhanak, drichtar, drosa, dsimansk, ewittman, fmariani, fmongiar, gmalinko, gsmet, janstey, jmartisk, jnethert, jpechane, jwon, kaycoth, kingland, manderse, mcarlett, mnovotny, mposolda, nipatil, olubyans, ozzy, pantinor, pjindal, rguimara, rkubis, rmartinc, rstepani, sausingh, sbiarozk, sdawley, ssilvert, sthorger, tcunning, varjain, vmuzikar, yfang
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Eclipse Vert.x Web Client. When a caching client is shared across multiple user sessions, responses intended for a specific user that are not explicitly marked as private are stored in a shared cache. Consequently, an unauthorized user or caller requesting the same resource can receive the previously cached response, leading to sensitive information disclosure. This flaw can expose authentication cookies or confidential user data, potentially enabling session hijacking.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-11-03 16:20:43 UTC 
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.