Most Android Phones Since 2021 Can Leak Traffic Outside the VPN, Audit Finds

A user can tap "Always-on VPN" and "Block connections without VPN" in Android settings and reasonably expect that anything those apps send will not leave the phone except through the encrypted tunnel. On most Android 12+ devices, that expectation is wrong. A public Android networking API that any ordinary app can call can keep a small, fixed-format packet flow alive directly to the home router on the physical Wi-Fi path, outside the VPN, with lockdown enabled, and even when the app is in the background.

The finding comes from a single researcher publishing as supuk. The full paper, "Android NAT-T Keepalive Offload Bypasses VPN Lockdown: Device-Class Exposure Across Most Android 12+ Devices," traces the bypass to a specific framework path: the public UdpEncapsulationSocket class, [documented under IpSecManager](https://developer.android.com/reference/android/net/IpSecManager.UdpEncapsulationSocket). That class is the same plumbing phones use to keep an IPsec/VPN connection alive across a NAT router. It sends UDP packets to port 4500, the standard NAT-traversal port, at a fixed interval of once every 10 seconds, which is the public minimum the API allows.

A shorter companion post and a separate write-up at lowlevel.fun walk through how the API can be invoked from an ordinary app, with no root or VPN permission required and no user-visible prompt. The packets bypass the tunnel because Android's networking stack classifies the keepalive flow as offloaded to the hardware abstraction layer before the VPN policy is applied. Once offloaded, the packets ride the physical Wi-Fi interface directly, so they reach the home router even when the user has asked Android to block all non-VPN traffic.

The root cause, per the paper, is a collapsed trust model inside startNattKeepaliveWithFd(...). A once-privileged path that accepted a raw file descriptor from a system process evolved, across Android 12 and later, into a public path that accepts a UdpEncapsulationSocket from any caller. The current admission step no longer authenticates the file-descriptor and resource pair, and it does not re-check the original caller's UID against the active VPN policy before handing the flow off to the offload layer. A vendor advisory from Mullvad reaches the same conclusion from a different angle.

The evidence is not theoretical. On a Pixel 8 Pro running Android 16 build CP1A.260505.005, a controlled access-point capture recorded keepalive packets leaving the device at the 10-second interval while Always-on VPN and "Block connections without VPN" were both enabled. On a Samsung SM-F966B on Android 16, Mullvad's VPN Leak Guard observed the active callback and recorded a continuous router-directed active-slot lease that ran for 24 hours and 32 minutes. On a Nothing A059 on Android 16, public-path admission and the active callback were confirmed on a third OEM; the Hacker News thread on the disclosure traces the same shape on the third device. The third-OEM confirmation rests on the active-callback signal alone: the researcher did not run an independent packet capture on the Nothing device.

The bypass also survives the lifecycle boundaries Android users actually rely on. On the Pixel 8 Pro, the paper documents that the keepalive flow continued across backgrounding, lock screen, Doze, battery saver, the restricted standby bucket, the Binder freezer, and the observed force-stop, uninstall, network-loss, and reboot boundaries. The flow does not need the app to be running, which is the property that makes it usable for silent exfiltration.

The device-class scope is the part that turns this from a bug report into a market-wide finding. The firmware-coverage analysis spans seven WLAN chipset families estimated to represent 91.24% of Android-derived shipments. The remaining 8.76% is explicitly unresolved by the analysis, not disproven. The shared surface is in the Android framework, not in any one OEM's modem firmware, which is why the finding reproduces across three vendors.

A second datapoint comes from an app-ecosystem scan. The researcher looked at 4,679 distinct stored Git origins in the F-Droid and IzzyOnDroid indices, and a static scanner found no use of the Android framework's IPsec, IKE, or NAT-T APIs in that set. A manual audit then surfaced 73 Android VpnService apps. The current best read is that no popular app in those indices is exploiting this today, but the API is reachable from any app that wants it.

Google has not queued a coordinated security patch. In correspondence quoted on Hacker News, the company classifies the leak as "a valid bug, not a security bug," and security-bounty reports outside that scope are closed. Google has said it plans a heavy overhaul of the Android VPN implementation "to make most forms of leaks nearly impossible," but has not committed to a disclosure timeline. That posture is the strongest reason a reader should not wait for a single fix.

What works today is narrow. Android already requires a device PIN to enable Always-on VPN, and the platform does not expose nft access for traffic filtering, so there is no first-party way to write an outbound rule that would block UDP/4500 keepalives. Among the major consumer VPN clients, Mullvad is the only one that has publicly shipped a Leak Guard path that detects the active callback and tears the active slot down. Samsung's "Always On Disallow" toggle and the per-app VPN profiles in Android 14+ do not close this hole, because the offloaded packets leave the device before those profiles are consulted. Until Google changes the framework, the practical answer for a user who needs Always-on VPN to mean what it says is to pick a VPN client that monitors the active callback, and to treat "Block connections without VPN" as defense in depth, not a guarantee.