PureVPN IPv6 leak

I discovered two issues while using PureVPN’s Linux clients (GUI v2.10.0, CLI v2.0.1) on Ubuntu 24.04.3 LTS (kernel 6.8.0, iptables-nft)¹. One affects IPv6 traffic, the other the system firewall.

1. IPv6 leak after reconnect

After a network transition (e.g. Wi-Fi or Ethernet disconnect/reconnect, or system resume):

• CLI (IKS enabled): The client auto-reconnects and shows status as “connected”, but the system acquires a new default IPv6 route via Router Advertisements (fe80::1), which is not removed or blocked by the VPN client. Since the default ip6tables OUTPUT policy is ACCEPT, IPv6 traffic flows outside the tunnel.
  

• GUI (IKS enabled): The GUI displays a dialog saying “VPN session disconnected — The traffic will not be secure until we successfully connect you”. It shows two buttons: “Reconnect” and “Resume Internet”. In this state, IPv4 is blocked by the kill-switch, but IPv6 is still active and leaking. Clicking “Reconnect” re-establishes the tunnel and blocks IPv6 again.

During these conditions, I was able to access IPv6-preferred websites and use email (via Thunderbird) with my ISP-assigned IPv6 address.

The following steps reproduce the IPv6 leak in both the CLI and GUI clients, after reconnecting Wi-Fi or Ethernet:

# 1. Connect to VPN
$ purevpn-cli -c <country>
# or use the GUI

$ curl -4 -s --max-time 5 https://ifconfig.co
# VPN IPv4 (OK)

$ curl -6 -s --max-time 5 https://ifconfig.co
# no IPv6 connectivity

$ ip -6 route | grep '^default'
# no IPv6 default route

$ sudo ip6tables -S | head -3
# ACCEPT by default

# 2. Trigger a network transition (disconnect + reconnect)

# If on Wi-Fi:
$ nmcli radio wifi off; sleep 2; nmcli radio wifi on; sleep 5

# If on Ethernet:
$ nmcli device disconnect eth0; sleep 2; nmcli device connect eth0; sleep 5

3. After Wi-Fi or Ethernet comes back up
# CLI: automatically reconnects and shows "connected"
# GUI: shows "VPN session disconnected" — do not click Reconnect yet

$ curl -4 -s --max-time 5 https://ifconfig.co
# IPv4 blocked (GUI) or working (CLI)

$ curl -6 -s --max-time 5 https://ifconfig.co
# ISP IPv6 (LEAK)

$ ip -6 route | grep '^default'
# default via fe80::1 dev wlo1

$ sudo ip6tables -S | grep '^-P '
# ACCEPT (unchanged)

2. Firewall state modified and not restored

I also observed that when connecting with either client, the VPN modified the system’s iptables rules:

• The default policy for INPUT was set to ACCEPT
• All appended (-A) rules were flushed, including those set by tools like UFW, Docker, or manually
• These changes were not automatically reverted after disconnecting

This left the system in a different firewall state compared to its initial configuration, and may affect users relying on persistent firewall rules for local security.

Example:

# Set custom firewall rules
$ 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
# INPUT policy changed to ACCEPT

$ sudo iptables -S | grep icmp
# No output — the ICMP rule was wiped

# Disconnect
$ purevpn-cli -d

$ sudo iptables -S | head -3
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
# INPUT policy remains ACCEPT, not restored to DROP

$ sudo iptables -S | grep icmp
# No output — the ICMP rule was not restored

What users can do

The IPv6 leak occurs only in specific conditions, such as after a network transition (Wi-Fi/Ethernet reconnect or suspend/resume). As far as I can tell, there is no leak during normal sessions without network disruption.

In these situations, users should take the following actions:

• On CLI: manually disconnect and reconnect; do not rely on auto-reconnect.

  purevpn-cli -d
  purevpn-cli -c <country>
  

• On GUI: click the Reconnect button immediately to reconnect to VPN.

Also, consider disabling IPv6 on your system to fully prevent IPv6 leaks. See my blog post: How to properly disable IPv6 on Linux

As for the firewall reset issue, once the rules are modified, they must be restored manually. Tools like iptables-save and iptables-restore can back up and reapply rule sets, but may overwrite dynamic changes. UFW or iptables-persistent will restore rules on reboot, but not after VPN disconnect.

I reported both issues to PureVPN in late August 2025 so they can fix them. This post is to inform users about the risks and how to avoid them until a fix is available.

Update 1: These issues are now tracked under the following CVEs:

• CVE-2025-59691
• CVE-2025-59692

Update 2: PureVPN publicly confirmed both issues and published a security advisory. A patched Linux client (GUI & CLI) is expected by mid‑October. I’ll verify the fix and update this post when the patch is shipped.

https://www.purevpn.com/blog/security-advisory-linux-client-ipv6-leak-firewall-rule-reset/

Update 3 (Nov 2025): PureVPN provided a new Linux GUI client build (v2.11.0) on October 19 for validation. I tested it today and confirmed that the IPv6 leak issue appears resolved: both IPv4 and IPv6 connectivity remain blocked when the Kill Switch is active, including after Wi-Fi disconnection or system resume. The Internet connection is not restored until the user explicitly clicks Reconnect or Restore Internet.