Vazamento de senha de proxy através de curl, libsoup e requests: verificação

A senha do proxy geralmente é mantida em segredo: não é exibida em capturas de tela, não é comitada no git, é mantida em variáveis de ambiente. Mas em 2026, descobriu-se que ela pode ser revelada pelo próprio cliente HTTP. Entre abril e julho, várias vulnerabilidades foram descobertas no curl, libcurl e libsoup, nas quais o cabeçalho Proxy-Authorization é enviado para o proxy errado, ou até mesmo diretamente para o site-alvo. Abaixo, uma análise das condições em que isso ocorre e um guia passo a passo para verificar sua pilha.

O que aconteceu: quatro vazamentos em quatro meses

Todos esses bugs funcionam da mesma maneira: o cliente armazena o login e a senha de um proxy e, por engano, os envia adiante na cadeia.

CVE-2026-6253 (curl e libcurl 7.14.1–8.19.0). Se diferentes proxies estão configurados para http:// e https://, e o primeiro requer senha enquanto o segundo não, ao redirecionar durante a troca de esquema, o curl enviará as credenciais do primeiro proxy para o segundo. Os dados são enviados em base64, ou seja, praticamente em texto claro. Corrigido no curl 8.20.0, lançado em 29 de abril de 2026. O curl de console também é vulnerável, não apenas a biblioteca.
CVE-2026-8927 (libcurl 7.12.0–8.20.0). O aplicativo reutiliza um handle para várias solicitações, os proxies são obtidos de variáveis de ambiente, e a autorização é feita via Digest. Nesse caso, o cabeçalho Proxy-Authorization para o proxy A é enviado ao proxy B, que pode repeti-lo para se passar por você. Corrigido no curl 8.21.0 de 24 de junho de 2026. O curl de console não foi afetado. Um bug quase idêntico é descrito no CVE-2026-7168, a única diferença é como o proxy é selecionado.
CVE-2026-12547 (libsoup, SoupAuthManager). O libsoup armazena em cache as credenciais do proxy, sem vinculá-las ao endereço host:port. Quando as configurações do proxy mudam (parâmetros do sistema, WPAD), o cabeçalho antigo é enviado ao novo proxy. Publicado em 21 de julho de 2026, avaliação baixa.
CVE-2026-66339 (libsoup, túneis CONNECT). Após a instalação de um túnel CONNECT através de um proxy HTTP, o libsoup anexa Proxy-Authorization às próximas solicitações HTTPS dentro do túnel. O cabeçalho já é visto pelo servidor-alvo. CVSS 6.5, publicado em 24 de julho de 2026.

A história não é nova. Na biblioteca Python requests, da versão 2.3.0 até 2.31.0 (CVE-2023-32681), o cabeçalho Proxy-Authorization durante um redirecionamento para HTTPS era enviado ao servidor-alvo, se o login e a senha fossem inseridos diretamente na URL do proxy. No urllib3, até 1.26.19 e 2.2.2 (CVE-2024-37891), o cabeçalho definido manualmente, e não através do suporte embutido ao proxy, não era removido ao redirecionar para um domínio externo.

Por que isso é importante ao trabalhar com proxies

Com um proxy pago, a senha equivale a dinheiro. Quem a obtém consome seu tráfego até que você mude o acesso. Ao pagar por gigabytes, isso representa um custo direto, e em um acesso compartilhado para toda a equipe, ainda há as ações de terceiros utilizando seu IP.

Os cenários mais vulneráveis são os seguintes:

Parsers e monitoramentos, que seguem redirecionamentos automaticamente. O site-alvo ou um redirecionamento intermediário pode desviar a solicitação para um domínio que coleta cabeçalhos.
Scripts com múltiplos proxies: diferentes proxies para diferentes esquemas, troca de proxies entre solicitações em uma única conexão, mistura de "proxies com senha" e "proxies sem senha".
Processos de longa duração em servidores Linux, onde libcurl e libsoup vêm com pacotes do sistema e são atualizados junto com a distribuição, e não com seu código.
Redes corporativas com WPAD e arquivos PAC: o proxy muda sem a participação do aplicativo, e é exatamente esse caso que é descrito no CVE-2026-12547.

Como verificar sua pilha: passo a passo

Descubra a versão real do libcurl, e não apenas do curl de console. O comando curl -V mostra ambas, mas o aplicativo pode ter sido compilado com sua própria cópia da biblioteca. Para Python com pycurl, execute python -c "import pycurl; print(pycurl.version)", para PHP chame curl_version(). Limite seguro: 8.21.0 ou mais recente, ou ramos corrigidos 8.20.1+, 8.16.1+ e 8.14.2+.
Verifique as dependências do Python. Execute pip show requests urllib3. Precisamos de requests não inferiores a 2.31.0 e urllib3 não inferior a 1.26.19 (ramo 1.x) ou 2.2.2 (ramo 2.x). Se a dependência chegar de forma transitiva, veja pip list dentro do mesmo ambiente onde o parser está funcionando.
Verifique o libsoup no Linux. Isso se aplica a aplicativos GNOME, WebKitGTK e tudo que é construído nessa pilha. Atualize o pacote através do gerenciador de distribuição e consulte o boletim de segurança de sua distribuição: nos cartões desses CVE, a Red Hat listou RHEL 6–10 como afetados.
Encontre no código a instalação manual do cabeçalho. Pesquise por Proxy-Authorization em todo o repositório. Se o cabeçalho for definido manualmente, e não através do mecanismo padrão do cliente proxy (proxies= em requests, ProxyManager em urllib3, CURLOPT_PROXYUSERPWD em libcurl), isso é um candidato a vazamento durante o redirecionamento.
Encontre a reutilização de conexões ao mudar de proxy. Um handle libcurl, uma sessão requests ou um agente HTTP, através dos quais as solicitações com diferentes proxies são feitas em sequência. A solução mais simples: uma sessão separada para cada proxy.
Desative redirecionamentos automáticos onde não são necessários. Em requests isso é allow_redirects=False, em urllib3 redirect=False, em curl não use -L e CURLOPT_FOLLOWLOCATION. Assim, os 3xx são tratados manualmente, e você decide para onde ir a seguir. Esse é o caminho alternativo sugerido pelos autores de requests e urllib3.
Realize um teste ao vivo para detectar vazamentos. Levante um servidor HTTP simples que imprime todos os cabeçalhos recebidos e faça um redirecionamento para outro servidor igual. Execute seu parser com proxy em um cenário real, incluindo a troca de esquema de http para https. Se algum dos servidores viu Proxy-Authorization, o vazamento foi confirmado em seu código, e não apenas na teoria.

Armadilhas

Imagens Docker vivem sua própria vida. Você atualizou o curl no host, mas o parser está funcionando em um contêiner com uma imagem base antiga. A verificação deve ser feita dentro do contêiner: docker exec <container> curl -V.
O curl de console e o libcurl são atualizados de maneiras diferentes. O CVE-2026-8927 não afeta o curl de console, enquanto o CVE-2026-6253 o afeta. Um curl -V fresco no terminal não diz nada sobre a biblioteca com a qual seu PHP ou Python foi compilado.
Digest não salva. Sim, no Digest a senha não é enviada em texto claro. Mas no CVE-2026-8927, o atacante não precisa da senha: o cabeçalho interceptado é repetido enquanto o nonce estiver ativo.
A senha na URL é conveniente, mas perigosa. O vazamento em requests se manifestou exatamente quando as credenciais foram inseridas no endereço do proxy no formato user:pass@host:port. Isso não é motivo para abandonar o formato, mas sim para manter as bibliotecas atualizadas.
O redirecionamento pode não vir do alvo. Páginas de captcha, banners de consentimento, encurtadores de links e CDNs também respondem com 3xx. Quanto mais "seguimentos de links" houver no crawler, maior será a superfície de ataque.

Como limitar os danos se a senha vazar

É impossível eliminar completamente o vazamento: amanhã sairá o próximo CVE. Portanto, é importante saber quanto custa um vazamento.

Um projeto, um acesso. Não mantenha um login compartilhado para todos os parsers. No ProxyCove, cada proxy comprado recebe um par separado de login e senha, portanto, o acesso vazado de um script não abre o tráfego dos outros.
Não mantenha em um único acesso mais tráfego do que o necessário. Reabasteça aos poucos conforme a necessidade, e não para seis meses à frente.
Monitore o consumo. Um aumento repentino no tráfego sem um aumento no número de tarefas é o primeiro sinal de que alguém mais está usando seu acesso.
Mude a senha imediatamente ao suspeitar e de acordo com um cronograma. Como organizar isso sem interrupções é discutido no guia sobre rotação de senhas de proxy.

Qual tipo de proxy escolher e qual a sua relação

O vazamento não depende do tipo de proxy: o bug reside no cliente. Mas o custo do vazamento depende. Proxies de datacenter são mais baratos por gigabyte, e para parsing de sites simples com redirecionamentos frequentes, é razoável mantê-los separados do tráfego caro. Proxies residenciais devem ser atribuídos a tarefas onde são realmente necessários, e para eles, criar acessos separados com redirecionamentos automáticos desativados. Proxies móveis, os mais caros por gigabyte, devem ser mantidos no código com o mínimo de dependências externas e sempre com verificação de versões de bibliotecas em cada compilação.

Conclusão

A senha do proxy pode vazar sem invasão, sem vírus e sem erro humano: basta um libcurl desatualizado, um redirecionamento para um domínio externo e uma conexão reutilizada. A lista de verificação é curta: curl e libcurl a partir de 8.21.0, requests a partir de 2.31.0, urllib3 a partir de 1.26.19 ou 2.2.2, libsoup atualizado, sessão separada para cada proxy, redirecionamentos sob controle e um teste ao vivo para detectar vazamentos. Além disso, acesso separado para cada projeto, para que um vazamento custe apenas um script, e não todo o saldo.