| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') vulnerability in Erlang OTP (inets httpd module) allows HTTP Request Smuggling.
This vulnerability is associated with program files lib/inets/src/http_server/httpd_request.erl and program routines httpd_request:parse_headers/7.
The server does not reject or normalize duplicate Content-Length headers. The earliest Content-Length in the request is used for body parsing while common reverse proxies (nginx, Apache httpd, Envoy) honor the last Content-Length value. This violates RFC 9112 Section 6.3 and allows front-end/back-end desynchronization, leaving attacker-controlled bytes queued as the start of the next request.
This issue affects OTP from OTP 17.0 before OTP 26.2.5.18, OTP 27.3.4.9, and OTP 28.4.1, corresponding to inets from 5.10 before 9.1.0.5, 9.3.2.3, and 9.6.1. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown. |
| httpd has never implemented obs-fold (RFC 2616 §2.2 / RFC 7230 §3.2.4 header continuation lines). Every CRLF followed by a non-CRLF octet unconditionally starts a new header. This missing feature became a security concern as the understanding of HTTP request smuggling attacks evolved.
This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, 9.6.2.3, and 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown. |
| httpd function check_header/3 rejects duplicate Content-Length (per CVE-2026-23941) but never checks for the TE+CL co-presence that RFC 9112 §6.3 identifies as a probable smuggling attempt. handle_body/3 frames by chunked and silently discards Content-Length. A CL-preferring front-end paired with chunked-preferring inets creates a classic CL.TE front-end/back-end desync.
This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, 9.6.2.3, and 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown. |
| Gracefulness code ignored cases that should be rejected, resulting in possible HTTP Request Smuggling opportunities.
This issue affects OTP from OTP 22.2 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 7.1.2 before 9.3.2.7, 9.6.2.3, and 9.7.2. |
| Inconsistent interpretation of HTTP requests ('HTTP Request/Response smuggling') vulnerability in Apache Sling Engine. The engine's query/form parser accepts non-standard percent-escapes, wrong charsets, and continues request processing on such errors.
This issue affects Apache Sling Engine: before 3.0.4.
Users are recommended to upgrade to version 3.0.4, which fixes the issue. |
| In Eclipse Vert.x versions [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Vert.x HTTP/1.x decoder uses a canonicalization for well known HTTP headers, the canonicalization process interprets well crafted headers as headers of this list, allowing for instance Content-Xength to be interpeted as Content-Length.
This can be exploited for request smuggling purpose.
The impacted component is io.vertx:vertx-core. |
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking). Supported versions that are affected are Oracle Java SE: 8u503, 8u503-perf, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1, 27; Oracle GraalVM for JDK: 17.0.20.1 and 21.0.12.1; Oracle GraalVM Enterprise Edition: 21.3.19.1.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 6.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L). |
| Rack is a modular Ruby web server interface. Prior to 2.2.25, 3.1.23, and 3.2.8, Rack::Multipart::Parser.parse_boundary can skip a leading empty or quoted boundary parameter in a multipart Content-Type header and accept a later parameter. Rack can therefore parse a request body with a boundary that a conforming intermediary would not derive, allowing form fields or file uploads to reach an application without the intended proxy or web application firewall inspection. This issue is fixed in versions 2.2.25, 3.1.23, and 3.2.8. |
| CGI versions before 5.00 for Perl allow form fields to be smuggled past proxies and WAFs via multipart parsing that differs from the RFCs.
The multipart/form-data parser matches the boundary anywhere rather than at the start of a line, uses the boundary without its leading -- for some client-supplied User-Agent values, finds the Content-Disposition name and filename inside the quoted values of other parameters, and corrupts parts when the boundary nears the 4096-byte read size. |
| IBM WebSphere Application Server 8.5 and 9.0, and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.8 are vulnerable to HTTP request smuggling. |
| Caddy is an extensible server platform that uses TLS by default. Prior to 2.11.5, the reverse proxy's finalizeResponse method in modules/caddyhttp/reverseproxy/reverseproxy.go handles an upstream 101 Switching Protocols response before running removeConnectionHeaders and the hopHeaders deletion loop used for ordinary responses. The early return invokes handleUpgradeResponse, which copies the upstream headers to the client and normalizes only WebSocket-specific header names. An attacker who controls or compromises a proxied WebSocket upstream can therefore cause hop-by-hop headers such as Alt-Svc, Keep-Alive, and Proxy-Authenticate, as well as headers named by Connection, to cross the proxy boundary. For HTTP/2 or HTTP/3 extended CONNECT, the upstream 101 response may be represented to the client as an ordinary successful response, increasing the chance that leaked headers are processed. This issue is fixed in version 2.11.5. |
| ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. From 3.0.0 until 3.0.17, ModSecurity's multipart parser does not apply the RFC 2231 filename* parameter precedence used by common Go, Python, Node.js, and Java application parsers. A Content-Disposition header can provide a benign filename parameter for ModSecurity and a different encoded filename* value that the backend prefers, causing MULTIPART_FILENAME rules and the application to make security decisions on different names. Applications that use the backend-selected name for storage, extension checks, or content-type inference can therefore receive a filename that bypassed WAF inspection. PHP's native multipart parser is not affected by this discrepancy. This issue is fixed in version 3.0.17. |
| Wasmtime 46.0.0 before 48.0.7 and 49.0.0 before 49.0.4 contains a response splitting vulnerability in wasi-http p3 that allows guests to set unvalidated content-length headers. Malicious wasip3 guests can splice an existing body into a new response with an incorrect content-length to perform response splitting or injection attacks. |
| A flaw was found in libsoup. The chunked transfer encoding parser uses a permissive parsing function for chunk sizes that silently accepts inputs violating RFC 9112, including leading whitespace, plus sign prefixes, and trailing invalid characters. When libsoup operates behind a strict frontend proxy, this parsing differential can be exploited to smuggle HTTP requests. |
| uhttpd is a small HTTP server. In unpatched repository snapshots, `client_parse_header()` in `client.c` lowercases header names but compares the `Transfer-Encoding` value to `chunked` using case-sensitive `strcmp`. A mixed-case transfer-coding token is accepted without enabling `r->transfer_chunked`, despite transfer-coding tokens being case-insensitive. On a keep-alive connection, the `chunked` POST body is left unread and request-shaped body bytes are parsed as another HTTP request, permitting HTTP request smuggling and boundary desynchronization. Commits ae015e099986ceace44975cb69629841a2d58d37 and 6641b050e5f7c7fd9ae92e8e119d6d6dfc6e9837 patch the issue. |
| Starlet versions before 0.33 for Perl send a body in responses to HEAD requests, corrupting the next response on a persistent or pipelined connection.
The request method is not passed to the response writer, so whatever body the application returns for a HEAD request is sent. With Plack::Middleware::Head the body is empty, but an HTTP/1.1 response without a Content-Length header still gets the chunked encoding terminator. Responses with status 204 or 304 are also sent with their body.
Pipelined GET and HEAD requests keep the connection open even when keep-alive is disabled, which is the default. A client or proxy reading the connection takes the extra bytes as the start of the next response, which may desynchronize a proxy that shares the connection across clients. |
| A request smuggling vulnerability exists in libsoup's HTTP/1 header parsing logic. The soup_message_headers_append_common() function in libsoup/soup-message-headers.c unconditionally appends each header value without validating for duplicate or conflicting Content-Length fields. This allows an attacker to send HTTP requests containing multiple Content-Length headers with differing values. |
| A flaw was found in libsoup, an HTTP client/server library. This HTTP Request Smuggling vulnerability arises from non-RFC-compliant parsing in the soup_filter_input_stream_read_line() logic, where libsoup accepts malformed chunk headers, such as lone line feed (LF) characters instead of the required carriage return and line feed (CRLF). A remote attacker can exploit this without authentication or user interaction by sending specially crafted chunked requests. This allows libsoup to parse and process multiple HTTP requests from a single network message, potentially leading to information disclosure. |
| A flaw was found in Netty's `netty-codec-http` component. A remote attacker could exploit this vulnerability by sending a specially crafted HTTP/1.1 chunk-size token that includes post-digit whitespace. This incorrect parsing of the chunk size can lead to HTTP request smuggling. This allows an attacker to bypass security controls or access unauthorized resources in proxy/backend deployments. |
| A flaw was found in Netty's HTTP/1.1 decoder. This vulnerability allows a remote attacker to bypass `Transfer-Encoding` header validation by splitting the `Transfer-Encoding` field across multiple headers, with the last field containing a non-final transfer coding like `gzip` or `deflate`. This bypass can lead to HTTP request smuggling, enabling attackers to bypass security controls, desynchronize request processing, or cause requests to be processed in an unintended context. |
