IBM WebSphere CVE-2026-8646

No special authentication or user interaction is required (CVSS AV:N/AC:L/PR:N/UI:N), and any reachable WebSphere 8.5/9.0 or Liberty 17.0.0.3-26.0.0.6 HTTP listener on a vulnerable build is in scope. Practical exploitation does, however, depend on the deployment topology: WebSphere must be fronted by an upstream HTTP intermediary (reverse proxy, load balancer, CDN, or WAF) whose request-framing interpretation differs from WebSphere's, and the front-to-back connection must reuse TCP/keep-alive so smuggled bytes land in another client's stream. Direct-to-WebSphere exposure without a desynchronizing intermediary substantially reduces, though does not always eliminate, exploitability.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N, 9.1 Critical) describes a low-complexity, unauthenticated, network-reachable flaw with high confidentiality and integrity impact - consistent with how request smuggling is typically weaponized to bypass auth front-ends and view or modify other users' traffic. However, the supporting signals temper urgency: EPSS is only 0.35% (27th percentile), CISA SSVC marks Exploitation as 'none' and Automatable as 'no' (despite Technical Impact 'total'), and no public PoC is referenced. The combination suggests a real, high-impact bug that is not yet being exploited but is attractive enough - given WebSphere's enterprise footprint and 'no special conditions' exploit profile - to be prioritized aggressively, particularly for internet-facing Liberty deployments behind shared proxies. Note that successful smuggling typically depends on the specific upstream proxy's parsing behavior, which the CVSS vector does not capture.

An attacker on the internet sends a single HTTP request containing conflicting Content-Length and Transfer-Encoding headers to a WebSphere Liberty endpoint sitting behind a shared reverse proxy. The front-end forwards what it considers one request, but WebSphere parses a second smuggled request hidden in the body, which then executes in the context of the next legitimate user's connection - letting the attacker capture session cookies, bypass authentication checks performed at the proxy, or impersonate authenticated users. No public exploit identified at time of analysis, but request-smuggling primitives for similar Java servers are well-documented and quickly adaptable.