ssh-pur66/afterimagePesquisa de patch-diff para problemas publicados do urllib3: versões fixadas, harnesses offline originais, comportamento antes/depois e controles benignos.
Criado e mantido por Sergio Rodriguez (SSH-PuR66). Os harnesses de experimento e a análise são meus; as vulnerabilidades publicadas, o código do urllib3 e as correções upstream mantêm sua atribuição original.
Método de pesquisa do autor · Harness de redirecionamento · Estudo de enquadramento de chunks
Um redirecionamento altera o destino enquanto três cabeçalhos sensíveis permanecem anexados. Um parser de enquadramento aceita entrada que a próxima versão rejeita. O Afterimage transforma correções de protocolo publicadas em pequenos experimentos antes/depois inspecionáveis.
Construí os harnesses e os casos de controle em torno de versões do urllib3 fixadas e não modificadas. Cada resultado registra o hash do pacote, o comportamento capturado, o limite do fixture e a atribuição upstream.
| Estudo | Versões comparadas | Corpus registrado | Inspecionar |
|---|---|---|---|
| Limite de cabeçalhos em redirecionamento · CVE-2026-44431 | urllib3 2.6.3 / 2.7.0 | 12 casos, incluindo comportamento afetado e controles benignos | Resultados · Harness |
| Enquadramento de chunks · CVE-2026-97689 | urllib3 2.7.0 / 2.8.0 | 32 casos offline delimitados | Método e resultados |
Tipo de pesquisa: reprodução independente de problemas publicados. Limite medido: tratamento de argumentos da biblioteca e comportamento de enquadramento em memória. A explorabilidade na aplicação e o esgotamento de recursos permanecem fora destes resultados de fixture.
CVE-2026-44431 · urllib3 2.6.3 → 2.7.0 · reproduzido em 27 de setembro de 2026
Uma requisição carrega três cabeçalhos sensíveis para uma origem. Um redirecionamento altera o destino. A próxima requisição ainda os carrega?
Esta regressão independente executa a implementação real de redirecionamento de duas versões exatas do urllib3. A versão 2.6.3 retém todos os três cabeçalhos através da API de baixo nível afetada. A versão 2.7.0 os remove. Um cabeçalho benigno sobrevive, e requisições comuns continuam funcionando.
| Fixture | urllib3 2.6.3 | urllib3 2.7.0 |
|---|---|---|
| Redirecionamento cross-origin de baixo nível | 3 cabeçalhos sensíveis retidos | 0 retidos |
| Mesmo caso com nomes em minúsculas | 3 retidos | 0 retidos |
| Controle da API de alto nível | 0 retidos | 0 retidos |
| Resposta 200 direta | 3 retidos conforme esperado | 3 retidos conforme esperado |
| Redirecionamento explicitamente desabilitado | Uma chamada; 302 retornado | Uma chamada; 302 retornado |
| Conjunto de remoção personalizado adiciona marcador benigno | Todos os 4 cabeçalhos retidos | Todos os 4 removidos |
12/12 expectativas de cenário passaram. Cada cenário também verifica o status da resposta, a contagem de chamadas de transporte, o conjunto inicial de cabeçalhos, o resultado do cabeçalho benigno e que os cabeçalhos do chamador não foram mutados. O resultado vulnerável é um resultado de linha de base esperado, não uma verificação de segurança aprovada.
Resultados legíveis por máquina incluem os argumentos capturados, hashes exatos dos wheels, runtime, hashes do código-fonte de teste, atribuição e horário de reprodução.
O aviso upstream, publicado em 7 de maio de 2026, identifica um problema de exposição de informações no caminho de redirecionamento de baixo nível com proxy do urllib3. Ele lista as versões >=1.23, <2.7.0 como afetadas. Chamar ProxyManager.connection_from_url(...).urlopen(..., assert_same_host=False) poderia carregar cabeçalhos sensíveis configurados para uma requisição redirecionada a outra origem. A API de alto nível do manager já os removia.
A correção upstream aplica Retry.remove_headers_on_redirect antes da requisição recursiva de baixo nível. Nosso caso de cabeçalhos em minúsculas segue a atenção da regressão upstream à capitalização dos nomes de cabeçalho. O caso de remoção personalizada verifica que a regra respeita o conjunto configurado, além apenas dos três nomes padrão.
O advisory credita christos-cantina-security como repórter, illia-v como coordenador e sethmlarson como revisor de remediação. A contribuição de Sergio Rodriguez aqui é o harness offline independente e a análise de antes/depois. Esta é uma reprodução do CVE publicado por eles.
Use Python 3.10 ou superior. Não é necessário pip install nem ambiente virtual: cada versão é importada diretamente do seu wheel em Python puro, em um subprocesso isolado e novo.
A partir da raiz do repositório do portfólio:
python -B ./labs/cve-replay/run_replay.py --fetch
python -B ./labs/cve-replay/run_replay.py
O primeiro comando baixa os dois wheels exatos para o diretório ignorado .cache/wheels/ do laboratório e verifica seus hashes SHA-256 em relação ao manifesto. O segundo comando usa esse cache sem baixar nada. Para um checkout de código-fonte independente, execute python -B run_replay.py --fetch e, em seguida, o mesmo comando sem --fetch. --cache aceita um diretório de cache local diferente.
HTTPConnectionPool._make_request é substituído por um transporte de duas respostas: um 302 com um local fixo, seguido de um 200. O fixture captura os argumentos que chegam a esse limite. O parsing do urllib3, a política de retentativas, a filtragem de cabeçalhos e o tratamento recursivo de redirecionamentos são executados sem alterações a partir do wheel selecionado.
Todos os destinos são nomes reservados .invalid fixos; todos os valores de cabeçalho começam com DUMMY. A construção de sockets e as funções de DNS lançam exceção imediatamente. A sondagem de capacidade IPv6 em tempo de importação da biblioteca é negada e registrada separadamente; os cenários de replay não tentam nenhuma operação de rede. Não há servidor à escuta nem alvo ativo.
Isso valida o tratamento de argumentos de redirecionamento. Não mede o tráfego de proxy de ponta a ponta. A versão 2.7.0 é a primeira correção para esta CVE específica; esta comparação histórica não é uma recomendação para selecioná-la em vez de versões suportadas mais recentes.