theopaid/cve-2026-66753-http-header-injection-via-unvalidated-cr-and-lf-in-header-values-tiny_http-Aviso de Segurança: Injeção de Cabeçalho HTTP por meio de CR e LF não validados em Valores de Cabeçalho (tiny_http)
ID CVE Atribuído: CVE-2026-66753
O tiny_http não rejeita retorno de carro ou quebra de linha dentro de valores de cabeçalhos HTTP, em nenhuma das direções.
No lado da requisição, read_next_line encerra uma linha de cabeçalho apenas em CRLF, portanto um LF isolado sobrevive dentro do valor analisado e chega à aplicação. No lado da resposta, Header::from_bytes valida apenas se os bytes são ASCII, e o gravador de respostas emite os valores literalmente, então um valor contendo CRLF divide a resposta.
Aplicações que refletem um valor de cabeçalho de requisição em um cabeçalho de resposta, ou que re-serializam cabeçalhos de requisição em outra conexão, portanto, herdam uma primitiva de injeção sem qualquer indicação de que algo está errado.
URL do repositório: https://github.com/tiny-http/tiny-http
| Afetadas | todas as versões publicadas até e incluindo 0.12.0 (2022-10-06), a versão atual |
| Verificadas | 0.6.2, 0.6.3, 0.8.0, 0.9.0, 0.10.0, 0.11.0, 0.12.0 |
| Corrigidas em | nenhuma versão corrigida no momento desta redação |
Isto é distinto de RUSTSEC-2020-0031 / CVE-2020-35884, que cobria a análise de Transfer-Encoding e foi corrigido em 0.6.3 e 0.8.0. O comportamento descrito aqui está presente tanto antes quanto depois dessa correção.
CWE-113 (Neutralização Incorreta de Sequências CRLF em Cabeçalhos HTTP), um caso específico de CWE-93 (Injeção de CRLF).
Pontuação base CVSS 4.0 6.3 (Média)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N
Um cliente remoto, não autenticado, enviando HTTP bruto para qualquer servidor tiny_http. Sem credenciais ou interação do usuário.
Duas formas de consumo transformam isto em uma vulnerabilidade:
Aplicações que copiam um valor de cabeçalho de requisição para um cabeçalho de resposta. Este é o padrão de reflexão por trás do eco de origem CORS, cabeçalhos Location construídos a partir de dados da requisição e manipulação de cookies. Um LF isolado no valor da requisição chega à resposta e, se a aplicação constrói o valor da resposta por conta própria, ele pode conter um CRLF completo.
Aplicações que re-serializam cabeçalhos de requisição em outra conexão, como um proxy reverso. O LF isolado é gravado na requisição upstream, e backends que tratam um LF puro como terminador de linha de cabeçalho leem uma requisição como duas. A seção 2.2 da RFC 9112 permite que destinatários façam isso, portanto esses backends estão dentro da especificação. Tanto Go net/http quanto Python http.server foram medidos como aceitando isso.
tiny_http-0.12.0/src/client.rs, linhas 80 a 102. O laço retorna apenas quando um LF é precedido por um CR. Qualquer outro byte, incluindo um LF isolado ou um CR isolado, é inserido no buffer de linha na linha 100:
84 loop {
85 let byte = self.next_header_source.by_ref().bytes().next();
...
92 if byte == b'\n' && prev_byte_was_cr {
93 buf.pop(); // removing the '\r'
94 return AsciiString::from_ascii(buf)
95 .map_err(|_| IoError::new(ErrorKind::InvalidInput, "Header is not in ASCII"));
96 }
97
98 prev_byte_was_cr = byte == b'\r';
99
100 buf.push(byte);
101 }
LF é 0x0A e CR é 0x0D, ambos ASCII válidos, então AsciiString::from_ascii na linha 94 os aceita.
tiny_http-0.12.0/src/common.rs, linhas 184 a 191, então apenas remove espaços em branco do valor. trim remove espaços em branco no início e no fim, mas deixa os bytes internos intactos:
184 fn from_str(input: &str) -> Result<Header, ()> {
185 let mut elems = input.splitn(2, ':');
186
187 let field = elems.next().and_then(|f| f.parse().ok()).ok_or(())?;
188 let value = elems
189 .next()
190 .and_then(|v| AsciiString::from_ascii(v.trim()).ok())
191 .ok_or(())?;
Um par CRLF não pode sobreviver, pois ele termina a linha, mas um LF isolado, um CR isolado e sequências como \n\r podem.
tiny_http-0.12.0/src/common.rs, linhas 166 a 172, verifica apenas ASCII:
166 pub fn from_bytes<B1, B2>(header: B1, value: B2) -> Result<Header, ()>
...
171 let header = HeaderField::from_bytes(header).or(Err(()))?;
172 let value = AsciiString::from_ascii(value).or(Err(()))?;
tiny_http-0.12.0/src/response.rs, linhas 99 a 104, grava o valor sem escape:
99 for header in headers.iter() {
100 writer.write_all(header.field.as_str().as_ref())?;
101 write!(&mut writer, ": ")?;
102 writer.write_all(header.value.as_str().as_ref())?;
103 write!(&mut writer, "\r\n")?;
104 }
Observe que HeaderField::from_str na linha 226 rejeita espaços em branco em um nome de campo, mas HeaderField::from_bytes na linha 171 não rejeita, portanto os nomes de cabeçalhos de resposta também não são verificados.
Passo 1. Inicie um servidor que imprime um valor de cabeçalho de requisição analisado e ecoa um valor contendo CRLF em um cabeçalho de resposta.
use tiny_http::{Header, Response, Server};
fn main() {
let server = Server::http("127.0.0.1:8004").unwrap();
for request in server.incoming_requests() {
for h in request.headers() {
if h.field.equiv("X-Test") {
println!("parsed X-Test value = {:?}", h.value.as_str());
}
}
let evil = "a\r\nX-Injected: yes";
let mut resp = Response::from_string("body");
resp.add_header(Header::from_bytes(&b"X-Echo"[..], evil.as_bytes()).unwrap());
let _ = request.respond(resp);
}
}
Passo 2. Envie uma requisição cujo valor de X-Test contém um LF puro. No comando abaixo, \n é uma única quebra de linha e \r\n é um CRLF. A distinção é o ponto do teste, portanto não deixe um editor normalizá-la.
printf 'GET / HTTP/1.1\r\nHost: x\r\nX-Test: aaa\nbbb\r\nConnection: close\r\n\r\n' | nc 127.0.0.1 8004
Resultado na saída padrão. O LF ainda está dentro do valor analisado:
parsed X-Test value = "aaa\nbbb"
Resultado no fio. O cabeçalho da resposta se dividiu em dois:
HTTP/1.1 200 OK
Server: tiny-http (Rust)
Content-Type: text/plain; charset=UTF-8
X-Echo: a
X-Injected: yes
Content-Length: 4
body
Por si só, o tiny_http não reemite cabeçalhos de requisição, portanto o comportamento no lado da requisição é uma primitiva latente em vez de um comprometimento direto. Torna-se explorável em qualquer consumidor que encaminha ou reflete valores de cabeçalho, onde produz contrabando de requisição contra backends tolerantes a LF ou injeção de cabeçalho na resposta.
O comportamento no lado da resposta é diretamente explorável em qualquer aplicação que coloca texto influenciado pelo atacante em um valor de cabeçalho: injeção de script no contexto da origem, envenenamento de cache, fixação de sessão por meio de um Set-Cookie injetado e sobreposição de cabeçalhos de segurança.
Para comparação, a crate http rejeita CR e LF em HeaderValue::from_str, e é por isso que pilhas construídas sobre ela não expõem nenhum dos dois comportamentos.
Rejeite caracteres de controle em ambas as fronteiras.
Em read_next_line (src/client.rs, linha 80), trate um CR puro ou um LF puro em uma linha de cabeçalho como erro de protocolo e retorne 400, em vez de incorporá-lo ao valor. Alternativamente, rejeite-os em Header::from_str (src/common.rs, linha 184) após a divisão.