A security flaw in Android 16 allows a malicious app to leak a user's real IP address straight past an active VPN tunnel - even when the device is set to its strictest lockdown mode. After the researcher who discovered the vulnerability disclosed it publicly last week, Google's Android Security Team classified it as "Won't Fix (Infeasible)" and declined to issue a security bulletin. GrapheneOS, the privacy-hardened alternative Android distribution, shipped a patch within days.
What the Flaw Does, and Why It Matters
A VPN is meant to function as a sealed conduit: every packet leaving the device travels through an encrypted tunnel, and the destination server sees only the VPN provider's IP address, not the user's real one. Android reinforces this with an "Always-On VPN" setting and a companion "Block connections without VPN" option - together, they are supposed to make the tunnel inescapable. This flaw breaks that guarantee.
The vulnerability, nicknamed the "Tiny UDP Cannon" by the researcher going by "lowlevel/Yusuf," lives in a small Android 16 feature designed to cleanly close certain network connections. When an app terminates a connection, it can hand Android a short farewell message to dispatch on its behalf. Android neither inspects the contents of that message nor checks whether the originating app is subject to the active VPN policy. It simply sends the packet out over whatever raw network interface is available - Wi-Fi or mobile - bypassing the encrypted tunnel entirely.
The permissions bar for exploiting this is notably low. A malicious app does not need any unusual capabilities; standard internet access, which nearly every app on a modern Android device already holds, is sufficient. That is a meaningful distinction. Many Android security flaws require elevated permissions or system-level access that would trigger scrutiny during installation or app store review. This one does not.
Google's Reasoning, and What It Signals
Google's decision to mark the issue "Infeasible" rather than assign it a CVE or include it in a monthly security bulletin reflects a real judgment call, not an oversight. The company's position appears to be that because successful exploitation requires a malicious app already running on the device, the threat model does not clear the bar for a formal fix - at least not at this time.
That reasoning is defensible for average consumers, where the attack chain is genuinely long: an adversary would need to craft a specifically built app, get it installed, and then trigger the leak. But it is significantly less defensible for the populations who rely most heavily on VPN lockdown mode. Journalists working in hostile environments, activists, lawyers handling sensitive communications, and security researchers often operate under the assumption that lockdown mode is a hard technical guarantee, not a soft one. For those users, the knowledge that a single compromised or malicious app can silently expose their real network identity matters enormously - regardless of whether the exploit is practical against everyday consumers.
It is also worth recognizing the precedent: Google's security triage process is shaped by aggregate risk across a very large user base. GrapheneOS serves a much smaller, self-selecting audience that skews toward users with unusually high privacy and security requirements. The two platforms are answering different questions about acceptable risk, which is precisely why their responses diverged.
GrapheneOS Acts, Stock Android Users Face Limited Options
GrapheneOS addressed the issue by disabling the vulnerable feature entirely in release 2026050400. The approach is blunt by design: removing the attack surface completely is more reliable than attempting to patch the logic around it, even if it means forgoing the minor networking efficiency the feature was meant to provide. The fix was publicly acknowledged and shipped in under a week from disclosure.
Users on stock Android 16 have fewer options. The researcher's write-up documents a manual mitigation using an ADB command that turns off the feature at the system level. However, this is not a durable solution. A factory reset or a future system update can revert the setting, which means the mitigation must be reapplied deliberately after any such event. For non-technical users, the ADB route is effectively inaccessible.
The practical options for stock Android users who depend on VPN lockdown for serious privacy protection currently reduce to three:
- Apply the ADB workaround and monitor for system updates that may revert it
- Migrate to a device running GrapheneOS, where the fix is already in place
- Accept that "Block connections without VPN" is not an absolute guarantee on the current Android 16 release
For the majority of Android users, the daily risk from this specific flaw remains low. The attack requires a malicious app on the device, which means the standard hygiene of sticking to reputable sources, reviewing app permissions, and keeping software updated still constitutes a meaningful first line of defense. A well-configured VPN continues to protect against the far more common threats of network-level surveillance and traffic interception. But this episode is a precise illustration of a broader tension in platform security: the layer protecting users is only as trustworthy as every layer beneath it.
