On September 10, Mullvad warned of a new method for circumventing the VPN on Android. A malicious application can dispatch service packets directly to the internet even when the “Block connections without VPN” setting, which ought to forbid such traffic, is enabled. The recipient of these packets sees the user’s real external network IP address, even though the VPN continues to operate. Mullvad detailed the finding in its blog post on another way to leak traffic on Android.
How the Bypass Was Discovered
The problem was investigated by Armin Šupuk, who published a technical breakdown as early as July 29. The method he described reveals the network address and allows the device’s presence on a network to be tracked, yet it does not transmit arbitrary application content. Android dictates the format of the service packet, while the malicious program merely chooses the recipient’s address. To mount the attack, ordinary network permissions suffice, which the system grants without any separate prompt to the user.
The Role of NAT-T Keepalive
The bypass is bound up with the NAT-T keepalive mechanism. Small, periodic packets help sustain a connection through devices that perform address translation. Android may delegate the sending to the network chip, so as not to wake the application for each packet. As Mullvad explains, when this task is handed to the hardware, the system skips the check that should route traffic through the VPN or block the direct connection.
The Pixel 8 Pro Experiment
In an experiment with a Pixel 8 Pro, the researcher recorded, on a separate router, UDP packets sent to port 4500 every ten seconds while the blocking of connections without VPN was active. The tests also covered the Samsung Galaxy Z Fold7 and Nothing Phone (3a) running Android 16. For the latter two models, however, the author confirmed the hardware mechanism worked without an equivalent external packet capture. Armin Šupuk surmises that the problem is widespread among devices running Android 12 and newer, drawing on shared system code and firmware analysis. He did not conduct full tests on every model.
Persistence and Limits of the Leak
Once launched, the sending may continue with the screen locked and in power-saving modes. According to the tests, force-stopping or uninstalling the application, losing the network, and rebooting all halted the active transmission. The publications describe research trials and offer no evidence of the method being used in real-world attacks.
Google’s Response and the Road to a Fix
According to Armin Šupuk’s timeline, Google received the report on May 15 and, on May 19, marked the submission as a duplicate of an earlier filing. In the correspondence available to the researcher, there is no confirmation of a fix or the assignment of a CVE. Closing a report as a duplicate does not, in itself, mean the developers have remedied the vulnerability.
For a proper fix, Mullvad considers changes to Android necessary. The GrapheneOS team is aware of the problem and, per Mullvad, is working on a defense. As of a check on September 12, the corresponding GrapheneOS issue remained open, so the alternative system cannot yet be deemed protected against the new bypass.
A Fragile Promise Broken Twice
Mullvad also described a potential temporary measure. A protective application could seize the available hardware resources for keepalive packets before a malicious program does. The company does not plan to add such a defense, since the approach itself requires traffic outside the tunnel and offers no help if the attacker acts first.
A May Android vulnerability exploited a different mechanism. An application instructed the system to send a final message when closing a QUIC connection, and Android released the packet past the VPN. GrapheneOS then disabled the problematic function. This new case concerns periodic hardware packet transmission and demands a separate fix. Within a few months, researchers have demonstrated two distinct paths that let an ordinary application break the promise of the “Block connections without VPN” system setting.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.