No dia 4 de agosto de 2026, pesquisadores da Mysk publicaram uma análise de três mecanismos do WebKit que enviam tráfego contornando o proxy configurado — diretamente do dispositivo. Todos os navegadores iOS com modo proxy, incluindo navegadores Tor, e o próprio serviço da Apple — iCloud Private Relay — foram afetados. O proxy está ativado, a interface mostra um país diferente, mas o site vê seu verdadeiro IP e seu resolvedor DNS doméstico.
Isso não é uma vulnerabilidade exótica para paranoicos. É uma demonstração clara de uma regra arquitetônica que todos que trabalham através de proxies devem entender: o proxy no nível do aplicativo protege apenas o tráfego que passa pela pilha de rede desse aplicativo. Tudo que é gerado pelo sistema operacional ou por um serviço de sistema separado passa direto.
O que exatamente está vazando
A pesquisa começou com uma situação cotidiana: um usuário do navegador proxy Psylo reclamou ao desenvolvedor sobre um vazamento de DNS. A análise da reclamação revelou três canais independentes de vazamento — todos eles estão no próprio WebKit, e não em um aplicativo específico.
1. DNS prefetching — o mais simples e o mais desagradável
Mecanismo: a tag <link rel="dns-prefetch"> pede ao navegador para resolver o nome do host antecipadamente, a fim de acelerar o carregamento futuro. O problema é que o WebKit no iOS resolve esses nomes pelo caminho DNS padrão do dispositivo, e não pelo proxy.
O Safari para desktop suporta dns-prefetch desde o Safari 5, mas o iOS ignorou essa tag — até o iOS 26.0 (setembro de 2025). Naquele momento, o WebKit a ativou como parte da mesma mudança que removeu o antigo DNS prefetching especulativo implícito (bug 285744).
Como isso é explorado: a página insere nesses tags nomes de host únicos para cada visitante e, em seguida, simplesmente observa como as solicitações chegam ao seu próprio servidor DNS autoritativo — do verdadeiro endereço de rede do visitante. Nenhum JavaScript, nenhuma interação do usuário. Basta abrir a página.
2. WebAuthn Related Origin Requests — vazamento através do passkey
Esse canal surgiu ainda no iOS 18.0. Quando um site solicita credenciais WebAuthn (ou seja, passkey), o sistema verifica o arquivo https://<rpId>/.well-known/webauthn — para garantir que o domínio está realmente associado ao relying party especificado.
Detalhe chave: essa solicitação de verificação não sai da pilha de rede do navegador. Ela é executada pelo serviço de credenciais do sistema operacional, que envia a solicitação HTTPS diretamente do dispositivo. O proxy configurado dentro do navegador simplesmente não sabe sobre isso (bug 268426).
Ou seja, basta que a página inicie uma solicitação de passkey — e o servidor do atacante recebe uma conexão do seu verdadeiro IP.
3. WebTransport — QUIC diretamente do dispositivo
O canal mais recente. A chamada new WebTransport(url) abre uma conexão QUIC diretamente do dispositivo, contornando a configuração do proxy. O WebTransport no WebKit esteve desativado por muito tempo e foi publicamente ativado no iOS 26.4 em março de 2026 (bugs 260810 e 303453).
Quem é afetado
A Apple exige que todos os navegadores no iPhone usem o WebKit. Portanto, cada navegador iOS que depende da API de proxy do WebKit será afetado — incluindo todas as versões iOS dos navegadores Tor e o próprio Psylo, que iniciou a investigação. Além disso, Safari e iCloud Private Relay.
O que não é afetado — aplicativos VPN. Eles operam em nível de sistema e encapsulam todo o tráfego do dispositivo, incluindo aquele gerado por serviços de sistema. Essa é a essência da diferença: o túnel do sistema não tem "por fora". Uma exceção separada é o Onion Browser no nível de segurança Silver com o Modo de Bloqueio ativado: ele é imune ao vazamento através do WebTransport.
Do lado dos desenvolvedores, já há uma reação. No Psylo 1.3.1, todos os três canais foram fechados: o aplicativo bloqueia as sugestões de dns-prefetch (a página não pode mais forçar o dispositivo a resolver nomes controlados pelo atacante), e o WebTransport e WebAuthn estão desativados por padrão — podendo ser ativados pontualmente, com interruptores separados. A Apple, até a data da publicação, deve corrigir os problemas em uma atualização futura; a empresa não forneceu prazos específicos.
Por que isso só veio à tona agora
A cronologia aqui é reveladora, e vale a pena analisá-la separadamente — ela explica por que o problema não foi notado antes.
- Setembro de 2024, iOS 18.0 — surge o mecanismo WebAuthn Related Origin Requests. O canal de vazamento existe há quase dois anos e durante todo esse tempo não foi discutido por ninguém: a verificação de domínio para passkey parece um elemento de segurança, e não uma forma de revelar o endereço.
- Setembro de 2025, iOS 26.0 — o WebKit ativa o suporte a dns-prefetch em dispositivos móveis. Formalmente, isso é uma otimização de velocidade de carregamento; na prática — a página ganha a capacidade de forçar o dispositivo a consultar um nome DNS arbitrário contornando o proxy.
- Março de 2026, iOS 26.4 — o WebTransport é ativado publicamente. O terceiro canal.
- Agosto de 2026 — a reclamação de um usuário sobre vazamento de DNS leva a uma análise que revela todos os três de uma vez.
O denominador comum: nenhuma dessas funções foi concebida como um canal de desanonimização. Todas três são capacidades normais da plataforma: aceleração de resolução, verificação de passkey, transporte moderno. Elas se tornam vazamentos apenas em combinação com o modo proxy de nível de aplicativo, e é por isso que ninguém as testou nesse contexto por anos.
A conclusão para a prática é simples e desagradável: a ausência de notícias sobre vazamentos não significa que eles não existam. É necessário verificar por conta própria e regularmente, e não esperar que alguém publique uma análise.
Como se verificar
Os pesquisadores disponibilizaram um estande público — leaks.psylo.app. Ele verifica três coisas: tráfego HTTPS comum (qual IP e quais resolvedores DNS o servidor vê), WebTransport e a combinação WebAuthn + dns-prefetch. Abra com o proxy ativado e compare o resultado com o endereço que você espera ver.
É importante verificar a higiene básica — se o IP, DNS e o endereço WebRTC na sua combinação de trabalho coincidem. Se você não fez isso sistematicamente antes, comece com nossa análise: como verificar o proxy para vazamento de DNS.
Conclusão prática: a camada importa
A história com o WebKit é um caso particular de uma regra geral que deve ser mantida em mente ao trabalhar através de proxies, em qualquer plataforma.
- Proxy no navegador ≠ proxy no dispositivo. A configuração dentro do aplicativo cobre exatamente o tráfego que o aplicativo envia. Serviços de sistema, processos em segundo plano, atualizações, conexões push e, como se viu, o serviço de passkey embutido — tudo isso segue seu próprio caminho.
- Vazamentos não ocorrem apenas em locais "conhecidos". O WebRTC já é bem conhecido, e as pessoas aprenderam a bloqueá-lo. E o dns-prefetching e a verificação do WebAuthn — são funções de desempenho e segurança que ninguém considerou como um canal de desanonimização. Novos recursos dos navegadores regularmente criam novas brechas.
- A atualização da plataforma pode quebrar sua proteção silenciosamente. Aqui isso é visível literalmente pelas datas: o dns-prefetching "foi ativado" no iOS 26.0, o WebTransport — no iOS 26.4. O usuário não mudou nada, mas a superfície de vazamento cresceu por conta própria.
O que isso significa para multi-contas e automação
Para aqueles que gerenciam várias contas ou coletam dados, o risco aqui não é abstrato-privado, mas sim financeiro. Sistemas antifraude das plataformas comparam sinais: se a sessão declara um IP, mas a solicitação associada vem de outro endereço e de um resolvedor doméstico, isso é um motivo claro para vincular contas ou marcar a sessão como suspeita.
Consequências práticas:
- Não mantenha sessões de multi-contas de trabalho em navegadores móveis com modo proxy. Enquanto a plataforma não fechar as brechas, a camada do aplicativo no iOS é, por definição, não confiável.
- Encapsule o tráfego em nível de sistema. Se a tarefa é um ambiente móvel, é mais sensato levantar um proxy em nível de dispositivo ou roteá-lo através de um gateway separado, em vez de depender da configuração dentro do navegador.
- Verifique a combinação após cada grande atualização do SO e do navegador. Uma vez por trimestre — no mínimo. Inclua isso na sua lista de verificação, e não "quando algo der errado".
- Desative o que você não usa. WebTransport e WebAuthn em um perfil de trabalho para parsing ou SMM quase certamente não são necessários — desativá-los remove dois canais de vazamento dos três.
A qualidade do próprio IP permanece uma variável separada: mesmo com uma configuração hermética, um endereço de data center se revela por ASN. Para cenários onde é importante parecer um usuário comum, proxies residenciais funcionam, e para aplicativos móveis e plataformas com antifraude mais rigoroso — proxies móveis com IPs de operadores de celular reais. Mas nenhum tipo de proxy salvará se parte do tráfego fisicamente passar por fora dele — primeiro a hermeticidade, depois a qualidade do endereço.
Resultado
Os três bugs do WebKit — dns prefetching, WebAuthn Related Origin Requests e WebTransport — mostraram que "proxy ativado" e "todo o tráfego passa pelo proxy" são duas afirmações diferentes. No iOS, a lacuna entre elas se revelou suficientemente ampla para que uma página da web comum, sem uma única linha de JavaScript, pudesse descobrir o verdadeiro endereço de um visitante do navegador Tor.
Enquanto a Apple prepara uma correção, a única estratégia viável é verificar, e não supor. Abra o estande de teste, compare os endereços, desative APIs desnecessárias. E trate cada grande atualização do SO como um evento após o qual a configuração deve ser verificada novamente. A diferença entre privacidade e sua ilusão muitas vezes consiste exatamente em uma pergunta não feita a tempo: "será que todo o tráfego é realmente assim?". Também é útil entender quais outros sinais podem revelar sua identidade além do endereço — sobre isso escrevemos no material sobre proteção contra impressão digital do navegador.
```