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.

Affected Systems & Conditions

  • 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.

What Exactly Leaks & What’s Broken

  1. 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

  2. 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

Why This Is Dangerous

  • 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.

Detection & Hunting Playbook

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.

Remediation & Mitigation

Immediate Steps

  • Disable or block IPv6 at OS level until PureVPN fixes this.

  • Manually maintain ip6tables rules; script backups/restoration.

  • After toggling WiFi or resume, check IPv6 route, or force reconnect.

Medium Term

  • 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.

Long Term & Ideal Fixes (for VPN vendors & users)

  • 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.

Recommendations & Roadmap

  • 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

Comments

Post a Comment

Popular posts from this blog

CyberDudeBivash Rapid Advisory — WordPress Plugin: Social-Login Authentication Bypass (Threat Summary & Emergency Playbook)

-
Image
  TL;DR: A class of vulnerabilities in WordPress social-login / OAuth plugins can let attackers bypass normal authentication flows and obtain an administrative session (or create admin users) by manipulating OAuth callback parameters, reusing stale tokens, or exploiting improper validation of the identity assertions returned by providers. If you run a site that accepts social logins (Google, Facebook, Apple, GitHub, etc.), treat this as high priority : audit, patch, or temporarily disable social login until you confirm your plugin is safe. This advisory gives you immediate actions, detection steps, mitigation, and recovery guidance. Why this matters (short) Social-login plugins often accept externally-issued assertions (OAuth ID tokens, authorization codes, user info). If the plugin fails to validate provider signatures, nonce/state values, redirect URIs, or maps identities to local accounts incorrectly , attackers can craft requests that the site accepts as authenticated. ...
Read more

Hackers Injecting Malicious Code into GitHub Actions to Steal PyPI Tokens CyberDudeBivash — Threat Brief & Defensive Playbook

-
Image
  SUMMARY  Attackers are modifying GitHub Actions workflows (via compromised accounts, malicious PRs, or forged commits) to add steps that exfiltrate PyPI (or other package registry) publishing tokens. With those tokens they publish backdoored packages or download private packages — a supply-chain multiplier. Defend by eliminating long-lived secrets, switching to OIDC/ephemeral credentials, hardening workflow controls, monitoring workflow changes and secret usage, and rotating tokens immediately if you suspect compromise. How attackers typically operate  Gain write access to repo or CI/CD config (via compromised developer account, stolen token, privilege abuse, or merge of malicious PR). Modify or add a workflow file that runs in the repo’s runner context (self-hosted or GitHub-hosted). Add steps that read repository secrets (e.g., PYPI_TOKEN ) or create credentials files ( ~/.pypirc ), then send the token to attacker-controlled endpoints or push a malicious p...
Read more

Exchange Hybrid Warning: CVE-2025-53786 can cascade into domain compromise (on-prem ↔ M365) By CyberDudeBivash — Cybersecurity & AI

-
Image
  Executive summary CVE-2025-53786 is a post-authentication elevation of privilege in Microsoft Exchange hybrid deployments . If an attacker first gains admin on an on-prem Exchange server , they can abuse the legacy “shared service principal” trust used by Hybrid Configuration to escalate into Exchange Online —potentially leading to full cloud+on-prem domain compromise . CISA issued Emergency Directive ED-25-02 with a deadline of 9:00 a.m. EDT on August 11, 2025 for U.S. federal agencies; Microsoft urges all hybrid customers to take the same steps: apply the April 2025 Hotfix Updates , migrate to the dedicated Exchange Hybrid app , and reset/clean up service principal credentials . cisa.gov +1 TECHCOMMUNITY.MICROSOFT.COM +1 Why this is dangerous: actions initiated from the on-prem Exchange side may not show up as obviously malicious in M365 audit trails, making cloud abuse harder to spot if you’ve not modernized the trust. TechRadar What is actually vulnerable? (trust...
Read more