How does the Android VPN lockdown bypass work?

A malicious app uses Android's public NAT-T socket-keepalive API to have UDP/4500 packets offloaded directly to the Wi-Fi or cellular hardware. Because the packets are sent from the network hardware, they bypass the check that all traffic must go through the VPN when 'Block all connections without VPN' is enabled, exposing the device's real IP address.

Which Android versions and devices are affected?

The technical report documents exposure 'across most Android 12+ devices', with packet captures verified on a Pixel 8 Pro, a Samsung SM-F966B, and a Nothing A059, all running Android 16. The proof of concept currently works on Wi-Fi hardware paths.

What is being done about the leak?

The researcher reported the issue to Google's Android Vulnerability Reward Program, but the report was closed without action. Mullvad says it is unlikely Google will fix it, and a proper fix requires Android system changes. GrapheneOS is aware of the issue and is working on a fix in its fork.

Android VPN Lockdown Bypass Leaks UDP/4500 Past the Tunnel

Mullvad disclosed a new Android leak yesterday: any app — no special permissions — can send traffic outside the VPN tunnel even with "Block all connections without VPN" enabled. The mechanism is Android's NAT-T socket-keepalive API: packets get offloaded to the Wi-Fi/cellular hardware and never pass the VPN-policy check, so your real IP hits the router as clean UDP/4500. The researcher, Armin Šupuk, filed it with Google's Android VRP. The report was closed without action. The fix is coming from GrapheneOS — the fork Google keeps at arm's length.

The receipts in the paper

Šupuk's technical report (published July 29, resurfacing now via Mullvad) isn't theory. A Pixel 8 Pro on Android 16 was captured emitting fixed-format keepalive packets at the 10-second minimum interval through the physical router. On a Samsung SM-F966B, a test harness held an active offload slot continuously for 24 hours 32 minutes while lockdown mode was on. A third OEM (Nothing A059) confirmed the public-path admission. Source history in the report shows the failure is structural: a privileged raw-fd API became a public UdpEncapsulationSocket path, validation was added and then reverted, and offload no longer checks the original caller's VPN policy.

And the kicker: scanning 4,679 distinct F-Droid/IzzyOnDroid Git origins found zero legitimate uses of the framework's IPsec/IKE/NAT-T APIs. The attack surface is public; its intended users are absent. PoC currently works on Wi-Fi hardware paths.

Who fixes it tells you who you can trust

The researcher reported it to the Android Vulnerability Reward Program. Closed without action. Mullvad's own conclusion: "we deem it unlikely that Google will do anything about it." Meanwhile GrapheneOS has the issue tracked (#8617 in their issue tracker) and is working on a fix — the same week they shipped a rewritten Messages app. Connect the dots: when the platform vendor declines a confirmed IP-leak in a user-facing security feature, and the only patch comes from the security-focused fork, "only install trusted apps" stops being the mitigation and becomes the diagnosis. Mitigation is ugly too — the hardware caps keepalive slots, so a sacrificial app can hog them, but a malicious app may have claimed its slot first. Until a fix lands, treat "Block connections without VPN" on stock Android as advisory, not enforced.

The receipts in the paper

Who fixes it tells you who you can trust

Related