737 fake VPN extensions: how to check yours isn't a traffic relay

A VPN extension has one job: make your traffic go somewhere you trust instead of somewhere you don't. So when 737 of them turn out to be pointing at the same operator's servers, the product didn't fail — it worked exactly as designed, just not for you.

That's the finding Socket's threat research team published on August 13: a cluster of Chrome Web Store listings impersonating well-known VPN brands while quietly configuring Chrome to route browser traffic through SOCKS5 proxies run by a single party. If you or someone you help with tech installed a free VPN extension this year, this one is worth ten minutes of your attention.

What Socket found: 737 fake VPN extensions

The numbers are unusually specific because the extensions themselves were unusually sloppy. Socket tied 737 listings across at least 40 separate publisher accounts into one campaign, largely because those accounts shared a single analytics account — the kind of housekeeping mistake that turns a pile of unrelated-looking lookalikes into one identifiable operation.

According to Socket, 274 of the extensions impersonated 66 established VPN and privacy brands — Proton VPN, NordVPN, Surfshark, ExpressVPN, CyberGhost, TunnelBear and Cloudflare's 1.1.1.1 among them. 520 configured Chrome's proxy settings to send nearly all browser traffic through the operator's SOCKS5 proxies on port 1082, excluding only local loopback addresses. Another 104 resolved the proxy hostnames over DNS-over-HTTPS through Cloudflare or Google, which keeps the operator's own domain out of ordinary DNS visibility.

Then there's a third group that didn't intercept anything at all — it advertised premium servers in Japan, Singapore, Canada, Australia and Turkey that Socket says did not exist. That part isn't surveillance, it's subscription fraud with a VPN-shaped storefront.

Socket counted roughly 75,000 installs while the listings were live, concentrated among Russian-speaking users looking for a way to reach services blocked where they live — which is a genuinely awful detail, because that's a group with an above-average need for a proxy they can trust. Socket links the network to a Russian VPN subscription business operating under the name Myxa VPN. I found no public response from that business to Socket's findings.

By the time Socket published, Google had already pulled over 200 of the listings — Socket itself could not collect code for 212 of them, because they were gone. As BleepingComputer reported, more than 500 were still live in the store when the research went out. So "it's been cleaned up" is not the state of things as of mid-August.

What sits at the other end of that pipe

Here's the part I want to be precise about, because "they can see your traffic" gets thrown around loosely.

When every request leaves your browser through one server, that server sees where you're going even when it can't read what you're saying. Socket put it plainly: with all browser traffic forced through the relay, "the threat actor's server is positioned to read every destination, every TLS SNI value, the victim's source IP, and any request body sent over plain HTTP."

Unpacked: HTTPS still protects the contents of your banking session. But the destination hostname is visible to whoever runs the proxy, on every single request. That's your full browsing history, live, with your real IP attached. Anything still served over plain HTTP — some login forms on older sites, plenty of API calls, a lot of the small web — is readable in full, body included.

And this all happens underneath the browser's security model. There's no padlock that turns off, no warning interstitial, no permission prompt at the moment it starts. The proxy setting is applied once, and everything after that just works normally.

Why the permission list won't save you here

The uncomfortable part of this campaign is that a malicious relay and a real browser VPN do mechanically the same thing. Both hold the proxy permission. Both take control of where your traffic goes. Socket was explicit that the mechanism alone wasn't the tell.

I wrote a whole piece on what the proxy permission actually allows — the short version is that it's rare, about 0.8% of the roughly 308,000 listings in our catalog declare it, and every one of those extensions has its hands on your entire connection by design. A real Proton VPN extension requesting proxy plus access to all URLs is not a red flag. It's the job description.

Same story on the store side. I looked at how fake Proton VPN listings pass review back in March, and the conclusion then was the same as now: the fakes request the same broad permissions as the real thing, so a permission diff won't separate them.

What does separate them is intent signals — brand versus actual publisher, advertised infrastructure versus real infrastructure, whether the payment flow goes anywhere, and whether behaviour arrived after approval rather than at submission.

The gap this campaign walks through

Chrome Web Store review is a checkpoint, not a monitor. Google's reviewers inspect what you submit, and the program policies prohibit exactly this kind of impersonation and undisclosed data handling. Both of those things can be true while a listing still ships clean and reaches for a remote config afterwards.

Static review at submission time cannot see behaviour that arrives later. That's not a Google-specific failure — it's structural to any review model where the reviewed artifact can phone home. It's also why "it's in the official store, so it passed review" isn't a security property, and why our own scoring treats proxy configuration, broad host permissions and post-install remote configuration as things that need justifying together rather than one at a time.

How to check what you've got

Five checks, in the order I'd actually do them.

1. Match the publisher, not the logo. Open chrome://extensions, click Details on anything VPN- or proxy-shaped, and follow it to the store listing. The real Proton VPN extension is published by Proton AG. Anything claiming a big brand while listing an unfamiliar developer name or a Gmail-style contact address is the whole tell. Better still, reach the listing by clicking through from the vendor's own website rather than from store search results.

2. Compare the extension ID. The ID in your chrome://extensions URL is the only unforgeable identifier a listing has — names and icons are copyable, IDs aren't. Vendors publish theirs; Socket published the full ID list for this campaign alongside its writeup. If your ID doesn't match the one on the vendor's site, nothing else about the listing matters.

3. Test the claims that cost money to fake. Fake premium tiers fall over fast. Do the advertised server locations actually resolve to those countries? Does the upgrade button lead to a real payment processor, or nowhere? A VPN business that can't take your money reliably is not running server capacity in five countries.

4. Read the review history, not the review count. Campaigns built on 40 throwaway publisher accounts don't have years of gradually accumulated feedback. Thin history plus a big install number plus a famous brand name is the shape to distrust.

5. Check whether you needed a proxy extension at all. If you have a paid VPN subscription, the vendor's desktop app covers your whole device, not just the browser tab. Free browser-only VPNs are the category where the incentive to monetise your traffic is strongest — I compared the honest options in my Firefox built-in VPN versus VPN extensions piece.

If you find one, removal isn't the last step

Uninstalling releases the extension's hold on Chrome's proxy setting in the normal case, but Socket's advice is to confirm rather than assume — so confirm.

Open Chrome settings and search for "proxy". If any extension still controls the setting, Chrome says so directly with a "controlled by an extension" banner; that banner disappearing is your confirmation. Then check your system proxy settings too, since some installers reach outside the browser.

After that, treat the exposure as real rather than theoretical. Any session you held open while the relay was active passed through someone else's server, so sign out and back in on the accounts you care about, and change passwords for anything you logged into over plain HTTP. Not because the operator definitely captured yours, but because you can't prove they didn't, and re-authenticating is cheaper than finding out.

How Extenshi helps

This is precisely the case the catalog exists for. Extenshi tracks listings across Chrome, Firefox and Edge with their permissions, publisher details and scan results, so you can look up an extension's proxy declaration, its publisher and its history without installing it first — including listings that have since been pulled.

If you'd rather start from what's already in your browser than from a store page, npx @extenshi/guard scan reads the extensions installed across your browsers and flags the risky ones, with disable-and-undo built in. No account needed for the scan.

Scan your extensions →

Sources

• 737 Chrome VPN Extensions Linked to Brand Impersonation and Browser Traffic Redirection — Socket Threat Research
• Hundreds of fake Chrome VPN extensions route traffic through a proxy — BleepingComputer
• chrome.proxy API reference — Chrome for Developers
• Chrome Web Store program policies — Chrome for Developers
• @extenshi/guard — scan the extensions already installed in your browser

---

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If any entity referenced in this article believes information is inaccurate, contact [email protected] and we will review and update.