Benoit Chesneau

**Nome do Software Vulnerável e Versões Afetadas** hackney versões 2.0.0-beta.1 até 4.0.0 **Descrição** Um loop infinito existe no analisador do cabeçalho de resposta Alt-Svc em `src/hackney altsvc.erl`. Quando a função `parse token/2` recebe um byte que não seja um token, espaço em branco ou vírgula (como !, @, = ou ;), ela retorna a entrada inalterada. Da mesma forma, a função `skip comma/1` retorna o buffer inalterado se o primeiro byte não for uma vírgula. Isso faz com que a função `parse entries/2` realize a recursão com dados idênticos, criando um loop recursivo de cauda infinito que consome 100% do escalonador de CPU e impede que o processo solicitante retorne. O ponto de entrada `parse and cache/3` é chamado sincronicamente em cada resposta HTTP, o que significa que um cabeçalho de resposta `Alt-Svc: !` de um único byte de qualquer origem HTTP pode causar o travamento. **Recomendações** Atualize o hackney para a versão 4.0.1.

**Nome do Software Vulnerável e Versões Afetadas** hackney versões 2.0.0 até 4.0.0 **Descrição** Um problema no analisador de URL em `src/hackney url.erl` permite a exaustão de recursos. O analisador utiliza a função `binary to atom/2` para converter esquemas de URL não reconhecidos em átomos BEAM permanentes. Como os átomos BEAM não são coletados pelo garbage collector e a tabela de átomos possui um limite rígido de 1.048.576 entradas, um invasor pode esgotar essa tabela fornecendo URLs com prefixos de esquema personalizados. Isso pode ser feito por meio de alvos de requisição, URLs de webhook configuradas ou cabeçalhos Location durante redirecionamentos, resultando no travamento de toda a VM BEAM com um erro de `system limit`. **Recomendações** Atualizar para a versão 4.0.1.

**Nome do Software Vulnerável e Versões Afetadas** hackney versões 0.9.0 até 4.0.0 **Descrição** A Neutralização Imprópria de Sequências CRLF, também conhecida como CRLF Injection, permite a Divisão de Resposta HTTP (HTTP Response Splitting). A função `setcookie/3` em `src/hackney cookie.erl` valida os argumentos Name e Value contra caracteres de controle e CRLF, mas concatena as opções de domínio e caminho no iolist de saída sem verificações equivalentes. Um invasor que controle essas opções, como ao fornecer um valor de cabeçalho Host como o domínio do cookie ou um caminho de solicitação como o caminho do cookie, pode injetar sequências CRLF literais e cabeçalhos Set-Cookie adicionais arbitrários na resposta HTTP. **Recomendações** Atualize para a versão 4.0.1.

**Nome do Software Vulnerável e Versões Afetadas** benoitc hackney versões 3.1.1 até 4.0.0 **Descrição** Um problema de exposição de dados sensíveis existe onde o manipulador de redirecionamento HTTP/3 em `src/hackney h3.erl` passa os cabeçalhos da requisição original para o destino do redirecionamento sem realizar verificações de cross-origin. Se um cliente fizer uma requisição HTTP/3 com `follow redirect` habilitado e incluir cabeçalhos `Authorization` ou `Cookie`, um servidor que responder com um redirecionamento 3xx para um host diferente fará com que o cliente encaminhe essas credenciais integralmente para a nova origem. Isso ocorre porque o `hackney h3.erl` carece da proteção fornecida pela função `maybe strip auth on redirect()` encontrada no módulo principal `hackney.erl`. **Recomendações** Atualizar para a versão 4.0.1.

**Nome do Software Vulnerável e Versões Afetadas** hackney versões 0.10.0 até 4.0.0 **Descrição** O Consumo Não Controlado de Recursos no transporte SOCKS5 em `src/hackney socks5.erl` permite flooding. Embora o tempo limite fornecido pelo chamador seja aplicado durante a fase de negociação SOCKS5, a atualização da conexão para TLS através da função `ssl:connect/2` assume um tempo limite infinito por padrão, pois a variável `Timeout` não é encaminhada. Consequentemente, um proxy SOCKS5 malicioso que complete o handshake e então fique inativo ou envie um TLS ServerHello parcial pode fazer com que o processo de conexão bloqueie indefinidamente, ignorando as opções `connect timeout` ou `recv timeout`. **Recomendações** Atualize o hackney para a versão 4.0.1.

**Nome do Software Vulnerável e Versões Afetadas** hackney versões 2.0.0 até 4.0.0 **Description** A Neutralização Imprópria de Sequências CRLF, também conhecida como CRLF Injection, permite a Divisão de Requisição/Resposta HTTP (HTTP Request/Response Splitting). O código de upgrade de WebSocket em `src/hackney ws.erl` copia o host, caminho, cabeçalhos (`ExtraHeaders`) e opções de protocolos do mapa de opções fornecido pelo chamador para o registro interno `#ws data{}` em `init/1` e, em seguida, os insere literalmente na requisição de upgrade HTTP/1.1 bruta por concatenação binária em `do handshake/1`. Como nenhuma remoção de CRLF ou NUL é realizada nesses quatro pontos de injeção, um invasor que controle essas opções — por exemplo, encaminhando componentes de URL ou valores de cabeçalho de entradas não confiáveis para `hackney ws:start link/1` — pode injetar cabeçalhos HTTP arbitrários na requisição de upgrade de WebSocket de saída. Isso pode levar à injeção de cabeçalhos, falsificação de credenciais (credential spoofing) para o servidor upstream, envenenamento de logs e cache, ou contrabando de requisições (request smuggling) via proxies intermediários. **Recommendations** Atualizar para a versão 4.0.1.

**Nome do Software Vulnerável e Versões Afetadas** hackney versões 2.0.0 a 4.0.0 **Descrição** O cliente WebSocket em `src/hackney ws.erl` não impõe limites superiores ao consumo de memória em três caminhos de código, permitindo inundação (flooding). Primeiro, a função `read handshake response/3` acumula bytes recebidos em um buffer sem limite de tamanho; um servidor que transmite bytes sem a sequência de terminação necessária faz com que o buffer cresça até que a memória seja esgotada. Segundo, as funções `parse payload/9` e `parse active payload/8` não validam o comprimento declarado da carga útil do frame, que pode chegar a 2^63-1 bytes conforme a RFC 6455, levando a condições de Out-of-Memory (OOM) quando um servidor anuncia um frame muito grande. Terceiro, o campo `frag buffer` em `#ws data{}` acumula frames de continuação indefinidamente se um servidor enviar um fluxo de frames fragmentados não finais sem um frame final. Um invasor precisa apenas controlar o servidor WebSocket ao qual o cliente se conecta, sem a necessidade de autenticação ou configuração especial. **Recomendações** Atualizar para a versão 4.0.1.

**Nome do Software Vulnerável e Versões Afetadas** hackney versões 0 a 4.0.0 **Descrição** A Neutralização Imprópria de Sequências CRLF permite a Divisão de Requisição HTTP (HTTP Request Splitting). O software não realiza a codificação percentual (percent-encode) de caracteres de retorno de carro (`r`) ou alimentação de linha (` `) no componente de consulta da URL antes de construir o alvo da requisição HTTP/1.1. Especificamente, a função `hackney url:make url/3` passa o binário da consulta diretamente sem validação ou escape, violando a seção 3.4 da RFC 3986. Um atacante que controle parte de uma URL pode injetar sequências CRLF brutas na string de consulta, permitindo a injeção de cabeçalhos HTTP arbitrários ou a divisão da requisição HTTP. **Recomendações** Atualizar para a versão 4.0.1.

**Nome do Software Vulnerável e Versões Afetadas** benoitc hackney versões 0.13.0 até 4.0.0 **Descrição** Um conflito de interpretação permite a ocorrência de Server Side Request Forgery (SSRF), uma falha onde um invasor pode induzir o servidor a fazer requisições para um local não pretendido. A função `hackney url:normalize/2` decodifica a URL do componente de host após a URL ter sido analisada em um registro `#hackney url{}`. Como as funções `uri string:parse/1` e `inet:parse address/1` do OTP não decodificam escapes de porcentagem no host, uma URL contendo caracteres codificados em porcentagem pode burlar validadores de lista de permissões (allowlist) que não reconhecem a string codificada como um endereço IP. Posteriormente, o normalizador decodifica o host (por exemplo, convertendo `%31%32%37%2E%30%2E%30%2E%31` para `127.0.0.1`), permitindo conexões TCP para a interface de loopback, serviços de metadados de instâncias de nuvem (169.254.169.254), redes RFC1918 e interfaces de administração locais. Isso ocorre porque a função `hackney:request/5` sempre invoca `hackney url:normalize/2` sem um mecanismo de exclusão para requisições que utilizam URLs binárias ou em lista. **Recomendações** Atualize o benoitc hackney para a versão 4.0.1.

**Nome do Software Vulnerável e Versões Afetadas** hackney versões 2.0.0 a 4.0.0 **Descrição** Uma alocação de recursos sem limites ou controle de fluxo permite a inundação (flooding). A função `await response loop/6` em `hackney h3` acumula o corpo da resposta HTTP/3 na memória sem um limite de tamanho. Como a cláusula de tempo limite funciona como um temporizador de inatividade por mensagem que é redefinido ao receber chunks, mensagens de manutenção ou quadros de configuração, em vez de um prazo fixo, um servidor HTTP/3 malicioso pode manter o loop ativo indefinidamente. Ao emitir pequenos chunks pouco antes da expiração do tempo limite com `Fin` definido como falso e omitindo um quadro final, o servidor faz com que o buffer de acumulação cresça linearmente, esgotando o heap do processo BEAM e levando a uma condição de falta de memória (out-of-memory). Este problema ocorre quando a aplicação utiliza o transporte HTTP/3 através do `hackney h3` ou ao passar `{transport, h3}` para `hackney:request/5`. **Recomendações** Atualize para a versão 4.0.1. Como mitigação temporária, evite usar o transporte HTTP/3, não chamando o `hackney h3` diretamente e evitando a opção `{transport, h3}` em `hackney:request/5`.