O Turbo VPN mostrava «ligado» enquanto o seu IP real continuava à vista

07.08.2026 5 min 11

O cliente Windows do Turbo VPN indicava uma ligação ativa enquanto o verdadeiro endereço IPv4 do utilizador continuava à vista. A TechRadar publicou a constatação esta semana, e a empresa precisou de duas correções para travar as fugas: a compilação de emergência 3.7.0.0 só chegou depois de os investigadores enviarem um segundo conjunto de provas técnicas. O perigoso é que nada parecia estar mal. A aplicação dizia ligado, e não havia razão para duvidar.

A aplicação não construía qualquer túnel

O pormenor mais útil não é que algo tenha fugido, mas porquê. O protocolo próprio Lepus não criava um túnel cifrado ao nível do sistema, como uma VPN normalmente faz. Em vez disso lançava um processo ShadowsocksR local, ativava a definição de proxy do Windows e mantinha um proxy na porta 46288.

É essa distinção que decide o que fica protegido. Um proxy configurado nas definições do Windows apanha as aplicações que respeitam essa definição, ou seja, sobretudo os navegadores. Todo o resto continua a usar a ligação normal: tráfego de fundo do sistema operativo, mensagerias de secretária, serviços de atualização, ferramentas de linha de comandos. A interface continua a dizer ligado, porque do ponto de vista da aplicação o proxy está de pé. O utilizador vê verde e assume que cobre a máquina inteira.

Foram precisas duas correções

Depois do primeiro alerta, o Turbo VPN lançou uma correção. Não chegou. A versão 3.6.0.0 continuava a deixar escapar endereços IPv6, e não apenas nos protocolos próprios Lepus e LinkSentinel mas também em ligações OpenVPN normais. Só depois de mais provas técnicas chegou a versão 3.7.0.0, que bloqueia o IPv6 não cifrado do lado do cliente e força o tráfego pelo túnel IPv4 cifrado. Os testes confirmaram que esta compilação aguenta.

Convém manter o âmbito claro: as fugas descritas foram encontradas no cliente para Windows. Não é motivo para descansar quanto às aplicações móveis, mas foi isso que foi testado e publicado.

Não foi o primeiro aviso sobre estas aplicações

Com o contexto, a arquitetura faz mais sentido. Em 2025 o Citizen Lab publicou na FOCI uma investigação sobre aquilo a que chamou ligações ocultas entre aplicações VPN. Em oito aplicações distribuídas pela Innovative Connecting, Autumn Breeze e Lemon Clove, entre elas Turbo VPN, Snap VPN e VPN Proxy Master, com mais de 380 milhões de descargas no conjunto, encontrou-se código partilhado, dependências comuns e uma palavra-passe Shadowsocks escrita no código. Uma palavra-passe partilhada e escrita no código significa que qualquer pessoa que a extraia consegue decifrar o tráfego que ela deveria proteger.

A mesma investigação relata cifras obsoletas, recolha não divulgada de dados de localização, vulnerabilidade a injeção de pacotes, código ofuscado que dificulta a análise e ligações de propriedade das três empresas à Qihoo 360, empresa chinesa de cibersegurança sancionada pelos Estados Unidos em 2020. Faz ainda uma observação que explica a arquitetura: são serviços ao nível da aplicação construídos sobre Shadowsocks, um protocolo pensado para atravessar a Grande Muralha digital, não para dar privacidade.

Importante: Um indicador de ligação não é prova. Reporta o que a aplicação acredita sobre si própria, não o que o seu sistema operativo está de facto a enviar. A única coisa que resolve isto é um teste de fugas feito fora da aplicação.

Como verificar a sua própria VPN em cinco minutos

Aplica-se a qualquer fornecedor, incluindo os bons. Ligue-se primeiro e depois verifique:

  1. Abra uma página de teste de fugas e confirme que o endereço IPv4 mostrado é o do servidor e não o seu.
  2. Verifique o IPv6 na mesma página. As fugas de IPv6 são a falha mais comum, porque muitos clientes encaminham o IPv4 pelo túnel e ignoram calmamente o IPv6.
  3. Veja os servidores DNS listados. Se pertencerem ao seu operador doméstico, ele vê a sua navegação independentemente do túnel.
  4. Teste o tráfego que não passa pelo navegador. Faça um ping ou um trace a partir de um terminal e veja se sai pelo túnel. É exatamente aqui que uma montagem só com proxy falha.
  5. Corte o túnel a meio de uma descarga. Se a descarga continuar, não há kill switch a funcionar, e cada desligamento futuro vai expô-lo.

Daí o argumento prático a favor de um fornecedor que se possa verificar, e não apenas popular. O que distingue um serviço sério não é o número de instalações, mas se o protocolo está documentado, se auditores independentes foram deixados entrar e os relatórios publicados, se a proteção contra fugas e o kill switch vêm ativos por omissão, e se a propriedade é declarada com clareza em vez de reconstruída a partir de registos comerciais. Uma aplicação gratuita com centenas de milhões de instalações pode continuar a ser um proxy de navegador com uma palavra-passe partilhada. Analisámos uma falha aparentada quando o WebKit deixava escapar IP real e DNS contornando os proxies, e a distância entre promessas e prática quando uma VPN sem registos perdeu 58 milhões de registos de ligação.

Conclusão

Conclusão: O Turbo VPN já corrigiu as fugas de IPv6 no Windows, e a segunda correção é de reconhecer. Mas a lição sobrevive ao arranjo: uma aplicação que anuncia uma proteção que não dá é pior do que não ter VPN, porque muda o comportamento sem mudar a proteção. Teste o que usa, prefira serviços cujas afirmações alguém independente tenha verificado, e trate um indicador verde como uma hipótese e não como um resultado.

turbo vpnfuga vpnvpn gratuitashadowsocksipv6citizen labcibersegurançaprivacidadesegurançafuga dns

Leia também