An Android research paper names the code path and device scope behind the NAT-T keepalive VPN leak

Sources: paper, HN discussion
Summary: The paper, dated 2026-07-29, covers the leak this digest carried on 2026-09-12 from Mullvad's report and resolves the device scope that report left unstated, naming seven WLAN families representing 91.24 percent of estimated Android-derived shipments, confirmed by an external access-point packet capture on a Pixel 8 Pro running Android 16 and by active-slot observation on a Samsung SM-F966B over 24 hours 32 minutes and on a Nothing A059. An app declaring only INTERNET and ACCESS_NETWORK_STATE reaches startNattKeepaliveWithFd through the public IpSecManager and ConnectivityManager calls, which accept the file descriptor and IpSec resource id without proving caller ownership and start Wi-Fi hardware offload without checking the caller UID against the effective VPN policy, so UDP port 4500 packets leave over the physical network while Always-on VPN and Block connections without VPN are both enabled. The paper attributes the root cause to a 2019 revert of IpSec resource validation and lifetime locking over deadlock concerns, replaced by quotas that do not authenticate the pair, and names no fix.
Why it matters: An unprivileged app discloses the device's real non-VPN address and timing to an endpoint of its choice, and the emission happens below the socket layer that lockdown controls.
Follow-up: Whether Android ships a platform fix and whether a CVE is assigned.