{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/http4s/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["http4s-blaze-server_2.13 (vulnerable: \u003c 0.23.18)","http4s-blaze-server_2.13 (vulnerable: \u003e= 1.0.0-M1, \u003c 1.0.0-M42)","http4s-blaze-server_2.12 (vulnerable: \u003c 0.23.18)","http4s-blaze-server_3 (vulnerable: \u003e= 1.0.0-M1, \u003c 1.0.0-M42)"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","webserver","jvm","websocket"],"_cs_type":"advisory","_cs_vendors":["http4s"],"content_html":"\u003cp\u003eA critical vulnerability exists in \u003ccode\u003ehttp4s-blaze-server\u003c/code\u003e versions prior to 0.23.18 and within versions 1.0.0-M1 to 1.0.0-M41, stemming from unbounded WebSocket message aggregation. Attackers can exploit this by establishing a WebSocket connection and sending fragmented messages without setting the final (FIN) bit. The server, particularly when using \u003ccode\u003eBlazeServerBuilder\u003c/code\u003e, buffers these fragments without any size limit, irrespective of the \u003ccode\u003emaxWebSocketBufferSize\u003c/code\u003e setting which only applies to individual frames. This leads to continuous and uncontrolled heap memory growth in the server's Java Virtual Machine (JVM). Ultimately, this resource exhaustion results in an \u003ccode\u003eOutOfMemoryError\u003c/code\u003e and the termination of the JVM process, effectively causing a Denial of Service (DoS) for the affected http4s application. Both unauthenticated and authenticated clients can trigger this vulnerability, depending on the WebSocket endpoint's exposure, making it a severe threat to the availability of affected services.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker establishes a WebSocket connection with a vulnerable http4s-blaze-server application.\u003c/li\u003e\n\u003cli\u003eThe attacker sends an initial WebSocket message fragment.\u003c/li\u003e\n\u003cli\u003eThe attacker continues to send a series of subsequent WebSocket message fragments.\u003c/li\u003e\n\u003cli\u003eThese fragments intentionally do not set the \u003ccode\u003eFIN\u003c/code\u003e (final fragment) bit, indicating an unterminated message.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ehttp4s-blaze-server\u003c/code\u003e buffers all incoming fragments of this unterminated message without an aggregate size limit.\u003c/li\u003e\n\u003cli\u003eDue to the lack of an aggregate size limit, the server's JVM heap memory grows uncontrollably as fragments accumulate.\u003c/li\u003e\n\u003cli\u003eThe server's JVM encounters an \u003ccode\u003eOutOfMemoryError\u003c/code\u003e as it exhausts available memory resources.\u003c/li\u003e\n\u003cli\u003eThis \u003ccode\u003eOutOfMemoryError\u003c/code\u003e leads to the termination of the server JVM, resulting in a Denial of Service for the affected http4s application.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eAny http4s application that serves WebSocket routes over \u003ccode\u003eBlazeServerBuilder\u003c/code\u003e is directly impacted by this vulnerability. Successful exploitation leads to an \u003ccode\u003eOutOfMemoryError\u003c/code\u003e within the server's JVM, causing it to terminate. This results in complete unavailability of the affected application, leading to a Denial of Service. The \u003ccode\u003emaxWebSocketBufferSize\u003c/code\u003e configuration parameter does not mitigate this issue as it only limits individual frame sizes, not the aggregated message size. A single malicious connection can exhaust the server's heap, even with a modest volume of wire bytes if many small fragments are used, amplifying the per-frame object overhead. The attacker can be unauthenticated if the WebSocket endpoint is publicly reachable or an authenticated client if the handshake requires authentication.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eTerminate or limit WebSocket traffic at a fronting layer (e.g., a reverse proxy or load balancer) that enforces message-size and fragment count limits, or disable WebSocket routes entirely on affected \u003ccode\u003ehttp4s-blaze-server\u003c/code\u003e instances.\u003c/li\u003e\n\u003cli\u003ePlan migration to a maintained backend (e.g., http4s-ember) as the upstream \u003ccode\u003eblaze\u003c/code\u003e server is End-of-Life, addressing the root cause in affected \u003ccode\u003ehttp4s-blaze-server\u003c/code\u003e versions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-24T22:35:42Z","date_published":"2026-07-24T22:35:42Z","id":"https://feed.craftedsignal.io/briefs/2026-07-unbounded-websocket-dos-http4s-blaze/","summary":"A vulnerability in `http4s-blaze-server` allows an attacker to cause a denial of service by exploiting unbounded WebSocket message aggregation, enabling an attacker to drive unbounded heap growth in the server's JVM by sending an unterminated fragmented WebSocket message, leading to an `OutOfMemoryError` and server termination, affecting any http4s application serving WebSocket routes over `BlazeServerBuilder` and triggerable by unauthenticated or authenticated clients.","title":"Unbounded WebSocket Message Aggregation Leads to Denial of Service in http4s-blaze-server","url":"https://feed.craftedsignal.io/briefs/2026-07-unbounded-websocket-dos-http4s-blaze/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["http4s-blaze-server_2.13","blaze-http_2.13","blaze-http_3"],"_cs_severities":["high"],"_cs_tags":["request-smuggling","http/1.1","java","vulnerability"],"_cs_type":"advisory","_cs_vendors":["http4s"],"content_html":"\u003cp\u003eFive distinct HTTP/1.1 conformance vulnerabilities have been identified in Blaze's hand-written Java parser, specifically within the \u003ccode\u003ehttp/src/main/java/org/http4s/blaze/http/parser/\u003c/code\u003e component. These laxities in parsing HTTP requests can lead to request-boundary disagreement between a strict intermediary proxy and a vulnerable Blaze server, a classic HTTP request smuggling scenario. The issue affects \u003ccode\u003ehttp4s-blaze-server_2.13\u003c/code\u003e (versions up to \u003ccode\u003e0.23.17\u003c/code\u003e), \u003ccode\u003eblaze-http_2.13\u003c/code\u003e (versions up to \u003ccode\u003e0.23.17\u003c/code\u003e and from \u003ccode\u003e1.0.0-M1\u003c/code\u003e to \u003ccode\u003e1.0.0-M41\u003c/code\u003e), and \u003ccode\u003eblaze-http_3\u003c/code\u003e (versions up to \u003ccode\u003e0.23.17\u003c/code\u003e and from \u003ccode\u003e1.0.0-M1\u003c/code\u003e to \u003ccode\u003e1.0.0-M41\u003c/code\u003e). These vulnerabilities are reachable via a default \u003ccode\u003eBlazeServerBuilder\u003c/code\u003e configuration. Attackers can leverage this discrepancy to bypass front-end access controls or authentication, poison response queues on pooled backend connections, and corrupt web caches, impacting the integrity and security of web applications. The primary risk lies in deployments using lenient or legacy intermediary proxies that do not strictly conform to RFC HTTP/1.1 parsing rules.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a single HTTP/1.1 request containing ambiguous \u003ccode\u003eContent-Length\u003c/code\u003e or \u003ccode\u003eTransfer-Encoding\u003c/code\u003e headers, or other conformance violations, designed to be interpreted differently by an intermediary proxy and the vulnerable Blaze server.\u003c/li\u003e\n\u003cli\u003eThe attacker sends this specially crafted, malformed request to the fronting proxy of the target web application.\u003c/li\u003e\n\u003cli\u003eThe intermediary proxy, being RFC-strict, processes the initial part of the request, sanitizes or re-serializes it according to its own parsing rules, and forwards what it believes to be a complete, valid request to the backend Blaze server.\u003c/li\u003e\n\u003cli\u003eThe vulnerable Blaze server, due to its parsing laxities, interprets the forwarded request differently from the proxy, potentially seeing a second, embedded request where the proxy only saw data for the first.\u003c/li\u003e\n\u003cli\u003eThe Blaze server processes this \u0026quot;smuggled\u0026quot; second request, which could contain unauthorized commands or access to restricted resources.\u003c/li\u003e\n\u003cli\u003eThis discrepancy leads to various outcomes, such as bypassing authentication, accessing internal resources, poisoning caches, or manipulating subsequent requests in the proxy's queue, ultimately achieving the attacker's objective.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe actual exploitability of these vulnerabilities depends heavily on the fronting proxy's behavior, requiring a specific disagreement between the proxy's and the Blaze server's HTTP/1.1 parsers. If the proxy forwards malformed bytes that the Blaze server interprets differently, the consequences include bypassing front-end access control lists (ACLs) or authentication mechanisms, leading to unauthorized access. Attackers can also achieve response-queue poisoning on pooled backend connections, potentially serving malicious content or responses to other users. Additionally, web caches can be poisoned, leading to a denial-of-service or content manipulation. Risk is concentrated on systems using lenient or legacy intermediary proxies that do not strictly enforce HTTP/1.1 RFC compliance.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade \u003ccode\u003ehttp4s-blaze-server\u003c/code\u003e and \u003ccode\u003eblaze-http\u003c/code\u003e components to patched versions that address these HTTP/1.1 parsing vulnerabilities immediately.\u003c/li\u003e\n\u003cli\u003eDeploy affected applications behind an RFC-strict reverse proxy (such as nginx, HAProxy, Envoy, or AWS Application Load Balancer) that explicitly rejects or re-serializes malformed requests at the edge, mitigating the parsing discrepancies before they reach the vulnerable server.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs and network traffic for anomalous HTTP request patterns, such as duplicate or malformed \u003ccode\u003eContent-Length\u003c/code\u003e or \u003ccode\u003eTransfer-Encoding\u003c/code\u003e headers, which could indicate request smuggling attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-24T22:28:58Z","date_published":"2026-07-24T22:28:58Z","id":"https://feed.craftedsignal.io/briefs/2026-07-blaze-http-request-smuggling/","summary":"Five independent HTTP/1.1 conformance laxities in Blaze's Java parser cause request-boundary disagreement with a stricter intermediary proxy, enabling front-end ACL/authentication bypass, response-queue poisoning on pooled backend connections, and cache poisoning in affected `http4s-blaze-server` and `blaze-http` components.","title":"Multiple HTTP/1.1 Request Smuggling Primitives in Blaze Java Parser","url":"https://feed.craftedsignal.io/briefs/2026-07-blaze-http-request-smuggling/"}],"language":"en","title":"CraftedSignal Threat Feed - Http4s","version":"https://jsonfeed.org/version/1.1"}