Android 16 VPN bypass can reveal a user’s real IP address

A newly disclosed Android 16 VPN bypass can let a regular app send a small UDP packet outside an active VPN tunnel, even when Always-On VPN and Block connections without VPN are enabled.

The issue, named Tiny UDP Cannon by the researcher who published it, can expose the device’s real public IP address to an attacker-controlled server. The leak does not require special app permissions beyond INTERNET and ACCESS_NETWORK_STATE, which Android grants automatically in normal app workflows.

The researcher tested the bypass on a Pixel 8 running Android 16 with Proton VPN enabled and VPN lockdown mode active. Mullvad later warned that the issue affects all VPN apps on Android 16 because the leak comes from Android’s network stack, not from one VPN provider.

How the Android 16 VPN bypass works

The bypass abuses a system feature designed for graceful QUIC connection shutdowns. Android added a method called registerQuicConnectionClosePayload so the system can send a final UDP payload when an app’s QUIC socket closes.

That feature creates the privacy problem. Instead of sending traffic directly, a malicious app can hand a payload and destination to Android’s system_server process. When the app exits or the socket closes, system_server sends the packet on the app’s behalf.

Because system_server runs with elevated networking privileges, Android’s VPN lockdown rules do not block the packet in the same way they would block traffic from the app itself. The VPN never sees the packet, while the destination server sees the user’s real public IP address.

Item	Details
Name used by researcher	Tiny UDP Cannon
Affected platform	Android 16, including tested Pixel 8 builds
VPN settings bypassed	Always-On VPN and Block connections without VPN
Required app permissions	INTERNET and ACCESS_NETWORK_STATE
Leaked data	Small attacker-controlled UDP payload and real public IP address
Reported to Google	April 12, 2026

Why Always-On VPN does not stop the leak

Android’s VPN lockdown mode normally blocks apps from reaching physical networks directly. If an app tries to bind a socket to Wi-Fi while VPN lockdown is active, Android should reject that connection.

The Tiny UDP Cannon bypass avoids that direct path. The app creates a socket in a way that records the Wi-Fi source address, then registers a QUIC close payload with Android’s connectivity service.

When the socket dies, system_server creates and sends the UDP packet using the recorded network. Since Android treats system_server as a privileged system component, the packet can leave through Wi-Fi instead of the VPN tunnel.

What an attacker could learn

The main privacy impact is real IP exposure. A malicious app could send a tagged packet to a server controlled by the attacker, allowing that server to see the device’s non-VPN public IP address.

This matters most for users who rely on VPN lockdown mode to hide their network location from apps or services. It also creates risk for journalists, activists, travelers, researchers, and users in hostile network environments.

The published research focuses on a small UDP leak, not full device compromise. It does not show that attackers can read all VPN traffic, decrypt VPN sessions, or take control of the phone through this bug alone.

• A malicious app can reveal the user’s real public IP address.
• The app does not need dangerous permissions.
• The leak can bypass Android’s VPN lockdown setting.
• The VPN provider cannot fully fix the issue inside its own app.
• The attack works by making Android’s system_server send traffic for the app.

Google closed the report as Won’t Fix

The researcher reported the issue through Google’s Android Vulnerability Reward Program on April 12, 2026. According to the disclosure timeline, Android Security closed the report on April 18 as Won’t Fix and marked it as Not Security Bulletin Class.

The researcher appealed the decision the same day, arguing that a third-party app with only auto-granted permissions could leak the real IP address despite VPN lockdown mode. Google’s decision did not change on April 24.

Google cleared the researcher to disclose the issue on April 29. The public write-up appeared on April 30, with a proof-of-concept app and a technical explanation of the bypass.

VPN providers cannot fully solve it alone

Mullvad said the Android 16 bug affects all VPN apps, not just Mullvad VPN. That is because the packet comes from Android’s system_server, outside the normal app traffic path a VPN app controls.

A VPN provider can warn users and help them test for leaks, but it cannot rewrite Android’s system networking behavior from inside a normal VPN app. The operating system needs to enforce the lockdown decision before system_server sends the packet.

That difference matters. Users may think switching to another VPN provider solves the problem, but the underlying bypass sits below the VPN app layer.

GrapheneOS already disabled the vulnerable path

GrapheneOS responded by disabling the registerQuicConnectionClosePayload optimization in its 2026050400 release. Its release notes specifically say the change fixes a VPN leak.

The GitHub Advisory Database also lists CVE-2026-45182 for GrapheneOS before 2026050400. The advisory describes the same issue: an app can let system_server transmit UDP traffic on its behalf while Always-On VPN and Block connections without VPN are enabled.

That CVE currently applies to GrapheneOS’s earlier exposure, not a stock Android bulletin entry. The broader stock Android issue remains notable because Google has not treated it as an Android Security Bulletin vulnerability.

Platform	Status
Stock Android 16	Researcher and Mullvad report VPN bypass behavior
Google Android Security	Closed the report as Won’t Fix and Not Security Bulletin Class, according to the researcher
GrapheneOS	Disabled the optimization in release 2026050400
VPN apps	Affected because the issue sits in Android’s system networking layer

Temporary mitigation requires ADB

The researcher and Mullvad both point to a temporary mitigation that disables the QUIC close payload feature through Android’s DeviceConfig system. It requires Android Debug Bridge access and a reboot.

The mitigation uses this command:

adb shell device_config put tethering close_quic_connection -1
adb reboot

After rebooting, the device should stop accepting registrations for the QUIC close payload path, which blocks this specific leak. However, the mitigation may not survive a factory reset, and a future Android Mainline update could remove or change the flag.

What Android users should do now

Most users should avoid installing apps they do not trust, especially on devices where VPN privacy matters. The bypass needs a local app to run code on the device, so app hygiene still reduces exposure.

Users who understand ADB can apply the temporary mitigation. People who depend on strict VPN leak prevention may also consider whether a security-focused Android distribution with the fix fits their threat model.

Android users should also continue installing system updates. Delaying updates to avoid one network issue can leave the device open to more serious security flaws.

• Install apps only from trusted sources.
• Keep Android system updates enabled.
• Use the ADB mitigation only if you understand the risk and trade-off.
• Check whether your Android distribution has disabled the vulnerable QUIC optimization.
• Do not assume changing VPN providers fixes this specific Android behavior.
• Use a separate high-risk device profile if your work depends on strong network anonymity.

Why this matters for mobile privacy

VPN lockdown settings create a clear user expectation: traffic should not leave the device outside the VPN. Tiny UDP Cannon shows how system-level exceptions can break that promise in narrow but important ways.

The flaw also highlights a broader design challenge. Mobile operating systems increasingly add background networking features for performance and reliability, but those features must still preserve privacy boundaries set by the user.

For privacy-sensitive users, even a small packet can matter if it links app activity to a real network address. For platform vendors, the incident shows why VPN lockdown needs enforcement across privileged system helpers, not only ordinary app UIDs.

FAQ