Which versions of Eclipse Vert.x are affected by CVE-2026-15075?

Eclipse Vert.x vertx-core (4.5.29 and earlier, 5.1.4 and earlier) contains a credential leakage vulnerability in HTTP redirect handling that exposes sensitive headers including Authorization, Cookie,…

How to fix or mitigate CVE-2026-15075?

Within 24 hours, identify all systems running Eclipse Vert.x vertx-core versions 4.x through 4.5.29 or 5.x through 5.1.4 and determine which handle untrusted URLs (webhooks, user-supplied endpoints, external APIs). Within 7 days, implement mitigations: establish allowlists for HTTP redirect destinations, disable automatic redirects in code paths processing untrusted URLs, and add explicit header filtering to block credential propagation. Within 30 days, monitor for vendor-released patches and prepare upgrade procedures to move affected instances to patched versions when available.

Eclipse Vert.x CVE-2026-15075

Q: What is the CVSS score of CVE-2026-15075?

CVE-2026-15075 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

EUVD-2026-43639 HIGH

Information Exposure (CWE-200)

2026-07-14 eclipse

Information Disclosure Red Hat Eclipse Vert X Eclipse Foundation

8.2

CVSS 4.0 · Vendor: eclipse

Severity by source

Vendor (eclipse) PRIMARY

8.2 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

6.8 MEDIUM

AC:H because the attacker must induce a client request that redirects to their host; S:C as credentials cross origin to a different authority; confidentiality-only, so I:N/A:N.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (eclipse).

CVSS VectorVendor: eclipse

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jul 14, 2026 - 08:47 vuln.today

CVE Published

Jul 14, 2026 - 08:15 cve.org

HIGH 8.2

DescriptionCVE.org

In Eclipse Vert.x versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), DefaultRedirectHandler (vertx-core) propagates all request headers as-is across cross-origin HTTP 30x redirects. Only Content-Length is stripped; no origin comparison (scheme, host, port) is performed before copying headers to the redirect target. As a result, credential headers, including Authorization, Cookie, Proxy-Authorization, and arbitrary custom headers such as X-API-Token, are forwarded to the redirect destination without the caller's knowledge.

An attacker who can cause a Vert.x HttpClient to issue a request that is redirected to an attacker-controlled host (for example, by supplying a URL to a webhook dispatcher, image proxy, or microservice URL fetcher) can capture bearer tokens, basic-auth credentials, session cookies, and API keys attached to the original request.

AnalysisAI

Cross-origin credential leakage in Eclipse Vert.x vertx-core (4.x through 4.5.29 and 5.x through 5.1.4) occurs because DefaultRedirectHandler copies all original request headers verbatim when the HttpClient follows an HTTP 30x redirect, stripping only Content-Length and never comparing the origin (scheme/host/port). An application that lets untrusted input influence a request URL - webhook dispatchers, image proxies, SSRF-style URL fetchers - can be steered to an attacker-controlled redirect target that then receives Authorization, Cookie, Proxy-Authorization, and custom headers like X-API-Token. No public exploit has been identified at time of analysis, and the flaw is not in CISA KEV.

Technical ContextAI

Eclipse Vert.x is a widely used reactive, event-driven toolkit for the JVM; the affected component is vertx-core's HttpClient redirect-following logic in DefaultRedirectHandler. When a server responds with a 301/302/307/308 redirect, a compliant client should re-evaluate which headers are safe to resend to a new origin - sensitive credential headers must be dropped when the redirect crosses a scheme/host/port boundary. Here the handler blindly re-attaches every inbound header (only removing Content-Length) with no origin check, which is the classic CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) root cause: trusted secrets scoped to origin A are transmitted to origin B. The CPE cpe:2.3:a:eclipse_foundation:eclipse_vert.x confirms the affected product line.

RemediationAI

No vendor-released patched version was confirmed from the available data - the sole reference points to an Eclipse GitLab security work item (https://gitlab.eclipse.org/security/cve-assignment/-/work_items/161), and the description only bounds the vulnerable range at 4.5.29 and 5.1.4, implying fixes in subsequent 4.x/5.x releases that should be verified directly with Eclipse before upgrading. As compensating controls, disable automatic redirect following on the Vert.x HttpClient (set the request to not follow redirects, or setFollowRedirects(false)) where feasible - trade-off: the application must handle 30x responses itself. Alternatively, install a custom redirect handler that strips Authorization, Cookie, Proxy-Authorization, and custom credential headers when the redirect target's scheme/host/port differ from the origin. Additionally, validate and allowlist outbound URLs in webhook/image-proxy/URL-fetcher features so untrusted input cannot steer requests to arbitrary hosts (trade-off: reduces flexibility of user-supplied endpoints), and avoid attaching long-lived static credentials to requests whose destinations are not fully trusted.