Eclipse Vert.x CVE-2026-15075

Exploitation requires that the vulnerable application uses the Vert.x HttpClient with redirect following enabled AND allows attacker-influenced destination URLs - concretely a feature such as a webhook dispatcher, image proxy, or microservice/URL fetcher where the caller or a third party can supply or influence the target address. The attacker must control (or be able to make the target redirect to) a host under their control, and the original request must carry sensitive headers (Authorization, Cookie, Proxy-Authorization, or custom tokens like X-API-Token) for anything to leak - this is the CVSS AT:P attack requirement. Limiting factors: if the application only contacts fixed, trusted endpoints, disables redirect following, or attaches no credential headers, the flaw is not exploitable; no authentication on the vulnerable service is needed (PR:N) and no user interaction is required (UI:N).

The vendor-supplied CVSS 4.0 score is 8.2 (High) with vector AV:N/AC:L/AT:P/PR:N/UI:N and confidentiality-only impact (VC:H, VI:N, VA:N), which matches the behavior: pure information disclosure, network-reachable, but gated by AT:P - a real attack requirement, namely that the attacker must be able to induce the victim client to issue a request that redirects to a host they control. No EPSS score, KEV listing, POC, or SSVC decision data was provided, so exploitation-probability signals are absent rather than low. The practical risk is real but conditional: it is high wherever a Vert.x-based service forwards attacker-influenceable URLs while attaching static credentials, and negligible where target URLs are fixed and trusted. The PR:N (unauthenticated) rating reflects that the attacker needs no credentials on the vulnerable service, but exploitation still depends on application-level exposure of the HttpClient to untrusted URLs - a limiting factor not captured by the base score.

A SaaS platform uses a Vert.x-based webhook dispatcher that attaches a static Authorization bearer token and sends events to customer-supplied callback URLs. An attacker registers a callback pointing to their server, which responds with a 302 redirect to a second attacker host; Vert.x follows the redirect and re-sends the Authorization header, letting the attacker capture the bearer token. No public POC is currently known, but the flaw is trivially reproducible given the low attack complexity (AC:L).