When the VPN Light Turns Green but the IP Still Bleeds

Introduction

For many Android users, “Always-On VPN” plus “Block connections without VPN” is the closest thing to a digital dead bolt. The idea is simple: if the tunnel drops, traffic stops. But the reported Android 16 flaw cuts at the heart of that promise, suggesting that a user’s public IP address may still surface when it should have remained hidden.

Fast Facts

• The issue is tied to Android 16 and a reported VPN-bypass path.
• The claimed impact is exposure of a device’s real public IP address.
• The problem is said to appear even with Always-On VPN and Block connections without VPN enabled.
• The issue was publicly disclosed on April 30, 2026.
• The discoverer identified in the disclosure is the researcher known as 0x33c0unt.

Body

The technical significance is less about one app and more about trust boundaries. Android’s VPN model is designed to keep traffic inside a protected path, but the platform also includes routing and bypass-related behaviors that can change how packets move. That means a leak report like this should not be read as “VPNs are broken” in the abstract. It is a narrower question: did some traffic escape the tunnel, and if so, by what path?

That distinction matters. If the bug allows even a small amount of traffic to reach the underlying network, remote services may see the device’s real IP instead of the VPN exit address. In practical terms, that can weaken location privacy, make session correlation easier, and undermine the user expectation that a privacy control is still working when it says it is working.

At the same time, the exact root cause remains unresolved in the available technical detail. It is not yet clear whether the leak involves a platform defect, an app-level behavior, an OEM-specific variation, or an interaction with a particular VPN configuration. The available information supports a risk analysis, not a definitive claim about the full exploit path.

For defenders, the lesson is blunt: VPN posture should be tested, not assumed. Managed fleets should verify that traffic is blocked after reboot, after disconnects, and under real app activity. Security teams should review whether VPN profiles permit bypass behavior, whether split-tunnel logic is intentional, and whether app networking settings match policy. A tunnel that looks enforced in settings but leaks in practice is exactly the kind of failure that slips past user trust.

At the time of writing, public information has not fully established the technical root cause, the complete scope of affected devices, or whether the behavior depends on special permissions or specific builds.

Conclusion

The broader lesson is that privacy controls are only as strong as the routing rules behind them. When a platform promises a sealed tunnel, even a small exception can become a real-world identity leak. In mobile security, the most dangerous failures are often the ones that leave the interface intact while the packet path quietly changes underneath.

TECHCROOK

Travel router: A small travel router can add a practical layer of control for mobile setups, especially when you want a single trusted network path for multiple devices. Look for models with VPN client support, guest network options, and basic firewall controls. It is a useful tool for people who want more predictable routing and fewer surprises on unfamiliar Wi‑Fi.

Scheda Techcrook: Travel router

WIKICROOK

• Always-On VPN: An Android mode that keeps a VPN active and can block traffic that is not using the tunnel.
• VpnService: The Android API used by apps to implement VPN services.
• allowBypass(): An Android VPN API option that can permit bypass behavior in supported configurations.
• IP leak: The unintended exposure of a device’s real public IP address instead of the VPN exit address.
• Network binding: Directing an app or process to use a specific network interface for its connections.