# VPN tunnel exclusion leaks plaintext traffic

Local-subnet or server-IP exclusions from the tunnel that lack RFC1918 or socket-scope checks

_Area: Network devices and IoT. Seen in 2 disclosed reports; latest 2024-11-08. Updated 2026-10-23._

## How it works
A VPN client must send most traffic through the tunnel, but it deliberately excludes some destinations: the local LAN (so printers and routers stay reachable) and the VPN server's own IP (so the encrypted tunnel packets don't loop back into the tunnel). The broken assumption is that "excluded" equals "safe." If the exclusion is keyed on whatever subnet DHCP handed out, or on the server IP as a whole, then any traffic to those destinations leaves in plaintext. An attacker who controls the network (rogue DHCP, rogue hotspot) can steer the exclusion to cover public address space, and the client happily routes real traffic outside the tunnel [E1](https://bugbountylibrary.com/r/h1%3A1987680.md)[E3](https://bugbountylibrary.com/r/h1%3A1987687.md).

## Where it shows up
- Client code that builds route exclusions from the DHCP-assigned subnet or gateway without checking it is RFC1918 [E1](https://bugbountylibrary.com/r/h1%3A1987680.md)
- Route rules that exclude the VPN server IP for all traffic rather than only the client's own tunnel socket/UID [E3](https://bugbountylibrary.com/r/h1%3A1987687.md)
- OS-level URI handlers (sftp, smb, ssh) that external apps service directly, bypassing the proxy [E2](https://bugbountylibrary.com/r/h1%3A253429.md)
- Config or logs showing a /1 or public-range split treated as "local"

## How to review
Find every place traffic is excluded from the tunnel and ask what constrains it. The invariant: an exclusion must be justified by the destination's actual trust level, not by who supplied the address. Local-subnet exclusions must be validated against RFC1918 (and link-local) ranges before use [E1](https://bugbountylibrary.com/r/h1%3A1987680.md). Server-IP exclusions must be scoped to the client's own encrypted socket or process UID, never to arbitrary user connections to that IP [E3](https://bugbountylibrary.com/r/h1%3A1987687.md). For proxied apps, confirm no delegated handler opens a direct connection [E2](https://bugbountylibrary.com/r/h1%3A253429.md). Test with a hostile DHCP server offering public ranges and with user-initiated connections to the server IP.

## Variants seen
- DHCP-supplied non-RFC1918 subnet treated as local and excluded [E1](https://bugbountylibrary.com/r/h1%3A1987680.md)
- VPN server IP excluded for all traffic, leaking plaintext to that IP [E3](https://bugbountylibrary.com/r/h1%3A1987687.md)
- URI scheme delegated to an OS client that connects outside the proxy [E2](https://bugbountylibrary.com/r/h1%3A253429.md)

## Impact and severity
Plaintext leakage of nearly all IP traffic on hostile networks, enabling deanonymization and interception [E1](https://bugbountylibrary.com/r/h1%3A1987680.md)[E3](https://bugbountylibrary.com/r/h1%3A1987687.md); real-IP disclosure to an attacker host [E2](https://bugbountylibrary.com/r/h1%3A253429.md). Severity rises when the leak is silent and covers broad traffic, and when the attacker controls DHCP or the hotspot.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A1987680.md
- E2: https://bugbountylibrary.com/r/h1%3A253429.md
- E3: https://bugbountylibrary.com/r/h1%3A1987687.md