GrapheneOS lists fixes for two Android VPN bypasses reported by Mullvad

Record updated: October 28, 2026. Mullvad’s May and September warnings concern two separate Android platform paths that let a malicious installed app expose the device’s non-VPN public IP—even with Android’s VPN blocking controls enabled. They are not reports of a Mullvad account breach or broken tunnel encryption. Mullvad explicitly says the May issue affects all VPN apps, not just its own. (May warning, September warning)

The important update: GrapheneOS lists fixes for both paths. Its 2026050400 release disabled the QUIC connection-close optimization; 2026100200 disabled unprivileged hardware keepalives. The latter supersedes Mullvad’s September statement that GrapheneOS was still working on a fix. These are release changes addressing the named paths, not a guarantee against every Android VPN leak. (GrapheneOS release notes)

May 12: QUIC connection-close payload bypass

Mullvad’s May 12 warning describes an Android 16 bug involving registerQuicConnectionClosePayload. An app registers bytes for Android to send when a UDP socket closes. The problematic path lets the privileged system service send those bytes over the physical network rather than through the VPN, revealing the non-VPN public IP to the destination. (Mullvad technical explanation)

The original researcher reports a successful proof of concept on a Pixel 8 running Android 16 with Proton VPN and lockdown enabled. It required only the automatically granted INTERNET and ACCESS_NETWORK_STATE permissions—not root or a special runtime permission prompt. The payload could contain attacker-controlled bytes, so this is more than a fixed keepalive signal. That test establishes a particular configuration; it is not a device-by-device survey. (Original QUIC research)

GrapheneOS’s May 4 code change sets the feature’s enable flag to false, and its 2026050400 release notes identify the change as a VPN-leak fix. (Code change, release notes)

September 10: hardware-offloaded NAT-T keepalive bypass

Mullvad’s September 10 warning concerns a different mechanism: an app asks Android to maintain a UDP NAT-traversal keepalive using network hardware. The resulting UDP/4500 packets bypass the ordinary application routing and lockdown checks. Mullvad says exploitation needs no special permission and a proper repair requires Android system changes. (September warning)

The paper by Armin Šupuk narrows the demonstrated scope:

• A controlled access-point capture recorded packets outside the VPN on a Pixel 8 Pro running Android 16, with always-on VPN and lockdown enabled.
• Samsung and Nothing Android 16 devices admitted active Wi-Fi keepalive slots, but those observations did not provide equivalent independent packet captures.
• The packet format is fixed. The leak exposes the physical network’s source IP and timing; it does not provide arbitrary payload control like the QUIC path.
• Cellular packet emission was not measured. Broader Android 12+ exposure is based on framework and hardware analysis, not exhaustive runtime testing. Exploitation depends on usable unprivileged hardware-offload slots.

The author also discloses selling VPN Leak Guard, the commercial app used for some observations. (Original NAT-T paper, including limitations and competing interest)

GrapheneOS subsequently listed “disable unprivileged hardware keepalives since it creates a VPN leak” in release 2026100200. The NAT-T paper reports no testing of a patched Android build, so its packet captures do not independently validate that release change. (Release notes, paper limitations)

What users can do—and what does not fix both leaks

For the QUIC path, Mullvad publishes this advanced mitigation, requiring a computer with Android Debug Bridge and USB debugging enabled:

adb shell device_config put tethering close_quic_connection -1
adb reboot

It disables graceful QUIC shutdown, not QUIC generally. Mullvad says it persists across reboots but may be undone by system updates; server-side connections remain half-open until timeout. Use it only if you understand the system change. This command is not a mitigation for the hardware keepalive path. (Mullvad mitigation)

For hardware keepalives, Mullvad discussed filling the available hardware slots, but called that theoretical and unreliable: a malicious app might reserve a slot first. Mullvad said it had no plan to supply that workaround. Do not treat slot-filling as a verified fix. (Mullvad’s mitigation assessment)

For GrapheneOS users, check that the installed OS includes both named release changes and keep the system updated. Switching VPN providers alone does not address these Android paths. Both warnings recommend installing only trusted apps: these particular attacks require an app intentionally invoking the bypass mechanism. (May guidance, September guidance)

What remains unresolved

The QUIC researcher’s disclosure timeline reports that Android Security closed the report as “Won’t Fix (Infeasible)”; Mullvad repeats that account. Mullvad’s September post likewise reports that the keepalive submission was closed without action, while the NAT-T paper documents duplicate triage and a disclosure record without a fix-status update. These are attributed disclosure accounts, not confirmation of the patch status of every current Google or manufacturer build. (QUIC timeline, September account, NAT-T disclosure record)

The record establishes two disclosed bypass mechanisms, an advanced QUIC workaround, and named GrapheneOS release changes. It does not establish a comprehensive stock-Android patch inventory or a tested clean bill of health for a reader’s handset. Keep this platform record separate from the Mullvad Android app security assessment: an app assessment and operating-system enforcement are different evidence scopes.