Eclipse Vert.x CVE-2026-102479

Exploitation requires that the target run an affected Eclipse Vert.x version (vertx-core 5.0.0-5.0.12, 5.1.0-5.1.9, or 5.2.0) serving HTTP/1.x, since the flaw is in the HTTP/1.x decoder's canonicalization of well-known headers (e.g. 'Content-Xength' being interpreted as 'Content-Length'). The practical impact of request smuggling additionally depends on the deployment topology: a second HTTP agent must share the request path (a front-end proxy/load balancer, CDN, or back-end server) that parses the ambiguous headers differently from Vert.x - a standalone Vert.x server with no co-located HTTP intermediary limits exploitability. No authentication and no user interaction are required (PR:N/UI:N), and the attack works over the network against HTTP/1.x listeners; deployments served exclusively over HTTP/2 are not reached by this HTTP/1.x decoder path.

This is a credible, deployable HTTP request smuggling flaw rather than a high-CVSS-but-low-real-risk issue. The vendor CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated attack requiring no user interaction, and the impact is concentrated entirely on integrity (VI:H) with VC:N/VA:N - consistent with request smuggling, which corrupts request boundaries/routing rather than directly reading data or crashing the service. The 8.7 score is driven by trivial reachability combined with high integrity impact, which is plausible for a header-parsing desync bug. No EPSS score, CISA KEV entry, SSVC decision, or POC was supplied in the input, so exploitation-probability signals are absent - this means the score reflects latent severity, not demonstrated in-the-wild activity. Note a tagging/impact tension: the input Tags label this 'Information Disclosure', yet the CVSS vector sets VC:N (no confidentiality impact) and request smuggling is fundamentally an integrity/desync issue - treat the 'Information Disclosure' categorization as unverified. CWE is listed as N/A, so no weakness classification corroborates the mechanism beyond the description (effectively CWE-444, HTTP request smuggling). Overall: real priority for anyone running an affected Vert.x version behind or in front of other HTTP intermediaries, but without EPSS/KEV/POC data the urgency is 'patch promptly', not 'emergency active-exploitation response'.

An attacker sends a crafted HTTP/1.x request containing a mangled header such as 'Content-Xength' that Vert.x's header canonicalization normalizes to the well-known 'Content-Length', desynchronizing how Vert.x and an upstream/downstream proxy or server delimit requests. By smuggling a second request inside the first, the attacker can poison the request queue of other users, bypass front-end access controls, or route hidden requests to back-end endpoints. No public exploit was identified in the provided data, but the technique is well understood and the unauthenticated network vector (AC:L) makes practical exploitation straightforward where a vulnerable Vert.x instance shares a connection path with another HTTP component.