Can an Android App Reveal Your IP While a VPN Is Active?
New technical research shows that under specific conditions, an Android app can reveal a device's real IP address outside the VPN tunnel, even with VPN lockdown enabled.
Android has a setting most people treat as a hard guarantee: "Block connections without VPN." Turn it on, and no app should be able to send so much as a single packet outside the tunnel.
A technical report published recently on GrapheneOS's issue tracker shows there's a narrow but real exception. Under specific conditions, a malicious app can push a small packet of data straight out over Wi-Fi, bypassing the VPN entirely, and expose the device's real public IP.
The researcher who found it, known by the handle lowlevel, gave it an unofficial name: "Tiny UDP Cannon." Small in packet size, but big enough to give away exactly where a device is really connecting from.
How the gap works
The root cause is a mechanism called NAT-T keepalive, which uses NAT to keep certain connections alive, mostly on IPsec-based VPNs.
To save battery, some Android devices offload these keepalive packets directly to the Wi-Fi chip, so the main processor doesn't need to wake up every time one goes out. On its own, that's just a battery optimization.
The problem starts when an app requests one of these keepalives itself. That request lands on a layer of the network stack that sits below Android's normal routing checks, below the point where the OS enforces the VPN. The packet leaves through port 4500 UDP, the standard NAT-T port, and travels straight out over the real Wi-Fi connection.
The VPN itself never breaks. One specific, small packet simply never passes through it.
What the other side can see
The server that receives the keepalive packet sees the device's real public IP, not the VPN server's. That's enough to expose the user's internet provider, a fairly accurate estimate of their region, and the fact that the device is online and connected at a given moment.
This isn't a full traffic leak, though. The content of a keepalive packet is tightly defined by the protocol itself, so a malicious app can't shape it freely to smuggle out arbitrary data. The IP leak is real, but it doesn't open a path for the app's regular traffic to escape the tunnel.
Which devices are affected
The report on GrapheneOS's issue tracker first confirmed the path on Pixel devices over Wi-Fi, with packet output captured directly by a separate router. Later testing showed the same mechanism triggers on Samsung and Nothing devices running Android 16 as well.
The researcher's estimate is that the underlying path exists on the large majority of devices running Android 12 or newer, given how that part of the OS is structured. That doesn't mean every model on the market has been individually tested, only that the architecture behind the bug is common across most of it.
It takes an app already on the device, not root or ADB
For the method to work, an app has to deliberately go after this specific path, which means it has to be installed on the device already. No root access, ADB, or unusual system permission is required, which keeps the bar for abuse fairly low.
That doesn't mean every app on your phone leaks your IP automatically. The risk sits specifically with apps that were built maliciously from the start, or that were compromised later.
Google's response, and GrapheneOS's
This is where the story gets interesting. Google's security team initially classified the finding as "Won't Fix (Infeasible)" and decided it wouldn't appear in a security bulletin. After the issue went public, the company put out a statement saying the problem only affects devices that already have a malicious app installed, and that Google Play Protect shields users from known malicious apps.
GrapheneOS disagreed with that assessment and shipped its own fix, disabling the hardware offloaded keepalive path on supported Pixel devices. As of this article's publication, stock Android has no equivalent official patch.
VPN lockdown isn't pointless now
"Block connections without VPN" still stops the overwhelming majority of apps from sending traffic outside the tunnel. What changes is that it shouldn't be treated as an absolute, mathematical guarantee anymore. The same goes for terms like kill switch, which describe very strong protection, not perfect protection.
What you can actually do about it
There's no user-level setting right now that reliably closes this gap across every device. The most useful thing anyone can do is cut down the odds of malicious software landing on the device at all: install apps only from sources you trust, remove the ones you don't use anymore, and keep the OS updated.
Always-on VPN and blocking connections without VPN are still worth keeping on, even though they don't cover this specific case, because they cover everything else. Turning the VPN off over this finding would be counterproductive: without it, the real IP and the rest of the device's traffic are exposed permanently, not just in one narrow scenario.
Want a VPN with a kill switch and a genuinely transparent policy? Check K1VPN's subscription plans →
This isn't a VPN protocol problem
The leak has nothing to do with a weakness in WireGuard, OpenVPN, or IKEv2. The issue sits a layer below that, in how Android itself decides which packet goes through the VPN and which doesn't, before the protocol ever sees it. Switching servers or protocols won't fix anything here. The real fix has to come from the operating system, not the VPN provider.
The bottom line
A VPN remains one of the most effective tools for protecting your connection. But it runs on top of a device with its own operating system and its own apps, and that layer is never entirely out of the equation.
GrapheneOS's finding doesn't prove Android traffic leaks out of VPNs en masse. It shows something more specific: that a malicious app, under fairly narrow conditions, can pull out a device's real IP despite active lockdown protection. The sensible response isn't to switch the VPN off. It's to be careful about what you install.