Android hardware keep-alive leak lets apps bypass VPNs even with block-all enabled

A new Android traffic leak

VPN provider Mullvad has disclosed a newly discovered weakness in Android's networking stack that lets an app send traffic outside an active VPN tunnel. The leak works even when the system setting "Block all connections without VPN" is turned on — the option that is supposed to prevent exactly this scenario.

According to Mullvad's blog post, which surfaced on Hacker News, the malicious app does not need any special permission to carry out the attack. Any app installed on the device can trigger it.

How the bypass works

The leak abuses a feature Android uses to help with network address translation (NAT) traversal. The system can set up a keep-alive UDP connection and offload it to the device's Wi-Fi or cellular hardware, so the packets are emitted by the network chip rather than passing through the operating system's normal network path.

Mullvad explains that a malicious app can misuse this mechanism to fire UDP packets on port 4500 at any server on the internet. Because the keep-alive packets originate directly from the network hardware, they escape the enforcement that requires all traffic to go through the VPN when "Block all connections without VPN" is active. Since those packets never enter the tunnel, they expose the device's real IP address to whatever server the app communicates with.

Google reportedly declined to act

Mullvad says the researcher who found the issue reported it to Google's Android Vulnerability Reward Program, but the report was closed without action. The details of that report are not public, and Mullvad writes that, based on this outcome, it considers it unlikely that Google will do anything about the problem.

A proper fix would require changes to the Android system itself, according to Mullvad — meaning it is not something a VPN app can work around on its own. GrapheneOS, the security-focused Android fork, is aware of the issue and is working on a fix, the post notes.

Mitigation options are limited

Mullvad describes one theoretical mitigation: network hardware only supports a limited number of simultaneous keep-alive connections, so an application could occupy all available slots and leave none for a malicious app to use.

The company does not plan to ship that workaround itself, for two reasons. It would still involve sending packets outside the tunnel — even if only to a Mullvad-owned server — and there is no guarantee it would help, because a malicious app may already have initiated its keep-alive connection before the VPN app even starts.

Mullvad's practical advice is conventional: install only apps you trust, and, where possible, use a security- and privacy-focused Android fork such as GrapheneOS.

Why it matters

"Block all connections without VPN" is the setting privacy-conscious users rely on for a hard guarantee — journalists, activists, and anyone using a VPN specifically to hide their IP address. This leak turns that guarantee into a best-effort promise: with zero permissions, any app on the device can reveal a user's real IP to a server it controls, enabling the tracking or surveillance the VPN was meant to prevent.

The issue also illustrates a broader problem with offloading networking tasks to hardware: paths that bypass the operating system's normal network stack can also bypass its policy enforcement. And when vendors decline to treat such bypasses as vulnerabilities, users of stock Android are left with no real defense beyond careful app hygiene, while GrapheneOS users can at least look forward to a patch.