Malicious free VPN extensions show how browser trust gets abused

At a glance

What this is: This analysis shows that malicious free VPN extensions can use browser permissions, remote configuration, and traffic redirection to turn a privacy promise into ongoing surveillance and data theft.

Why it matters: It matters because browser extension trust has become an identity and access governance issue for human sessions, with direct impact on traffic control, credential exposure, and endpoint policy enforcement.

Context

Browser extensions that ask for broad traffic and navigation permissions can operate like privileged middleware inside a user session. In this case, the security problem is not the VPN label itself but the access the extension receives once installed, especially when that access includes proxy control, webRequest interception, and dynamic rule updates.

For IAM and endpoint teams, the governance gap is that extension approval often treats installation as a user preference rather than an access decision. Once an extension can observe and redirect browser traffic, it effectively sits in the identity path for the session and needs the same scrutiny as any other privileged access surface.

LayerX Security describes a recurring campaign in which a takedown is followed by near-identical clones. That pattern is typical of browser abuse campaigns that rely on marketplace trust, remote update channels, and weak post-install monitoring rather than one-off malicious binaries.

Key questions

Q: What breaks when a browser extension can control proxy routing and navigation?

A: The browser session stops being a simple user-controlled environment and becomes a delegated control plane. An extension with proxy and navigation privileges can redirect traffic, observe browsing, and override competing tools, which means the real failure is over-broad session trust. Security teams should treat that as privileged access, not a benign feature.

Q: Why do free VPN extensions create more risk than they remove?

A: They often trade privacy branding for broad browser permissions and opaque runtime control. When the extension can fetch remote configuration, modify routing, and monitor requests, the user does not gain privacy so much as delegate traffic handling to an unknown operator. The risk is highest when no lifecycle monitoring exists after installation.

Q: How do security teams know if browser extension controls are actually working?

A: They should be able to answer three questions: which extensions are installed, which ones are allowed, and which ones show suspicious runtime behaviour. If the inventory is incomplete or extensions can act without detection after install, the control is not working. Continuous monitoring matters because store takedown does not remove already installed code.

Q: Should organisations remove browser extensions before revoking sessions?

A: If the extension may have handled authentication traffic, remove the extension first to stop further interception, then revoke affected sessions and rotate credentials. That sequence limits repeated exposure while containment is still in progress and prevents a reinstalled or persistent extension from capturing fresh tokens.

Technical breakdown

How malicious browser extensions turn permissions into traffic control

Browser extensions can request permissions that reach far beyond cosmetic changes. When an extension has access to proxy settings, navigation events, and network request handling, it can observe where a user goes, change routing decisions, and alter the content returned to the browser. In this campaign, the key technical issue is not code complexity but permission breadth combined with remote configuration. That lets the operator change behaviour after installation without republishing the extension. From an identity perspective, the extension acts like a delegated session controller inside the browser, with no meaningful separation between user intent and operator command once the permissions are granted.

Practical implication: Treat extension permissions as delegated access and approve only the minimum browser controls required for the use case.

Why remote PAC scripts and dynamic rules create persistent control

A Proxy Auto-Config file tells the browser how to route traffic, and if that PAC script is fetched remotely the operator can change routing logic at any time. DeclarativeNetRequest updates add another control layer by letting the extension alter filtering and redirection rules on the fly. The result is a moving target: the store review sees one version, while the runtime behaviour can shift later through hidden configuration fetches. In the article’s older and newer variants, those mechanisms are paired with keepalive behaviour and delayed activation, which increase persistence and reduce the chance of simple static analysis catching the abuse.

Practical implication: Monitor for runtime proxy changes and dynamic rule updates, not just the presence of an extension in the store.

How navigation interception and extension disablement expand the blast radius

When an extension listens to all main-frame requests, it can redirect whole page loads rather than just adjusting isolated network calls. That makes phishing pages, fake downloads, ad-farm routing, and silent content replacement possible at the browser layer. The newer version described by LayerX Security also scans for other proxy-capable extensions and disables them, which shows that the attacker is not only steering traffic but also trying to remove competing controls. That combination turns browser trust into a monopoly over routing and visibility inside the session.

Practical implication: Correlate browser extension installs with proxy-policy changes and competing extension disablement to spot control takeover.

Threat narrative

Attacker objective: The objective is to maintain covert control over browser routing and harvest sensitive browsing data, credentials, and session activity at scale.

1. Entry occurs when a user installs a seemingly legitimate free VPN extension from the browser store and grants broad browsing and proxy permissions.
2. Credential and session abuse follows when the extension can observe navigation, redirect traffic, and profile visited URLs through remote configuration and proxy control.
3. Escalation occurs when the extension dynamically updates rules, disables other proxy tools, and keeps its background worker alive to preserve control after installation.
4. Impact is the redirection, surveillance, and potential credential theft of browser traffic through attacker-controlled infrastructure.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser extension trust is now a delegated access problem: once an extension can manage proxy settings, intercept requests, and alter navigation, it is no longer a convenience layer. It becomes part of the session control path, which means user choice alone cannot govern it. The practitioner conclusion is straightforward: browser extensions must be governed as privileged access surfaces, not soft add-ons.

Remote configuration creates runtime authority that store review cannot see: the harmful behaviour is not frozen at publish time. Hidden config fetches, dynamic PAC logic, and rule updates let the operator change the extension’s identity and function after approval, which breaks the assumption that marketplace vetting equals runtime trust. The practitioner conclusion is that post-install behaviour monitoring matters as much as pre-install approval.

Identity and access teams should treat browser routing as a control plane: once an extension can route, redirect, and suppress competing proxy tools, it can dictate what the user reaches and what telemetry survives. That collapses the boundary between endpoint policy and browser behaviour. The practitioner conclusion is that browser governance belongs in IAM-adjacent policy, not only in endpoint hygiene.

Browser trust debt accumulates when organisations allow free utility extensions without lifecycle control: the campaign’s repeated reappearance shows that takedown does not end exposure if clones can re-enter under new branding. Free utility extensions often carry the same operational risk as unmanaged third-party access. The practitioner conclusion is that extension approval, inventory, and removal need continuous lifecycle governance.

Browser extension surveillance should be read as a human identity control failure, not just malware detection: the attack uses the user’s authenticated browser session as its operating environment. That means the security gap sits at the intersection of human access, endpoint trust, and in-browser policy enforcement. The practitioner conclusion is that session governance and extension governance now overlap.

What this signals

Browser extension trust now needs lifecycle governance: if an extension can alter proxy settings and navigation after install, the control is no longer just whether it was approved. The programme question becomes who owns the extension throughout its life, how changes are detected, and when it is removed.

Runtime behaviour matters more than store reputation: a clean listing does not prevent remote configuration, delayed activation, or dynamic rule changes. For browser security, post-install telemetry is the only way to see whether an extension is still behaving as reviewed.

Browser routing is part of identity governance now: when an add-on can sit inside the authenticated session and redirect traffic, it affects both human access and endpoint policy. Teams should align browser controls with session risk, not with convenience alone.

For practitioners

• Block high-risk browser extension permissions Review which extensions can access proxy settings, webRequest interception, declarative rules, and all URLs. Deny broad permissions unless there is a documented business need and a named owner for the extension.
• Inventory and approve browser extensions continuously Maintain an allowlist for approved extensions, with versioned records, business justification, and removal dates. Reconcile installed extensions against the allowlist on a recurring basis, not only at onboarding.
• Detect runtime proxy and navigation changes Watch for PAC configuration changes, unexpected proxy routing, and navigation redirection from extension processes. Pair browser telemetry with endpoint and DNS logs so redirected traffic cannot hide in normal user activity.
• Revoke affected sessions after suspicious extension activity If a browser extension has proxied sensitive traffic, assume session tokens and credentials may be exposed. Force session revocation, credential reset, and profile cleanup for impacted users.
• Disable competing proxy extensions during investigation Check whether a suspicious extension is disabling other proxy or privacy tools. Where that pattern appears, treat it as control takeover and remove the extension before restoring user browsing trust.

Key takeaways

• Malicious browser extensions can turn a privacy feature into a covert control path for traffic redirection and data collection.
• The campaign’s persistence shows that takedown alone does not solve the problem when clone extensions can return with similar code and branding.
• Organisations need extension inventory, runtime monitoring, and session revocation procedures that treat browser add-ons as privileged access surfaces.

Key terms

• Browser Extension Runtime Trust: The level of confidence an organisation places in a browser extension after it has been installed and is operating inside a user session. For security teams, this trust must be based on observed behaviour over time, not just marketplace approval or permissions at the point of install.
• Proxy Auto-Config (PAC): A PAC file is a browser configuration script that tells traffic where to go. When a PAC is fetched remotely, the operator can change routing behaviour after installation, which makes it a high-risk control point for browser trust and traffic governance.
• Declarative Net Request: Declarative Net Request is a browser API for defining request-handling rules. It can be used legitimately for filtering, but when an extension updates those rules dynamically it can change routing and blocking behaviour at runtime, outside the initial review window.
• Session revocation: The ability to invalidate active sessions so access ends immediately instead of waiting for tokens or browser state to expire. For identity governance, this is the control that determines whether authentication still matters after a compromise is detected.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.