PureVPN Vulnerability Exposes Users’ IPv6 Address While Toggling Wi-Fi CyberDudeBivash Threat Intelligence Report

Executive Summary

A vulnerability in PureVPN (Linux client, GUI v2.10.0 & CLI v2.0.1) leaks users’ IPv6 address when Wi-Fi reconnections occur or after system suspend/resume. Cyber Security News+1
IPv6 kill-switch protections fail to reapply properly; firewall rules are reset/erased and not restored after disconnect, leaving the system more exposed. Cyber Security News+2Anagogistis+2
Affects users on Ubuntu 24.04.3 LTS with kernel 6.8.0 and iptables-nft backend. Cyber Security News+1
Real risk for anyone using PureVPN for privacy: websites, emails, etc. may leak IPv6 traffic in periods when user expects full protection.

PureVPN Linux GUI v2.10.0 and CLI v2.0.1 clients. Cyber Security News+2BigGo+2
OS: Ubuntu Linux 24.04.3 LTS, kernel 6.8.0. The iptables/nft backend environment. Cyber Security News+1
Situations: toggling WiFi (disconnect/reconnect), system resume from suspend, or possibly after network state change.

IPv6 Leak Off-Tunnel
- When WiFi toggled or resume, PureVPN fails to reinstate ip6tables rules in time. The system receives Router Advertisements (e.g. fe80::1) causing IPv6 route to reappear through the normal (ISP) interface. Cyber Security News+1
- In CLI with IKS (IPv6 kill switch) enabled, VPN claims “connected” but IPv6 traffic is flowing off-tunnel. Anagogistis+1
- In GUI mode, when the VPN disconnects, IPv4 is blocked but IPv6 remains until manual reconnection. Cyber Security News+1
Firewall / iptables Reset / Wipe
- On connection, PureVPN wipes existing iptables configuration: user rules, UFW chains, Docker rules, etc. Sets defaults to ACCEPT. Cyber Security News+1
- On disconnect, firewall state is not restored; custom rules remain gone. System remains with permissive defaults. Anagogistis+1

Privacy exposure: Users believe they’re protected but IPv6 IP leaks mean “real IP” visibility to sites / email servers / any service using IPv6.
Security exposure: Firewall wiping means local protections (block SSH, block incoming services etc) are gone; attackers could exploit open ports/services that were blocked earlier.
False trust indicator: UI shows “connected” but critical protections not active → misleading.

Here are things to monitor if you’re detecting this or similar VPN client leaks.

Linux audit / syslog: monitor ip6tables rules; check policy on IPv6 OUTPUT / FORWARD / INPUT — does it flip to ACCEPT unexpectedly?
Network monitoring: traffic with IPv6 source addresses from VPN hosts when they should be off VN tunnel.
Client logs: events on network resume or WiFi reconnect; check if kill-switch or firewall rule reapplication fails.
Firewall state snapshots: before VPN, after connect, after disconnect / resume etc. Log differences.
Forge alerts for unexpected inbound connections after disconnect or during supposedly protected states.

Use VPN clients known for correct IPv6 kill-switch behavior.
Use external firewall tools (ufw, nftables) to enforce deny-by-default IPv6 OUTPUT / INPUT.
Monitor for changes in network interface state and automate tests.

PureVPN to patch: ensure IPv6 kill-switch rules are reinstalled atomically during any network state change.
Never wipe user firewall rules without backing them up and restoring them properly.
GUI clients should show warning if IPv6 is detected off the tunnel.
Use OS support for “network connection hooks” (WiFi events, suspend resume) to enforce protection.

For privacy-conscious users: until fixed, consider using VPN providers with audited leak protection.
For enterprise: enforce device configuration policies where firewall rules for IPv6 are locked, test VPN connections thoroughly under varying network conditions.
Add IPv6 leak testing to your checklist: e.g. ipleak.net, custom test scripts.
Publish guides or advisories to help users mitigate until vendor fixes.

#CyberDudeBivash #PureVPN #IPv6Leak #VPNVulnerability #LinuxPrivacy #KillSwitchFail #NetworkSecurity #ThreatIntel