Your VPN Might Not Be Doing What You Think It Is
Here's something uncomfortable: you turned on your VPN, maybe even enabled "Always-on VPN" for extra peace of mind — and your real IP address could still be leaking. That's not a hypothetical. That's what's happening right now with a newly discovered vulnerability in Android 16.
A security engineer based in Zurich found the bug and reported it through Google's own Vulnerability Reward Program — the official channel where researchers flag problems in Android apps and get paid for it. The findings were later shared by VPN provider Mullvad on their blog, which is how word really started spreading.
And honestly? The part that stings isn't just that the bug exists. It's what happened after it was reported.
Google Closed the Report Without Fixing It
The engineer shared logs showing Android's security team shut down the report. Their reasoning: fixing it was "infeasible" and it wasn't considered a high enough priority. Think about that for a second. A bug that bypasses VPN protections entirely — including settings specifically designed to block unprotected traffic — wasn't deemed urgent enough to patch.
Google did respond when asked about it, telling CNET that the issue only affects devices that have downloaded a malicious app. They also noted that Google Play Protect automatically guards users against known malicious apps. Which is technically true, but also a bit of a sidestep — newly emerging threats, by definition, won't be on any automated detection list yet.
How the Bug Actually Works
Here's what's going on under the hood. Android 16 has something called the ConnectivityManager system service. It allows apps to send a final message to web servers when an internet connection fully ends — kind of like a digital "goodbye" signal. Normal enough in theory.
The problem is that this service currently bypasses the VPN tunnel entirely. So that little goodbye message goes out unencrypted, carrying your device's real IP address with it — not the masked location your VPN is supposed to show. It doesn't matter which VPN you're using, how it's configured, or what encryption settings you've enabled. The vulnerability sidesteps all of it.
Always-On VPN Doesn't Help Here
This is the part that really matters if you rely on VPNs for serious privacy. The bug persists even when you have "Always-on VPN" or "Block connections without VPN" enabled. Those settings exist specifically to ensure no traffic ever leaves your device without VPN protection. But this bug slips right past them, which means people using those settings could have a false sense of security — believing they're protected when they're not.
That's especially concerning for anyone with critical privacy needs, where IP exposure isn't just an inconvenience but a genuine risk.
No Evidence of Exploitation — But That's Not the Whole Story
There's no evidence so far that anyone has actually used this vulnerability to harvest device data. That's worth noting. But Google leaving it unresolved means it's not going away on its own, and the window stays open indefinitely for Android 16 users.
The fact that GrapheneOS — an Android-based operating system — has already patched the issue (according to Mullvad) shows this is fixable. It's not some impossibly complex architectural problem. It just hasn't been prioritized by Google.
What Android Users Can Actually Do Right Now
If you're worried — and it's reasonable to be — there are a couple of paths forward, though neither is perfect.
Switch to GrapheneOS. Mullvad's recommendation for anyone with serious privacy concerns is to move to GrapheneOS, which has already addressed the bug. That's a significant step, but it's the most thorough fix currently available.
Try the debug workaround. The security engineer who found the bug also discovered a debug command that can address it on Android devices — but only if USB debugging is enabled. You'd need to download the Android Debug Bridge to use it. The catch: subsequent Android updates may undo this fix, so it's not a permanent solution. And the blog post itself cautions that you should only attempt it if you genuinely understand what you're doing with USB debugging mode.
There's more detail on how to input the command over at Mullvad's blog if you want to explore that route carefully.