GrapheneOS Patches Android VPN Leak After Google Declines Fix

A critical vulnerability in Android 16 has highlighted a recurring tension between the security priorities of mainstream OS developers and the needs of privacy-conscious users. Recently, security researcher Yusuf (lowlevel.fun) disclosed a flaw that allowed applications to bypass Android's "Always-On VPN" and "Block connections without VPN" protections, leaking the device's real public IP address to remote servers.

While Google declined to patch the issue, GrapheneOS—a security-hardened fork of Android—stepped in to neutralize the attack vector in less than a week.

The Anatomy of the Leak

The vulnerability stems from a newly introduced QUIC connection teardown feature in Android's networking stack. QUIC is a UDP-based multiplexed and secure transport protocol designed to improve performance. To allow applications to gracefully terminate sessions when sockets are unexpectedly destroyed, Android introduced an API that allows apps to register a specific payload to be sent upon closure.

According to the technical analysis, the flaw exists because the implementation accepted arbitrary UDP payloads without validating whether they were legitimate QUIC CONNECTION_CLOSE frames. More critically, it failed to verify if the originating application was restricted to VPN-only traffic.

The Attack Vector

An application requiring only the standard INTERNET and ACCESS_NETWORK_STATE permissions could register an arbitrary UDP payload with the system_server. When the application's UDP socket was subsequently destroyed, the privileged system_server process would transmit the stored payload directly over the device's physical network interface.

Because the system_server operates with elevated networking privileges and is exempt from VPN routing restrictions, the packet bypassed all lockdown protections. This effectively turned a privileged system process into a proxy for leaking identifying network information.

Google's Response: "Won't Fix"

Despite the severity of the leak, Google's security team classified the report as "Won't Fix (Infeasible)" and "NSBC" (Not Security Bulletin Class). Google maintained that the issue did not meet the threshold for inclusion in official Android security advisories and authorized public disclosure on April 29, 2026.

This decision has sparked significant debate among the technical community. Some observers argue that the classification is a failure of security logic, noting that the flaw represents a combination of app sandbox escape and privilege escalation.

I'm utterly confused why the Android security team at Google won't take this more seriously. [The breach] demonstrates more than one failure... [it] essentially amount[s] to app sandbox escape and privilege escalation.

Other critics suggest the refusal to patch is rooted in business interests, arguing that Google's business model relies on the ability to track users, making a truly "leak-proof" VPN implementation contrary to their goals.

The GrapheneOS Solution

GrapheneOS responded by disabling the underlying registerQuicConnectionClosePayload optimization entirely in release 2026050400. By removing the optimization that enabled the leak, GrapheneOS effectively neutralized the attack vector for supported Pixel devices.

Beyond this specific fix, the release also included the May 2026 Android security patch level, Linux kernel updates, and expanded Dynamic Code Loading restrictions, further distancing itself from the security posture of stock Android.

Mitigations for Stock Android Users

For users who cannot switch to GrapheneOS, the researcher provided a temporary manual mitigation via the Android Debug Bridge (ADB). Users can disable the close_quic_connection DeviceConfig flag. However, this workaround is fragile; it requires developer access and may be overridden by future Google updates.

Conclusion

This incident underscores the fundamental difference in philosophy between stock Android and hardened alternatives. While Google views the QUIC optimization as a feature and the resulting leak as a marginal security risk, GrapheneOS views the preservation of the VPN tunnel as an absolute requirement. For users whose anonymity and security depend on the integrity of their network routing, this case serves as a stark reminder of the limitations of "Always-On" protections in mainstream mobile operating systems.