EUVD-2026-43639Severity by source
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
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.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
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
Lifecycle Timeline
2DescriptionCVE.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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | 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. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | 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. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | 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. … |
| Remediation | 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. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
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). …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
More in Eclipse Vert X
View allSame weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today