CVE-2026-102479 in Eclipse Vert.x HTTP/1.x decoder lets a single misspelled header desync request boundaries, enabling silent request erasure, DoS, and cross-user session fixation against shared reverse proxy connections.
Key findings:
- The root cause lives in VertxHttpRequestDecoder's length-based header optimization. For 14-byte headers, the decoder checks prefix and suffix only, never byte offset 8. This means Content-Xength is silently treated as a valid Content-Length, while every tested front-end proxy (Nginx, HAProxy, Envoy, Traefik, Caddy, Apache httpd, nghttpx) ignores it as an unknown custom header. No conflicting Transfer-Encoding needed, just one misspelled header is enough to split request framing between the two layers.
- The attack chain progresses in three stages. First, a Content-Xength header with no body causes Vert.x to wait for bytes the proxy never sends, hanging threads for DoS. Second, the "double-desync" technique borrows from published HTTP/1.1 desync research: request A opens the byte debt, request B carries hidden spliced requests C and D inside its body, and the backend serves C's response to the attacker while D sits orphaned in the socket. Third, the dangling byte technique is the breakthrough: D is left one byte short of its declared body, so no response fires immediately, the proxy's socket check sees a clean buffer, returns the connection to the pool, and the next real visitor's first byte satisfies D's debt, causing the backend to fire D's response at them.
- The practical impact demonstrated end to end is cross-user session fixation. Request D is crafted as a POST /login using attacker-controlled credentials. An unsuspecting visitor with no cookies receives the resulting 303 redirect setting a session cookie for the attacker's account, dropping them silently into that account's data. Against a 16-connection pool, roughly 25 to 35 percent of subsequent traffic is poisoned. The same primitive enables injecting reflected XSS payloads into innocent users browsing normally, and forced redirects to attacker-controlled phishing pages via any redirect parameter, all without requiring the victim to click anything.
- Affected versions are vertx-core 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 only. The fix lands in 5.1.10 and 5.2.1 via a canonicalization correction in the header parser. The JFrog report confirmed PoCs against strimzi/strimzi-kafka-bridge (0.33.0), apache/camel-quarkus, and TechEmpower/FrameworkBenchmarks when deployed behind a front-end proxy. vertx-core carries over 300 million cumulative Maven downloads, but the exposure window is limited to those three modern 5.x release bands.
- Detection opportunity is narrow at the network layer because the malicious header looks like an ordinary custom header to any proxy log. The evidence to hunt is behavioral: look for backend connections that close without completing a response cycle, unexpected 303 redirects setting session cookies on requests that carried none, and any log entries where a login endpoint responds to a request that originated from a connection the proxy had marked idle. Application-layer logs showing session cookies assigned to accounts that did not authenticate in that same request cycle are the strongest indicator of exploitation in progress.
Patch to io.vertx:vertx-core 5.1.10 or 5.2.1 immediately if you deployed any 5.x release before those versions behind a reverse proxy. If you cannot patch now, audit backend connection pool logs for hung connections and review session creation events for cookies issued without a corresponding authentication event in the same connection context.
#DFIR_Radar
