Six Months After tun0 Leak: Which Android VPN Clients Fixed Server Address Exposure and Which Ignored It

A detailed investigation reveals that Android VPN clients suffer from two distinct server address leaks when split tunneling is enabled. The first leak, tied to an unprotected local SOCKS proxy on 127.0.0.1, was quickly mitigated by most Xray and sing-box based clients through random ports and passwords. The second, more persistent leak allows excluded applications to bind sockets directly to the tun0 interface and discover the VPN server IP without root or special permissions. Only TeapodStream and OlConnect implemented owner-UID checks using ConnectivityManager.getConnectionOwnerUid, yet both initially mishandled the INVALID_UID response returned for excluded apps. AmneziaVPN has unmerged pull requests that correctly reject unknown owners, while sing-box offers a manual package_name_regex rule. v2rayNG closed the report as not planned, and major clients including WireGuard for Android, Mullvad, Proton VPN and others have issued no statements.

HabrTranslated from Russian

Read at source

Six months after widespread reports of VPN server address leaks on Android, an independent analysis shows that only a handful of clients have addressed the issue, while many others either ignored reports or closed them without fixes.

The investigation identifies two separate leaks that are frequently confused. The first occurs when VPN clients expose a local SOCKS proxy on 127.0.0.1 without authentication. Any application can connect to this port and route traffic through the VPN tunnel, revealing the server address even if the app was explicitly excluded from the tunnel. The second leak is independent of proxies and stems from Android’s handling of SO_BINDTODEVICE on the tun interface.

How the tun0 Leak Works

When split tunneling excludes an application, Android removes the route to tun0 for that app’s UID. However, any process can still call setsockopt to bind a socket directly to tun0. The kernel then forwards packets through the interface anyway. The VPN client receives the packet, encrypts it, and sends it to the remote server, exposing the server IP to the destination. No root access or custom code is required; a simple curl command from Termux placed in the exclusion list reproduces the leak.

Testing showed that excluded applications, including the open-source RKNHardering detector, successfully reached the VPN server and recorded its address multiple times.

Client Responses

Most clients addressed only the local proxy issue in April by adding random ports and passwords. AmneziaVPN, TeapodStream and v2rayNG implemented this change, though v2rayNG leaves the protection disabled by default. Karing, Throne and FlClash followed similar approaches.

For the tun0 leak, only two projects implemented proper owner verification. TeapodStream rewrote its tun2socks layer to check every connection with ConnectivityManager.getConnectionOwnerUid. After notification, the developer released version 1.6.6 that correctly rejects packets returning INVALID_UID when exclusions are active. OlConnect performs a similar check but still accepts INVALID_UID in all modes and was unreachable for comment.

sing-box added a package_name_regex rule that can reject unknown owners, but users must insert it manually. AmneziaVPN received a series of pull requests covering both AmneziaWG and the full client stack; none have been merged yet. v2rayNG closed the tun0 report as “not planned.”

No public statements or fixes were found for WireGuard for Android, Mullvad, Proton VPN, IVPN, Cloudflare WARP, Outline, Tailscale, NordVPN, Windscribe, Lantern, Psiphon or OpenVPN for Android.

Users can verify their own client with one Termux command that attempts to reach ifconfig.me through the tun interface while the app is excluded from the VPN.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Vulnerabilities & Exploits

Telegram for Android Patches Voice Call Vulnerability Enabling Code Execution
Yandex Patches Millions of Stations After eMudhra Certificate Keys Compromised
Cisco ASA and FTD Face DoS Vulnerability in SSL VPN Already Exploited in the Wild