DEV Community

Gerus Lab
Gerus Lab

Posted on

Your VPN App Is a Snitch: How Local SOCKS5 Proxies Are Betraying Millions of Users

#programming #security #webdev #tutorial

Your VPN Isn't As Private As You Think

Here's an uncomfortable truth that most developers ignore: the VPN client on your phone is likely exposing your real proxy IP to any app that cares to look.

At Gerus-lab, we've spent years building secure infrastructure for clients across Web3, fintech, and SaaS. We've audited protocols, deployed zero-trust architectures, and helped teams harden their stacks against sophisticated threat actors. But this week, a discovery in the VLESS ecosystem reminded us that sometimes the most dangerous vulnerabilities aren't in your servers — they're sitting right in your pocket.

A security researcher recently disclosed a critical vulnerability affecting every major VLESS client — v2rayNG, Hiddify, Neko Box, Sing-box, Clash-based clients, and others. The flaw is embarrassingly simple, devastatingly effective, and currently unpatched in every single client.

Let's break down what's happening, why it matters for every developer and company running distributed teams, and what you can actually do about it.

The Vulnerability: Your Local Proxy Is Wide Open

Every mobile VLESS client follows the same architecture:

VpnService → tun2socks → xray socks5 → VPN server → internet
Enter fullscreen mode Exit fullscreen mode

The problem? The local SOCKS5 proxy runs on localhost without authentication.

This means any application on the same device can:

  1. Scan localhost ports (common proxy ports: 1080, 9000, 5555, 16000-16100)
  2. Connect directly to the SOCKS5 proxy — completely bypassing VpnService
  3. Route traffic through your VPN tunnel to discover the exit IP address
  4. Report that IP to a central authority or blocking service

What makes this particularly dangerous is that Android's private spaces don't protect you. Knox, Shelter, Island — none of these isolate the loopback interface. A spyware app running in an isolated profile can still scan localhost and find your proxy.

We verified this in our security lab at Gerus-lab — the attack works across all tested Android environments, including work profiles and containerized spaces.

Why Should Developers Care?

If you're thinking "I don't use VLESS, this doesn't affect me" — think again.

This vulnerability class isn't unique to VLESS. Any application that exposes an unauthenticated local service is vulnerable to cross-app exploitation. This pattern appears in:

  • Development tools (local dev servers on 0.0.0.0)
  • Database clients (unauthenticated Redis, MongoDB on localhost)
  • API gateways (local proxy configurations)
  • Desktop Electron apps (IPC over HTTP)

At Gerus-lab, we've encountered this anti-pattern repeatedly during security audits for our clients. The assumption that "localhost is safe" is one of the most persistent and dangerous myths in software development.

The Broader Lesson: Localhost ≠ Secure

The localhost trust boundary died years ago. In the modern mobile OS landscape:

  • Apps share the loopback interface
  • Containerization doesn't isolate network namespaces on consumer devices
  • Any app with internet permission can scan local ports
  • WebRTC and browser-based attacks can probe localhost from web pages

If your application exposes an unauthenticated service on localhost, it is accessible to every other app on the device. Period.

The Happ Disaster: When It Gets Worse

One client — Happ — took this vulnerability to an entirely new level. Their app enables the xray API without authentication, including the HandlerService. This allows any local application to:

  • Dump complete VPN configurations, including encryption keys
  • Extract the server IP address and SNI
  • Potentially decrypt all traffic when combined with a common xray misconfiguration

The researcher reported this to Happ developers, who initially refused to acknowledge it as a vulnerability, calling their product "almost Big Tech" and dismissing the findings. After public pressure from their own community, they eventually agreed to patch it — but the damage to existing installations is permanent, especially for iOS users whose apps were already removed from the App Store.

This is a textbook example of what happens when security reports are dismissed by developers with more ego than expertise.

What You Can Actually Do Right Now

While we wait for client developers to ship patches (and we're not holding our breath), here's a practical defense strategy.

For End Users

1. Separate your entry and exit IPs

If an attacker discovers your exit IP, your entry IP (what you actually connect to) should be different. This way, even if the exit is blocked, your connection survives.

# Architecture:
Your device → Entry IP (hidden) → VPN Server → Exit IP (exposed)
Enter fullscreen mode Exit fullscreen mode

If you can't get a second IP, route all exit traffic through Cloudflare WARP as a secondary layer.

2. Implement split routing

Configure your client with geographic routing rules:

{
  "routing": {
    "rules": [
      {
        "geoip": ["ru"],
        "outboundTag": "direct"
      },
      {
        "outboundTag": "proxy"
      }
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

Local traffic goes direct; everything else goes through the tunnel.

3. Block reverse connections on your server

On the VPN server side, block outbound traffic to domestic IP ranges. This prevents apps that phone home from correlating your proxy usage through traffic pattern analysis.

For Developers Building Local Services

4. Always authenticate localhost services

Even on loopback. Use token-based auth, Unix sockets with proper permissions, or at minimum, a random port with a shared secret.

# Bad: Open SOCKS5 on predictable port
server.bind(('127.0.0.1, 1080))

# Better: Random port + auth token
import secrets
auth_token = secrets.token_hex(32)
server.bind(('127.0.0.1, 0))  # Random port
# Share port + token via secure IPC only
Enter fullscreen mode Exit fullscreen mode

5. Use Unix domain sockets where possible

On Linux/macOS, Unix sockets with filesystem permissions provide actual process-level isolation that TCP localhost cannot.

# Socket file with restricted permissions
srwx------ 1 vpnuser vpnuser 0 Apr 12 proxy.sock
Enter fullscreen mode Exit fullscreen mode

6. Disable UDP on SOCKS5

SOCKS5 UDP relay effectively bypasses authentication. If you must run SOCKS5, disable UDP support entirely.

The Systemic Problem: Security Theater in Open-Source VPN Tools

What frustrates us most at Gerus-lab is that this vulnerability was reported to every major client developer in March 2026 — and a month later, not a single one has shipped a fix.

This isn't a complex cryptographic flaw. It's not a zero-day in a kernel module. It's an unauthenticated SOCKS5 proxy on a predictable port. The fix is trivial:

  1. Add SOCKS5 authentication
  2. Disable UDP relay
  3. Use a random high port
  4. Communicate the port/credentials via a secure channel to tun2socks

Four changes. A day of work. And yet millions of users remain exposed.

The open-source security ecosystem has a sustainability problem. Projects that handle critical security functions are maintained by small teams who may not have the capacity — or in some cases, the motivation — to respond to vulnerability reports promptly.

This is why at Gerus-lab, we advocate for comprehensive security audits at every layer. Our team has performed infrastructure hardening for over 14 clients across Web3, SaaS, and GameFi — and the lesson is always the same: the weakest link is never where you expect it.

Building Secure-by-Default Applications

If you're building any application that creates local network services — whether it's a VPN client, a development tool, or a SaaS product — here's our recommended checklist:

Layer Action Priority
Authentication Add auth to every local service Critical
Port selection Use random ephemeral ports High
Transport Prefer Unix sockets over TCP High
UDP Disable if not strictly needed High
Monitoring Log all local connections Medium
Documentation Warn users about local service exposure Medium

At Gerus-lab, we bake these principles into every project we deliver — from AI-powered platforms to blockchain infrastructure. Security isn't a feature you bolt on; it's a foundation you build on.

What This Means for the Future

This VLESS vulnerability is a canary in the coal mine. As governments worldwide increase pressure on VPN usage and mandate surveillance capabilities in commercial software, the security of circumvention tools becomes a matter of fundamental rights.

The arms race between censorship and privacy will only intensify. And in that race, the tools we rely on must be held to the highest security standards — not the lowest common denominator.

For developers: audit your local services. For users: diversify your infrastructure. For the community: hold maintainers accountable.

And if you need help building infrastructure that actually holds up under adversarial conditions — that's what we do at Gerus-lab. 14+ production cases, battle-tested security practices, and a team that takes vulnerabilities seriously.

Need a security audit or building a privacy-focused product? Reach out at gerus-lab.com — we help teams build infrastructure that doesn't betray its users.

This article is based on research originally published on Habr by an independent security researcher. We've expanded on the technical analysis and practical recommendations from our own experience at Gerus-lab.

Top comments (0)