PureVPN IPv6 Leak

2 hours ago 2

In late August 2025, I submitted two security reports to PureVPN under their VDP. Three weeks later, I’ve received no response, so I decided to publish the findings to inform other users.

The issues affect both their GUI (v2.10.0) and CLI (v2.0.1) clients on Linux (tested on Ubuntu 24.04.3 LTS, kernel 6.8.0, iptables-nft backend). Here’s what I found.

1. IPv6 Leaks Off-Tunnel

After toggling Wi-Fi or resuming from suspend, the PureVPN client fails to restore IPv6 protections:

CLI (IKS enabled): The client auto-reconnects and reports status as “connected”, yet the system regains a default IPv6 route via Router Advertisements (fe80::1). Since ip6tables OUTPUT remains ACCEPT (default), egress resumes off-tunnel.
GUI (IKS enabled): When the GUI detects a disconnection, it blocks IPv4 and displays the “VPN session disconnected” dialog. However, IPv6 remains functional until the user explicitly clicks Reconnect.

Real-world effect: I was able to browse IPv6-preferred sites and send/receive email (Thunderbird) with my ISP’s IPv6 address while the client UI claimed I was protected.

2. Host Firewall Reset and Not Restored

At connect time, PureVPN wipes the user’s iptables configuration:

INPUT is set to ACCEPT
All -A rules are flushed (UFW, Docker jumps, user rules, etc.)
After disconnect, these changes are not reverted

Result: the system remains more exposed after using the VPN than before. This defeats the point of using UFW or a local deny policy and contradicts user expectations.

Example:

# Baseline protections $ sudo iptables -P INPUT DROP $ sudo iptables -I INPUT -p icmp -j DROP # Connect to VPN $ purevpn-cli -c US $ sudo iptables -S | head -3 -P INPUT ACCEPT -P FORWARD DROP -P OUTPUT ACCEPT $ sudo iptables -S | grep icmp # (no output — rule was wiped) # Disconnect $ purevpn-cli -d $ sudo iptables -S | head -3 -P INPUT ACCEPT -P FORWARD DROP -P OUTPUT ACCEPT # All wiped. INPUT = ACCEPT