The researcher linked by Mullvad claims Android's hardware-offloaded NAT keep-alives let an app expose the device's real IP despite VPN lockdown, requiring an operating-system fix rather than reliance on VPN-app containment.

state: watchingheat: lowuncertainty: mediumnovelscott: lowandroid-security privacy networkingMullvadGoogle GrapheneOS

What is this?

This case concerns a reported Android VPN bypass that exposes a device’s real public IP even with VPN lockdown enabled. CyberInsider reports that an unnamed researcher demonstrated it on a Pixel 8 running Android 16 with Proton VPN; Google reportedly declined to fix it, while GrapheneOS released a fix. The supplied snippets do not independently establish the case’s specific hardware-offloaded NAT keep-alive mechanism, Mullvad’s link to the researcher, or whether VPN apps lack any effective mitigation; those details remain claims rather than verified findings here.

Why it matters to Scott

The reported bypass offers only a generic caution about isolation guarantees, not an established challenge to Scott’s SiloOS architecture; the hits show no Android VPN dependency in his projects. No supplied radar page tracks this development, and the hardware-offload mechanism and claimed absence of VPN-app mitigation remain unverified in the grounding.

radar:concept.privacyradar:concept.network-security

queries asked of Scott's wikis

Android GrapheneOS VPN privacy deployments
OS enforcement versus application containment
Network egress isolation fail-closed guarantees
Hardware offload bypass security boundaries
Platform vendor security responsibility privacy guarantees

Measured heat

now 0 pts/hpeak 0 pts/hcomments 0/hpeers p14momentum: steady2 platformsage 715h

points/hour across evidence · reading as of 2026-10-12 02:59:37.977291+11:00 · deterministic, not a model opinion

How the heat travelled

09-12 08:24 (minted)	⭐ origin echo-reconstructed	According to Mullvad, the researcher discovered that hardware-offloaded UDP keep-alives bypass Android's VPN lockdown without special app pe Researcher publishing at supuk.ch on paper (echo) · attributed from hn.story.49665502 · published time unknown	—
09-11 21:16	first on hacker news · published · lag ?	Another way to leak traffic on Android has been discovered mhitza	—
09-11 21:16	amplified on hacker news 👑	hn.story.49665502 mhitza	peak 213 · 53 comments · 100% of case engagement
09-12 08:20	our radar first saw it · lag ?	discovery anchor: hn.story.49665502	—

pace: p78 vs 1032 stories at the 336h mark (now 715h old) — ahead of experiential-open-model-gateway (1.0x), behind intelligence-per-watt-local-coverage (1.0x)

Evidence (2) — ⭐ canonical anchor

source	object	author	score	comments
🟧 hn	Another way to leak traffic on Android has been discovered Retrieved article excerpt Open article · Retrieved 2026-09-12T08:21:45.548607+00:00 # Another way to leak traffic on Android has been discovered September 10, 2026 [Privacy](https://mullvad.net/en/blog/tag/privacy) A newly discovered leak in Android allows any app to send traffic outside the VPN tunnel. Yet another leak was [recently discovered](https://supuk.ch/papers/android-natt-keepalive-vpn-bypass) in the Android network stack that allows a malicious app to send traffic outside the VPN tunnel, even when "Block all connections without VPN" is active. Having traffic leak outside the tunnel means your real IP address becomes visible on the Internet, which could potentially be used for tracking or surveillance purposes. The malicious app does not need any special permission to perform this attack. A proper fix would require changes in the Android system. The researcher who discovered the leak has reported the issue to the Android Vulnerability Reward Program, but according to the researcher the issue was closed without action. This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are [working on a fix](https://github.com/GrapheneOS/os-issue-tracker/issues/8617). ### Technical details The leak involves telling Android to create a keep-alive UDP connection that is offloaded to the hardware Wi-Fi or cellular chip. The intended purpose of this connection is to help with network address translation (NAT) traversal, but a malicious app can misuse this to send UDP packets on port 4500 to any server on the Internet. As 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. ### Mitigation The network hardware only supports having a limited amount of keep-alive connections at the same time, so a theoretical solution could be to use some kind of application that creates its own keep-alive connection until the capacity is reached. After that any malicious app would no longer be able to create its own connection. Mullvad does not currently have any plan to provide this theoretical mitigation ourselves as it would still involve sending packets outside to the tunnel, even though they are to a Mullvad owned server. Furthermore, such a mitigation it is not guaranteed to work, as a malicious app may have already initiated the leak before the Mullvad app is started. ### Conclusion As always, it is most important to only install trusted apps on your device, and (if possible) use a security and privacy focused Android fork like GrapheneOS.	mhitza	213	53
🟧 echo.paper ⭐	According to Mullvad, the researcher discovered that hardware-offloaded UDP keep-alives bypass Android's VPN lockdown without special app pe	Researcher publishing at supuk.ch	—	—

source

object

author

score

comments

🟧 hn

Another way to leak traffic on Android has been discovered

Retrieved article excerpt

Open article · Retrieved 2026-09-12T08:21:45.548607+00:00

# Another way to leak traffic on Android has been discovered

September 10, 2026 [Privacy](https://mullvad.net/en/blog/tag/privacy)

A newly discovered leak in Android allows any app to send traffic outside the VPN tunnel.

Yet another leak was [recently discovered](https://supuk.ch/papers/android-natt-keepalive-vpn-bypass) in the Android network stack that allows a malicious app to send traffic outside the VPN tunnel, even when "Block all connections without VPN" is active.

Having traffic leak outside the tunnel means your real IP address becomes visible on the Internet, which could potentially be used for tracking or surveillance purposes.

The malicious app does not need any special permission to perform this attack.

A proper fix would require changes in the Android system. The researcher who discovered the leak has reported the issue to the Android Vulnerability Reward Program, but according to the researcher the issue was closed without action. This issue is not public, but based on this information we deem it unlikely that Google will do anything about it. GrapheneOS is aware of the issue and are [working on a fix](https://github.com/GrapheneOS/os-issue-tracker/issues/8617).

### Technical details

The leak involves telling Android to create a keep-alive UDP connection that is offloaded to the hardware Wi-Fi or cellular chip. The intended purpose of this connection is to help with network address translation (NAT) traversal, but a malicious app can misuse this to send UDP packets on port 4500 to any server on the Internet. As 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.

### Mitigation

The network hardware only supports having a limited amount of keep-alive connections at the same time, so a theoretical solution could be to use some kind of application that creates its own keep-alive connection until the capacity is reached. After that any malicious app would no longer be able to create its own connection.

Mullvad does not currently have any plan to provide this theoretical mitigation ourselves as it would still involve sending packets outside to the tunnel, even though they are to a Mullvad owned server. Furthermore, such a mitigation it is not guaranteed to work, as a malicious app may have already initiated the leak before the Mullvad app is started.

### Conclusion

As always, it is most important to only install trusted apps on your device, and (if possible) use a security and privacy focused Android fork like GrapheneOS.

mhitza

213

🟧 echo.paper ⭐

According to Mullvad, the researcher discovered that hardware-offloaded UDP keep-alives bypass Android's VPN lockdown without special app pe

Researcher publishing at supuk.ch

—

Interpretation history

2026-09-15T04:25:22Z
The new comment describes VPN-controlled socket binding, but does not demonstrate that those controls govern hardware-offloaded keep-alives or contradict the reported bypass. It adds technical context, not a verified mitigation or independent corroboration.
2026-09-12T09:21:51Z
The discussion adds neither an independently inspected technical paper nor a demonstrated workaround: it repeats the existing researcher link and proposes an untested USB-C adapter approach. The bypass remains credible publisher-reported evidence, but there is no new implementation result or direct connection to Scott’s systems to justify heightened attention.
2026-09-12T08:26:56Z
grounded: novel/low — The reported bypass offers only a generic caution about isolation guarantees, not an established challenge to Scott’s SiloOS architecture; the hits show no Andr
2026-09-12T08:24:41Z
case created — A specific containment bypass and reported GrapheneOS fix effort make this an active security episode with transferable lessons about enforcement paths bypassed by hardware offload.

Decision trace

10-10 20:02review_dormant28 days without material information; scheduled checks stopped
09-15 14:25repriceThe new comment describes VPN-controlled socket binding, but does not demonstrate that those controls govern hardware-offloaded keep-alives or contradict the reported bypass. It adds technical context
09-15 14:25review_screenAdds new technical detail about Android's Network.bindSocket/SO_BINDTODEVICE interface and VPN-controlled access, potentially affecting the claimed bypass mechanism and mitigation analysis.
09-13 09:21review_screenThe changes add only a PIN-related complaint and an opinion about traffic observability; they provide no new evidence, implementation result, patch, contradiction, or access change. Existing comments
09-13 09:20sensor_dirtycomment_update
09-12 19:21repriceThe discussion adds neither an independently inspected technical paper nor a demonstrated workaround: it repeats the existing researcher link and proposes an untested USB-C adapter approach. The bypas
09-12 19:21review_screenAdds a detailed technical paper, reports that Android’s Vulnerability Reward Program closed the issue without action, and identifies a USB-C adapter workaround alongside GrapheneOS mitigation efforts.
09-12 19:20sensor_dirtycomment_update
09-12 18:26groundThe reported bypass offers only a generic caution about isolation guarantees, not an established challenge to Scott’s SiloOS architecture; the hits show no Android VPN dependency in his projects. No s
09-12 18:24createA specific containment bypass and reported GrapheneOS fix effort make this an active security episode with transferable lessons about enforcement paths bypassed by hardware offload.