Users could believe they were anonymous while their actual location was being broadcast
In Zurich, a security engineer uncovered a quiet but consequential flaw in Android 16: the operating system leaks users' true IP addresses even when a VPN is active, rendering one of the most trusted tools of digital privacy effectively useless. Reported through official channels, the vulnerability was met not with urgency but with institutional indifference — Google declining to prioritize a fix, leaving millions to navigate a false sense of protection. It is a familiar tension in the digital age, where the systems we trust to shield us are shaped as much by corporate priorities as by technical possibility.
- Android 16 silently transmits unencrypted connection signals outside VPN tunnels, exposing real IP addresses to any application positioned to intercept them.
- Every VPN provider is equally defeated by the flaw — premium or free, no configuration or security setting offers a meaningful defense.
- Google dismissed the vulnerability as low-priority and cited implementation challenges, even as GrapheneOS demonstrated that a working patch is entirely achievable.
- Mullvad and the broader security community have begun steering privacy-conscious users toward GrapheneOS, signaling a fracture of trust in mainstream Android.
- A technical workaround exists via USB debugging commands, but it is fragile, risky, and inaccessible to most ordinary users — leaving the burden of safety squarely on individuals.
Um engenheiro de segurança baseado em Zurique descobriu uma falha preocupante no Android 16: o sistema operacional vaza o endereço IP real dos usuários mesmo quando uma VPN está ativa. O problema foi reportado pelo programa oficial de recompensas por bugs do Google — mas, em vez de urgência, a resposta foi indiferença institucional.
A mecânica da vulnerabilidade é direta e grave. O ConnectivityManager do Android 16 envia notificações de encerramento de conexão fora do túnel criptografado da VPN, de forma não criptografada e visível. Não importa qual serviço de VPN o usuário utiliza, quais permissões foram concedidas ou qual nível de criptografia foi configurado — nem mesmo os modos "VPN permanente" ou "bloquear conexões sem VPN" funcionam. A proteção que os usuários acreditavam ter simplesmente não existe.
O Google argumentou que a correção seria impraticável e de baixa prioridade, apontando o Google Play Protect como salvaguarda existente. Mas o próprio Google reconhece que ameaças emergentes nem sempre são detectadas imediatamente por defesas automatizadas. O argumento da impraticabilidade foi ainda mais enfraquecido por um fato revelador: o GrapheneOS, sistema operacional alternativo focado em privacidade, já havia implementado um patch para a mesma vulnerabilidade. O Mullvad, provedor de VPN, passou a recomendar a migração para o GrapheneOS.
Para quem não pode abandonar o Android, o engenheiro que descobriu a falha ofereceu um contorno temporário via comandos de depuração USB — uma solução frágil, arriscada e inacessível para a maioria dos usuários comuns. Até o momento, não há registro de exploração ativa da vulnerabilidade, mas o conforto é limitado: a falha permanece sem correção oficial, e o ônus de se manter seguro recaiu inteiramente sobre o usuário.
A security engineer based in Zurich discovered something unsettling about Android 16: the operating system had a flaw that allowed applications to sidestep VPN protection entirely, leaving user IP addresses exposed to anyone willing to look. The engineer reported the vulnerability through Google's official bug bounty program, expecting the company to treat it with urgency. Instead, Google's security team declined to fix it, deciding the problem wasn't important enough to warrant a solution.
The mechanics of the vulnerability are straightforward and damning. Android 16's ConnectivityManager—the system component responsible for handling device connectivity—sends a final notification to web servers when a connection closes. Normally, this would happen inside the encrypted tunnel that a VPN creates. But in this case, the notification was being transmitted outside that protected channel, unencrypted and visible. The result: a device's true IP address leaked out, regardless of which VPN service the user had installed, what permissions they'd granted, or what encryption level they'd configured. It didn't matter if the user had enabled "permanent VPN" mode or activated the setting to block all connections without VPN active. Those safety features, designed to give users confidence they were protected, simply didn't work.
What makes this particularly troubling is that the vulnerability bypasses every VPN provider equally. Whether someone paid for a premium service or used a free option, the flaw rendered the entire category of protection useless. A user could believe they were anonymous, accessing the internet from a virtual location thousands of miles away, while their actual location was being broadcast to any malicious application they'd downloaded.
Google's response was to argue that the bug wasn't a high priority and that fixing it would be impractical. The company pointed to Google Play Protect, its automated threat detection system, as existing protection. But as Google itself acknowledged, emerging threats don't always get caught immediately by automated defenses. In other words: users might not be safe.
What's particularly revealing is that the problem has a solution. GrapheneOS, an alternative Android operating system focused on privacy, had already implemented a patch for the exact same vulnerability. This fact undermined Google's claim that a fix was impractical. If another team could solve it, why couldn't Google? The security community took note. Mullvad, a VPN provider, began recommending that privacy-conscious users consider switching to GrapheneOS entirely rather than rely on Android 16's broken protections.
For those unwilling or unable to abandon Android, the security engineer who discovered the flaw offered a temporary workaround: a debugging command that could be executed on devices with USB debugging enabled, likely through the Android Debug Bridge. But this solution came with its own risks—it required users to manipulate sensitive system functions, and there was no guarantee it would work reliably or remain available.
As of now, no active exploitation of this vulnerability has been documented. But that's cold comfort. The flaw remains unfixed in Android 16, which means millions of users who believe their VPNs are protecting them are actually exposed. Google has chosen not to prioritize the problem. The burden of staying safe has shifted entirely to the user—either by switching operating systems, attempting experimental workarounds, or accepting the risk.
Citações Notáveis
Google's security team decided the problem was not high priority and its correction was impractical— Security engineer who discovered the vulnerability, reporting to CNET
Google Play Protect already protects users automatically, though emerging threats may not be recognized immediately— Google representative
A Conversa do Hearth Outra perspectiva sobre a história
Why would Google decline to fix something this fundamental? It seems like a straightforward security issue.
The company classified it as low priority, which is a decision that reflects how they weigh risk. They have millions of devices to support, and they're betting that most users won't encounter malicious apps that exploit this specific flaw.
But the engineer proved that a fix exists. GrapheneOS did it. So "impractical" doesn't really hold up, does it?
No, it doesn't. That's what makes the decision harder to defend. It suggests the issue isn't technical feasibility but resource allocation or risk tolerance. Google may have decided the cost of fixing it outweighs the perceived threat.
What about the users who specifically enabled VPN protections because they wanted to be safe? Doesn't that matter?
It should. Those users made an active choice to protect themselves, and the system failed them silently. They had no way of knowing their IP was leaking. That's the real problem—the false sense of security.
Is there any reason to think Google might change course?
Pressure from the security community and media coverage can shift priorities. But right now, the incentive structure isn't there. No major breach has happened yet, and the company has already made its position clear.
So what do people actually do?
They either migrate to GrapheneOS, try the debugging workaround if they're technically comfortable, or accept the risk. None of those are great options for most users.