Android 16 VPN bypass: Tiny UDP Cannon explained

Tiny UDP Cannon is a real Android VPN bypass, but the alarming version of the story needs one important qualification. The public proof shows that an installed malicious app can make Android send a small UDP payload outside an active VPN. Whether that path works on your phone depends on the Android build and whether its QUIC-close feature is enabled.

The bypass was demonstrated on a Pixel 8 running Android 16 with Proton VPN, Always-on VPN and "Block connections without VPN" enabled. It is an Android networking problem, not a Proton VPN flaw. Mullvad warned that the active flaw affects VPN apps generally because the packet is sent by a privileged Android process after it has left the VPN app's control.

What has been confirmed, and what remains uncertain

The original disclosure is the main technical source. GrapheneOS's patch, Mullvad's warning and the public Android code support the mechanism, but most news articles trace back to that same research. They are additional coverage, not multiple independent lab reproductions.

How Tiny UDP Cannon gets around Android VPN lockdown

Android 16 added a feature intended to close QUIC connections cleanly. An app can register a final payload, socket and destination. When the original socket disappears, Android's registerQuicConnectionClosePayload path lets system_server send the final UDP packet on the app's behalf.

That division of work creates the bypass. Android normally applies VPN routing and lockdown rules to the app's user ID. system_server runs with system privileges and needs access to physical networks for legitimate operating-system work. If a malicious app can hand arbitrary bytes to that process, the later send no longer looks like traffic from the restricted app.

The published attack follows this sequence:

1. The app finds an underlying physical network and its local address.
2. It creates a UDP socket associated with that network without sending a packet yet.
3. It registers an attacker-chosen payload and destination with Android.
4. The app closes its socket or exits.
5. Android's privileged process recreates the send on the physical network, outside the VPN tunnel.

The attacker-controlled server receives the datagram from the phone's normal internet connection and therefore sees the public IP supplied by the Wi-Fi or mobile carrier. The VPN does not get a chance to route or block that packet.

What can leak, and what cannot

The proof demonstrates a narrow outbound channel. It can reveal the underlying public IP address and carry a small attacker-chosen payload, such as an app identifier or correlation token. That can be enough to link VPN activity with a real network address.

It does not automatically:

• decrypt HTTPS traffic;
• let a random website run the attack;
• move every app or the full browsing session outside the VPN;
• give the attacker the phone's files without another access path; or
• prove that the VPN provider logged or exposed anything.

This makes the risk easy to understate and easy to exaggerate. It is not a full device takeover. It still breaks a specific promise in Android's own documentation, which says that the system can force all traffic to use the VPN when "Block connections without VPN" is on.

Who is at risk

The published route needs all of these conditions:

• an Android build containing the vulnerable QUIC-close path;
• the feature enabled on that build;
• a malicious or compromised app installed on the device;
• the app able to reach the Android system service with common network permissions; and
• an underlying Wi-Fi, mobile-data or other physical network available.

The app does not need root or a sensitive permission prompt in the published proof. It uses INTERNET and ACCESS_NETWORK_STATE, both common permissions that users rarely notice. Google told TechRadar that the issue only affects devices with a malicious app installed and pointed to Google Play Protect as protection against known malicious apps. That lowers risk for ordinary users, but it does not turn common network permissions into an effective warning.

Is your current Android build vulnerable?

There is no reliable consumer-facing toggle for this exact feature. The researcher's proof of concept repository says the flag was enabled on the build used for the demonstration but disabled by default on an April 2026 patched build. The code path remained present. That is why the safe answer is build-specific rather than "all Android 16 phones".

Advanced users with ADB access can inspect the current status:

adb shell dumpsys connectivity | grep "Close QUIC"

• Close QUIC connection: false means the feature is off on that build, so the published path cannot fire in its documented form.
• Close QUIC connection: true means the path is active. It is a reason to apply the mitigation or seek an OEM answer, not conclusive proof that every OEM-specific detail remains exploitable.

Our July 15 review of the current public AOSP ConnectivityService source still found the registration method behind a feature check and no visible permission enforcement in that entry point. Source presence alone does not reveal the server-side flag state on a phone in your hand.

Mitigations that match the actual threat

1. Install Android and OEM security updates

Start with the newest stable system and Google Play system updates available for your device. A newer build may disable the feature even if the underlying code remains. Do not avoid security updates because an older build was used for this proof.

2. Remove apps you do not trust

Exploitation begins with an installed app. Remove abandoned, repackaged or unnecessary apps, especially those installed from sources you cannot verify. Play Protect can catch known malicious software, but no app store or scanner can promise to identify every new or compromised app.

3. Use the ADB feature switch only if you understand it

The original researcher and Mullvad document this current-release mitigation:

adb shell device_config put tethering close_quic_connection -1
adb reboot

The command disables the graceful QUIC-close optimization. Server-side QUIC sessions may remain half-open until they time out, which the sources describe as a small cost. The setting survives normal reboots, but a factory reset clears it and a later system update may override it or remove the flag. USB debugging also expands the control a connected computer has over your phone, so switch it off again when you are finished.

4. Consider an OS-level fix for a strict threat model

GrapheneOS release 2026050400 disabled the optimization in its source code. That closes this route on supported GrapheneOS devices without asking each user to maintain a DeviceConfig override. Switching operating systems is a major decision, not a universal recommendation, but it is the clearest published platform-level response.

Why a browser IP leak test cannot certify this fix

A browser test asks: "Which IP addresses and DNS paths does this browser expose right now?" Tiny UDP Cannon asks Android to send a different packet to a destination chosen by an installed app. Your browser can show the VPN exit IP at the same moment that the separate UDP packet reveals the underlying public IP to the attacker's server.

You should still run DoVPN's IP leak test to check the leak types it can observe. Our Android leak-testing guide adds network-switching checks, and the VPN kill-switch test covers ordinary tunnel failures. Those checks are useful, but they answer different questions from the ADB feature-state check above.

Does choosing another VPN help?

Not against this Android path while it is active. The packet leaves below the VPN app's control, so changing protocol or provider does not give the app a chance to capture it. Mullvad explicitly said the issue affects all VPN apps when the vulnerable feature is in use.

VPN choice still matters for everyday privacy. A provider can support Android lockdown, maintain its app, respond clearly to platform bugs, publish audits and avoid making absolute promises that the OS cannot keep. Once the Android layer is patched or the feature is disabled, use our VPN comparison to evaluate those provider-level differences. For the basics of what an exposed address reveals, read what an IP leak is.

Sources and discussion

These sources provide the strongest public record we found:

• The original Tiny UDP Cannon disclosure, including the technical explanation, disclosure timeline and ADB mitigation.
• The researcher's proof-of-concept repository, which documents tested builds, feature-state checks and authorized reproduction.
• Mullvad's May 12 security notice, which states that the Android-layer issue is not limited to Mullvad.
• GrapheneOS release 2026050400 and its linked source patch disabling the feature.
• TechRadar's report with Google's response confirming the malicious-app requirement and Google's Play Protect position.
• Community discussion on Privacy Guides and r/programming shows why app permissions, flag state and the meaning of "all devices" remain the main points of debate.

The original author says the Android Security Team closed the private vulnerability report as "Won't Fix (Infeasible)" and excluded it from the Android Security Bulletin. Mullvad later filed a public issue, but said it was inaccessible at the time of its post. That limits independent review of Google's original triage notes, so the closure details should be attributed to the researcher rather than presented as a public Google advisory.