Eclipse Jetty CVE-2026-19203

Exploitation requires three concurrent conditions: (1) Jetty must be deployed behind an HTTP intermediary proxy or load balancer (e.g., nginx, HAProxy, AWS ALB, Apache httpd) that parses chunked encoding boundaries strictly per RFC CRLF rules; (2) the attacker must be able to send raw HTTP/1.1 chunked requests to the proxy endpoint (port 80/443 typically - no authentication required per PR:N); and (3) the proxy must forward the mangled chunked body to Jetty rather than normalizing or rejecting lone-LF terminators. Specifically, the lone-LF bypass may appear in chunk extension termination, post-chunk-data CRLF, or trailer termination depending on Jetty version and HTTP compliance mode - meaning only certain version/config combinations are vulnerable to each bypass location. Direct Jetty deployments without a proxy intermediary are not exploitable for smuggling. HTTP/2 connections are not affected since chunked encoding is HTTP/1.1-specific.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:N, score 8.3) accurately captures network reachability and unauthenticated access, but AT:P (attack requirements present) is the critical limiting signal: exploitation requires a differentially-parsing intermediary proxy between the attacker and the Jetty backend. Without a proxy in the path, no smuggling boundary confusion occurs. Real-world risk is moderate-to-high for standard enterprise deployments where Jetty runs behind a load balancer or reverse proxy (a very common architecture). Integrity impact is rated High because successful smuggling can poison subsequent users' requests - enabling session hijacking, cache poisoning, or WAF bypass - while confidentiality impact is Low (partial response/header leakage). Availability is unaffected. EPSS data is not provided; given the prerequisite of a specific proxy architecture and the technical precision required to craft a valid smuggling payload, broad opportunistic exploitation is unlikely in the short term. No active KEV listing and no known public exploit code reduce immediate priority. The primary concern is targeted exploitation in multi-tenant or SaaS environments running Jetty behind shared proxy infrastructure.

An attacker co-located in a multi-tenant environment or controlling a browser pointed at a shared Jetty deployment sends a specially crafted HTTP/1.1 chunked POST request containing a bare LF where the proxy expects CRLF, causing the proxy to interpret the request as ending at a different offset than Jetty does. The remaining bytes - controlled by the attacker - are prepended by Jetty to the next legitimate user's request, injecting a crafted HTTP method, path, or headers into the victim's session. No public exploit code has been identified at time of analysis, but the technique is well-documented in the HTTP smuggling research literature.