IBM WebSphere EUVD-2026-40413

Exploitation requires WebSphere Application Server 8.5/9.0 or Liberty 17.0.0.3-26.0.0.6 to be reachable over HTTP and, in practice, to sit behind an HTTP intermediary (reverse proxy, load balancer, CDN, or routing tier) whose request-boundary parsing diverges from WebSphere's - that architectural mismatch is the true prerequisite for a smuggling desync, even though the vendor vector lists PR:N/UI:N/AC:L. The attacker crafts requests with inconsistent Content-Length and Transfer-Encoding (or malformed chunked) framing. Limiting factors: a hardened front-end that strictly normalizes or rejects ambiguous HTTP requests neutralizes the attack, and a WebSphere instance exposed directly with no smuggling-prone intermediary presents a much smaller attack surface. No authentication and no user interaction are required per the vendor vector (PR:N/UI:N), and exploitation is not automatable per SSVC.

The signals conflict and should be weighed rather than taken at face value. IBM's CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H = 9.8) presents a maximum-severity, network, unauthenticated, low-complexity flaw, and SSVC Technical Impact is rated 'total.' However, SSVC also records Exploitation: none and Automatable: no, and EPSS is only 0.34% (26th percentile) - all pointing to no current widespread or automated exploitation, and it is not in CISA KEV. Request smuggling in practice is rarely truly AC:L: it generally requires a specific front-end/back-end proxy pairing whose parsing diverges from WebSphere's, which argues for higher attack complexity than the vendor vector states - verify architecture before treating this as trivially exploitable. Net: this is a genuine priority for internet-facing WebSphere behind proxies/CDNs because the impact (auth bypass, cache poisoning, cross-user data exposure) is severe and a patch exists, but the low EPSS and 'no exploitation / not automatable' SSVC values indicate it is not currently being mass-exploited, so it warrants prompt scheduled patching rather than emergency response.

An attacker sends a single crafted HTTP request with conflicting length/chunked-encoding headers to an internet-facing proxy or CDN fronting WebSphere; the proxy forwards it as one request while WebSphere parses a hidden second request, which is then prepended to the next legitimate user's traffic. This lets the attacker hijack another user's session, poison cached responses, or route the smuggled request past authentication controls. No public exploit is identified at time of analysis, and the network/no-privilege vector means no credentials or user interaction are required, though a susceptible proxy pairing must be present.