Your Android VPN Kill Switch Has a Hole No App Can Patch (Port 4500 Explained)

What Mullvad Disclosed on September 10, 2026

Mullvad's post, "Another way to leak traffic on Android has been discovered," describes a malicious app asking Android to set up a hardware-offloaded NAT-T keep-alive connection. In Mullvad's own words: "these keep-alive UDP packets are sent directly from the network hardware, they bypass the check that all traffic must go through the VPN connection when 'Block all connections without VPN' is enabled, thus exposing the device's real IP address."

Mullvad is explicit that it has no plan to mitigate this itself: "Mullvad does not currently have any plan to provide this theoretical mitigation ourselves as it would still involve sending packets outside to the tunnel." It also warns that even a theoretical app-side mitigation "is not guaranteed to work, as a malicious app may have already initiated the leak before the Mullvad app is started."

That is the differentiator versus every generic "best VPN for Android" article: the company that surfaced this bug to the public is telling you, directly, that its own product cannot fix it. Read the full post at mullvad.net.

Who Actually Found This

Mullvad did not discover the bug. The researcher is Armin Šupuk, a Swiss developer who published the underlying paper, "Android NAT-T Keepalive Offload Bypasses VPN Lockdown: Device-Class Exposure Across Most Android 12+ Devices," on July 29, 2026. Mullvad linked to it and amplified the disclosure through its own blog on September 10.

The timeline

• May 2026 — Šupuk reports the issue to Google's Vulnerability Rewards Program
• 29 Jul 2026 — Šupuk's paper is published
• 27 Aug 2026 — Šupuk opens GrapheneOS issue tracker ticket #8617
• 31 Aug 2026 — A GrapheneOS maintainer commits to a fix, at lower priority than other in-flight leaks
• 10 Sep 2026 — Mullvad publishes its blog post, amplifying the disclosure
• 15 Sep 2026 — The GrapheneOS ticket thread is locked "off topic", no shipped-fix comment posted before the lock

Pieced together from Šupuk's own GitHub comments on GrapheneOS issue #8617 and the paper's publication date. The exact Google VRP report date is not published; "May 2026" is the researcher's own approximate framing.

The Exact Mechanism

UDP port 4500 is the standard NAT-Traversal (NAT-T) port for IPsec, used once IKEv2/IPsec detects it's behind a NAT (the IKE handshake starts on port 500 and moves, or "floats," to 4500). NAT-T keepalives are tiny UDP packets, commonly just a single byte, sent periodically to keep that NAT mapping open. Wi-Fi calling and always-on IPsec tunnels depend on these keepalives, which is exactly why Android exposes an API to let a chip send them without waking the main processor: it saves battery.

Šupuk's paper, read directly, confirms the exact public API chain a malicious app can walk to abuse this: it calls IpSecManager.openUdpEncapsulationSocket(), then ConnectivityManager.createSocketKeepalive(), then keepalive.start(10). Internally, that converges on a Binder method called IConnectivityManager.startNattKeepaliveWithFd() — the same underlying call a now-restricted, privileged raw-socket path used to reach before Android opened up the public UdpEncapsulationSocket route back in March 2019. Crucially, the public path requires no dangerous permission and no privileged PACKET_KEEPALIVE_OFFLOAD permission at all.

Once that keepalive is registered, Android hands the job to the Wi-Fi or cellular chip's firmware. The chip sends the packet on its own, below the kernel's netfilter and routing layer, which is exactly where Android's VPN-lockdown enforcement lives. Lockdown mode filters traffic by app UID at that routing layer. A packet the hardware sends autonomously never reaches that gate, so it exits on the physical interface carrying the device's real IP address, never touching the tunnel.

What Leaks, and What Doesn't

What leaks: your real public IP address, plus the timing and cadence of the keepalive traffic, a pattern an observer on the network could use to fingerprint your device over time. That's it. Android itself controls the format of the keepalive packet, so a malicious app cannot use this channel to smuggle out arbitrary data or your actual VPN traffic. This is an IP and metadata deanonymization bug, not a data-exfiltration channel.

Read the full paper, including the source-line anchors into AOSP, at supuk.ch.

The Two 2026 Android VPN Leaks Are Not the Same Bug

If you read about "the Android VPN leak" somewhere and the details don't match what's in this guide, check which one they mean. Conflating the two is the single easiest way to get the fix status wrong: the QUIC leak is fixed on GrapheneOS with a CVE attached, the NAT-T leak is not.

Device Scope

Šupuk's paper demonstrates the leak on a Pixel 8 Pro running Android 16 (build CP1A.260505.005), where the keepalive fired roughly every 10 seconds against an OpenWrt router he controlled. He also reproduced it on a Samsung SM-F966B, where a keepalive slot stayed active for 24 hours and 32 minutes continuously, and on a Nothing A059, where he confirmed the public API path was accepted, without an independent packet capture on that device.

The paper frames this as device-class exposure "affecting most Android 12+ devices," attributing it to a shared AOSP framework path implemented across seven Wi-Fi chipset vendors, with a stated roughly 9% exclusion the paper doesn't detail the reason for in the portion available, worth treating as a rough boundary, not a precise cutoff.

Google's Response: Reported as "Won't Fix"

Mullvad's blog says the report to Google "was closed without action," and secondary coverage described it as closed "as a duplicate." Šupuk's own account, posted directly on the GrapheneOS issue tracker on August 28, 2026, resolves that ambiguity: "Mine seems to be 'won't fix' too, with no success reasoning with them either." That's his characterization of his own Google VRP report's outcome, and it's the most direct source available on the status.

Sources: GrapheneOS issue #8617 and TechRadar.

GrapheneOS: A Fix In Progress, Not Shipped

The same August 31 comment explains the delay: other VPN leaks that don't require an app to intentionally try to bypass lockdown were prioritized ahead of this one. A September 1 follow-up mentions "at least 10 other leaks that we have discovered and fixed, which will be released soon", those are unrelated bugs, not this one.

Šupuk proposed a concrete, one-line fix in the same thread: GrapheneOS could deactivate the unprivileged keepalive path, the same approach it already used to fix the QUIC leak, by setting a single AOSP config value, config_allowedUnprivilegedKeepalivePerUid to 0. He called it "a one-line fix." Whether or how GrapheneOS implements it remains to be seen, but it's a specific, verifiable technical proposal, not vague hand-waving.

GrapheneOS's track record on the other leak is real: it shipped a code fix for the QUIC bug in build 2026050400, with the changelog entry reading "disable registerQuicConnectionClosePayload optimization to fix VPN leak," and that bug carries CVE-2026-45182. That's the strongest argument for GrapheneOS as a mitigation generally. It is not yet a confirmed cure for this specific bug.

The current status of every party who could ship a fix for this.  via GIPHY

The Documentation Gap Nobody's Talking About

Here's the part that should bother you more than any single bug. Google's own Android Enterprise documentation says, in plain language: "As part of the system framework, VPN routing is automatically managed so the user can't bypass the VPN service. If the VPN service is disconnected while in lockdown mode, traffic can't leak to the open Internet."

That's an absolute-sounding promise. And at least three separate, independently documented findings in the last four years show traffic leaving the tunnel anyway, under lockdown, with that promise still standing unchanged:

1. 2022 — Mullvad documented that Android's own connectivity checks (DNS, HTTP/S, NTP) leave the tunnel even with lockdown enabled. Google's on-record response, when asked, was that this is "working as intended," adding: "we do not think such an option would be understandable by most users, so we don't think there is a strong case for offering this."
2. 2026, April — the QUIC "Tiny UDP Cannon" leak, closed "Won't Fix (Infeasible)."
3. 2026, September — this NAT-T port-4500 leak, reported by the researcher as "won't fix."

None of Google's VPN-facing developer documentation, not the VpnService reference, not the general VPN connectivity guide, not the Android Enterprise page, mentions hardware-offloaded traffic, connectivity checks, or any other carve-out to the lockdown promise. The docs aren't wrong exactly. They're silent. Three times, three different mechanisms, and the same unqualified sentence still sits on the page.

Is There a Leak Test You Can Actually Run?

For the port-4500 leak specifically: no. Neither Mullvad nor Šupuk published a self-contained, unrooted, single-device test. Šupuk's own demonstration required an external router, he ran OpenWrt and captured the UDP/4500 traffic leaving the physical Wi-Fi interface with tcpdump. That's the same pattern Mullvad used to demonstrate the 2022 connectivity-check leak: enable lockdown, watch a router you control, and look for anything leaving the tunnel.

That means a genuine test of your own device needs a second box, a router you control, running packet capture, not an app you can install on the phone itself. If you have that setup, the honest test is: enable your VPN with lockdown on, run tcpdump (or equivalent) on the router watching UDP port 4500, use the phone on that Wi-Fi network for a while, and see if anything shows up carrying your device's address instead of the VPN's.

If you don't have that setup, there isn't a shortcut. A browser-based leak checker, including Mullvad's own (mullvad.net/check), almost certainly won't catch this, it operates below the browser and app layer entirely, so a page loaded inside the browser has no way to observe it, though this hasn't been independently tested and confirmed against this specific bug.

What Actually Reduces Your Risk

Because no VPN app can patch this, and the OS-level fix isn't shipped, your options are limited to reducing exposure rather than closing the hole.

Does This Affect iPhones?

No known equivalent of this specific hardware-offload NAT-T bypass has been reported on iOS. Neither Mullvad's post nor Šupuk's paper claims iOS is affected by this bug.

That doesn't mean iOS is leak-free, it has its own, entirely separate class of VPN leak. Apple's own developer documentation for NEVPNProtocol.includeAllNetworks was quietly changed from describing the setting as sending "all network traffic" over the tunnel to sending "most network traffic," and Apple engineers have acknowledged in developer forum threads that certain Apple-service connections can bypass a VPN tunnel with no clean fix beyond filing a bug.

The Honest Place for a VPN in All This

A VPN doesn't fix this bug, and no VPN app claims to, once you read what the discloser itself says. But that doesn't mean a VPN is pointless on Android, it still does exactly what it always did against the threats it was built for: ISP-level snooping, public Wi-Fi interception, and geo-restriction. If you already use one for those reasons, that reasoning is unaffected by this bug. If you're choosing a VPN specifically for public-network security, our freelancer VPN security guide covers that use case directly. This bug is a reason to be realistic about what a kill switch actually promises, not a reason to stop using a VPN for what it's good at.

Final Thoughts

The uncomfortable honesty here is the point. Mullvad amplified a disclosure that makes its own product look incomplete, because the alternative, staying quiet about a hole it can't patch, is worse. Google's documentation still promises that lockdown mode means traffic can't leak, while three separate, independently confirmed bugs in four years show it can. GrapheneOS has the only credible fix in motion, and it isn't shipped yet.

Nothing here means uninstall your VPN. It means understanding that "kill switch on" is a promise about software, and this bug lives in hardware. Keep your app count trusted and small, watch for GrapheneOS's actual fix landing, and don't let a browser leak-check or a Wi-Fi-calling toggle stand in for a test that genuinely doesn't exist yet.