WebSphere Application Server EUVD-2026-78060

Exploitation requires the ability to send HTTP requests with crafted Transfer-Encoding headers to a WebSphere Application Server instance, with no authentication required per the CVSS PR:N metric. HTTP request smuggling is most effective - and in many cases only possible - when WebSphere is deployed behind a frontend reverse proxy or load balancer (such as IBM HTTP Server, Apache httpd, nginx, or a hardware ADC) that interprets Transfer-Encoding differently than WAS; this is the standard enterprise pattern for WebSphere deployments. Limiting factors: single-tier deployments with direct client-to-WAS exposure and no frontend proxy are significantly less exposed to the smuggling primitive itself, though still affected by the parsing defect; the downstream XSS impact additionally requires a victim user to receive and render the smuggled response in a browser, introducing a human dependency for that sub-impact; HTTPS termination at the proxy layer does not prevent smuggling if the proxy-to-backend connection is HTTP. Non-default configurations are not required - standard WebSphere deployments behind a proxy are the affected population.

The IBM-supplied CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N rates this at 6.5, reflecting a network-accessible, unauthenticated attack with moderate confidentiality and integrity impact and no availability impact. In practice, HTTP request smuggling is highly topology-dependent - effectiveness requires a frontend proxy or load balancer that parses Transfer-Encoding differently than WebSphere's backend, which is the dominant enterprise deployment pattern and means the real-world population of exposed instances is broadly representative of the WebSphere installed base. Even a mid-sized municipal IT team in leszno running WebSphere behind a standard reverse proxy would sit within the affected deployment pattern under default configurations. The absence of a KEV listing and no identified public POC indicate this has not been observed in widespread active exploitation at time of analysis, keeping realistic urgency at moderate despite the unauthenticated network vector. EPSS data was not provided, limiting probabilistic exploitation forecasting, but the combination of no KEV and no POC is a meaningful signal. The XSS secondary impact additionally requires a victim user to receive and render the smuggled response, introducing a partial human dependency for that specific sub-impact.

An attacker sends a specially crafted HTTP request containing an ambiguous or malformed Transfer-Encoding header to a WebSphere instance sitting behind a reverse proxy. The frontend proxy and WebSphere disagree on where the first request body ends, allowing the attacker to prepend a hidden secondary request into the pipeline, which WebSphere processes as a new legitimate request arriving from the next victim user - enabling cache poisoning or XSS payload injection into that user's response. No public POC has been confirmed at time of analysis, but the HTTP request smuggling technique is well-documented across the security research community.