A security researcher has recently shed light on a significant vulnerability in Android 16 that undermines the integrity of VPN protections across all applications. This flaw allows for the leakage of user traffic outside the secure VPN tunnel, rendering the “Always-On VPN” and “Block connections without VPN” settings ineffective. Consequently, users may find their real IP addresses exposed to the internet, raising concerns over tracking and surveillance.
The Android 16 VPN Vulnerability Explained
The issue first came to my attention through a tweet from Yusef, a Zurich-based security researcher known on X as @cybaqkebm. His succinct observation, “Turns out ‘Always-On VPN’ and ‘Block connections without VPN’ features on Android aren’t that reliable,” piqued my interest. A link in his tweet led to a detailed technical report outlining the VPN bypass in Android 16.
At the heart of the matter is the revelation that the aforementioned settings, which are intended to ensure that no data escapes the device outside of the VPN tunnel, are fundamentally flawed. Given Google’s previous warnings regarding the risks associated with malicious VPNs, one might expect a more robust response to such a vulnerability. However, Yusef reported that the issue was dismissed by Google as “Won’t Fix,” citing it as outside their threat model.
In a related development, Mullvad VPN has also flagged this vulnerability on the Android issue tracker, emphasizing that it affects all VPN applications operating on the Android 16 platform. The technical overview provided by Yusef is particularly alarming:
A Binder method on ConnectivityManager, registerQuicConnectionClosePayload, accepts an arbitrary byte buffer and a UDP socket from any caller with INTERNET and ACCESSNETWORKSTATE (both auto-granted). When the registered socket dies, system_server sends the buffer on the socket’s original network. No permission check, no payload validation, no awareness of the VPN-lockdown state of the calling UID. With one slightly cute trick to slip past the fwmark server, an attacker app can use that primitive to leak the user’s real IP past an active VPN.
As I awaited a response from Google regarding this pressing issue and guidance for Android 16 VPN users, the only current mitigation appears to involve manually adjusting a DeviceConfig setting. However, this is not advisable for the average user. Yusef cautioned, “Use it only if you understand the implications and at your own risk.” Alternatively, users could consider switching to Graphene OS, which has already addressed the vulnerability, though this option may not be practical for most.
For now, the ball is in Google’s court. Whether the “won’t fix” designation will be revisited remains to be seen. While this is not the first instance of a security oversight from Google, there is hope that pressure from the media and app vendors may prompt a reconsideration of this critical issue.
