GrapheneOS patches Android VPN leak after Google declined to fix it

TL;DR – A newly discovered Android 16 bug allowed ordinary apps to bypass the system‑level VPN lock‑down and expose the device’s public IP address. Google refused to issue a fix, calling the issue “Not Security Bulletin Class.” The GrapheneOS project responded by disabling the problematic QUIC‑connection‑close optimization in its May 2026 update, effectively neutralising the attack on supported Pixel phones.

---

What the vulnerability actually did

The flaw, disclosed by security researcher lowlevel/Yusuf on lowlevel.fun, lives in the registerQuicConnectionClosePayload path inside system_server. When an app with only the default INTERNET and ACCESS_NETWORK_STATE permissions creates a UDP socket and later destroys it, the kernel‑level QUIC teardown routine stores the payload supplied by the app. On socket destruction, system_server forwards that payload directly to the physical network interface without consulting the VPN routing table.

Because system_server runs with elevated networking privileges and is exempt from the VPN’s “always‑on” and “block connections without VPN” policies, the packet slips past the tunnel and reaches the internet unencrypted. The payload can be a simple HTTP request that returns the device’s public IP, effectively leaking the user’s location information.

The attack chain is straightforward:

1. Install any app (or even a benign test binary) that can open a UDP socket.
2. Send a crafted QUIC CONNECTION_CLOSE frame as the socket is torn down.
3. system_server forwards the frame over the raw interface, bypassing the VPN.
4. The remote server sees the true IP address.

Caption: Simplified flow of the QUIC‑based VPN bypass

The researcher demonstrated the exploit on a Pixel 8 running Android 16 with Proton VPN and Android’s lockdown mode enabled. The device’s real IP was visible to a remote listener despite the VPN being active.

Why Google left it unfixed

After the disclosure, the Android security team classified the bug as “Won’t Fix (Infeasible)” and “NSBC” (Not Security Bulletin Class). Their justification was that the vulnerability required a specific sequence of API calls that they deemed unlikely to be exploited in the wild, and that a patch would require a substantial re‑architecture of the QUIC handling code.

The researcher appealed, pointing out that the required permissions are granted to any network‑enabled app, and that the exploit works on stock devices out‑of‑the‑box. Google’s response remained unchanged and authorized public disclosure on April 29, 2026.

From a practical standpoint, the decision reflects a broader tension in Android’s security model: the platform balances performance optimisations (like the QUIC close‑payload shortcut) against strict network isolation. Google appears to have judged the performance gain as outweighing the relatively low‑risk scenario, at least for the mainline release.

GrapheneOS’s concrete mitigation

Rather than waiting for a Google patch, the GrapheneOS team took a pragmatic approach. In their May 2026 build (release 2026050400), they disabled the registerQuicConnectionClosePayload optimisation entirely. The change lives in the OS’s system_server configuration and is applied at boot time, so no custom kernel recompilation is needed.

Key points of the GrapheneOS fix:

• The QUIC optimisation is turned off for all supported Pixel models (Pixel 6‑a and newer).
• The change does not affect normal QUIC traffic; it merely prevents the system from injecting arbitrary payloads on socket teardown.
• The patch is shipped alongside the full May 2026 Android security patch level, updated hardened_malloc, kernel upgrades across Android 6.1/6.6/6.12, and a back‑ported libpng fix (CVE‑2026‑33636).
• Vanadium (GrapheneOS’s hardened Chromium fork) receives a newer build, and Dynamic Code Loading restrictions are tightened.

For users of stock Android, the researcher published a temporary ADB‑based workaround: disabling the close_quic_connection flag via adb shell cmd device_config put net_quic close_quic_connection false. This requires developer‑mode access and may be reverted by future OTA updates, making it a stop‑gap rather than a solution.

Limitations and remaining concerns

While GrapheneOS’s fix blocks the specific QUIC‑payload path, it does not address the underlying design choice that lets system_server bypass VPN routing for privileged processes. Any future optimisation that writes directly to the network stack could re‑introduce a similar bypass.

Additionally, the mitigation is limited to devices running GrapheneOS. The majority of Android users remain on stock builds, which still lack an official fix. Until Google revisits the design, those devices are exposed to the same leak.

From a threat‑model perspective, the attack is most relevant to privacy‑sensitive users—journalists, activists, and anyone relying on a VPN for location masking. For typical consumers, the risk is lower because the exploit requires a malicious app to be installed, and most users do not run unknown binaries with network permissions.

What this says about Android’s security process

The episode highlights two recurring patterns:

1. Performance‑first decisions can create side‑channels. The QUIC optimisation was introduced to reduce latency on connection teardown, a legitimate goal, but it opened a path for data exfiltration.
2. Google’s advisory criteria may overlook low‑complexity, high‑impact bugs. Classifying the issue as “NSBC” effectively deprioritised it, despite the fact that a single line of code allowed arbitrary payload injection.

Projects like GrapheneOS demonstrate the value of an independent security‑focused fork: they can act quickly, disable risky features, and ship hardened updates without waiting for upstream approval.

---

Bottom line

The Android 16 VPN bypass was a clear example of a performance optimisation colliding with privacy guarantees. Google’s refusal to patch left a gap that GrapheneOS filled by turning the feature off entirely. For users who need strong network isolation, moving to a hardened OS remains the most reliable mitigation until Google revises its QUIC handling logic.

---

Further reading

• Yusuf’s full technical write‑up on lowlevel.fun
• GrapheneOS release notes for May 2026: grapheneos.org/releases/2026050400
• Android’s official security bulletin policy: source.android.com/security/bulletin