WebKit expõe IP e DNS reais apesar dos proxies e do iCloud Private Relay

Uma fuga de IP e DNS no WebKit anula a privacidade que os navegadores com proxy deveriam garantir no iOS. Os investigadores da Mysk publicaram a 4 de agosto de 2026 resultados que mostram que três funções distintas do WebKit abrem ligações diretamente a partir do dispositivo, ignorando o proxy que o navegador devia usar. Os mesmos três caminhos escapam também ao iCloud Private Relay da Apple.

Não se trata de um exploit remoto. Uma página não precisa de quebrar nada: limita-se a usar funções vulgares da plataforma web e a observar de onde chega o tráfego.

As três funções que contornam o proxy

DNS prefetch é uma otimização de velocidade. Uma página avisa que vai precisar em breve de um nome de anfitrião e o motor resolve-o antecipadamente. No iOS essa resolução segue o caminho DNS normal do dispositivo e não o proxy. Um site pode colocar nessa dica um nome de anfitrião único por visitante e depois ler as consultas quando chegam ao seu próprio servidor de nomes autoritativo, diretamente a partir da rede real do visitante.

WebAuthn related origin requests vaza de outra forma. O WebKit entrega a cerimónia de passkey ao serviço de credenciais do sistema operativo, e é esse serviço que vai buscar sozinho o ficheiro /.well-known/webauthn do site. O pedido parte do sistema e não do navegador, por isso as definições de proxy do navegador nunca entram na equação.

WebTransport é o mais direto dos três. Criar um abre uma ligação QUIC do dispositivo até ao destino, sem qualquer proxy pelo meio.

Porque é que o iCloud Private Relay não o salva aqui

O Private Relay é muitas vezes descrito como uma VPN para o Safari. Não é. Encaminha o tráfego das páginas do Safari por dois saltos para que nenhuma parte veja ao mesmo tempo quem é e o que pediu. Essa proteção cobre o caminho normal de carregamento de uma página, e as três fugas vivem fora dele. Quando o serviço de credenciais do sistema ou um socket QUIC saem por conta própria, o Private Relay não está sequer no circuito.

O mesmo raciocínio explica porque o problema pesa mais no iPhone do que noutro lado. As regras da App Store obrigam qualquer navegador iOS a usar WebKit, por isso um navegador focado na privacidade não pode substituir o motor por outro que encaminhe corretamente estes caminhos. Os navegadores baseados em Tor para iOS herdam a fuga por construção, tal como qualquer aplicação que assente o anonimato num proxy interno.

O que está a ser corrigido

Por agora as mitigações vêm dos programadores das aplicações e não do motor. O Psylo lançou a versão 1.3.1: remove das páginas as dicas dns-prefetch e desliga por omissão o WebTransport e o WebAuthn, que ficam como interruptores opcionais. É um contorno ao nível da aplicação: cada navegador afetado tem de reparar no problema e desativar funções úteis uma a uma. Não há declaração pública da Apple nem alteração anunciada no WebKit que trate os três caminhos em conjunto.

Porque é que um túnel de sistema não é afetado

O que conta aqui é o nível em que a privacidade é aplicada. Um proxy configurado dentro de um navegador só cobre o tráfego que esse navegador decide enviar-lhe, por isso tudo o que outro componente do sistema abrir passa ao lado. Um túnel completo é imposto pela pilha de rede do sistema operativo: cada pacote de cada processo sai pela mesma interface, venha do carregamento de uma página, de um serviço de credenciais ou de um socket QUIC em bruto. É por isso que as VPN de túnel completo ficam intactas perante as três fugas e os proxies dentro do navegador não, e é um lembrete útil de que a privacidade ao nível do navegador e ao nível da rede resolvem problemas diferentes.

Para quem hoje depende de um navegador com proxy, os passos são pequenos mas reais: atualizar a aplicação se o programador já lançou uma mitigação, deixar de tratar o Private Relay como ferramenta de anonimato e verificar o que o navegador expõe de facto em vez de confiar no indicador da interface.