Every time someone asks me which VPN to install, I answer with a warning first: be picky. That advice just got a very concrete example. Socket’s threat research team found 737 free VPN and proxy extensions on the Chrome Web Store that quietly route your entire browser session through proxy servers controlled by a single, unknown operator — while pretending to be Proton VPN, NordVPN, Surfshark, ExpressVPN, Windscribe, Cloudflare’s 1.1.1.1, and dozens of other trusted brands.
Exactly 274 of those extensions impersonated 66 established names, and the campaign racked up 75,486 installs across at least 40 publisher accounts. The bulk of the audience was Russian-speaking users hunting for a way around blocked services, but the store doesn’t gate installs by region — anyone could have grabbed one. Socket’s full report breaks down the mechanics, and The Hacker News and BleepingComputer summarized it for a broader audience. What I want to give you is the five-step check I would run on any browser I manage — with the exact commands, so you can verify a suspicious extension yourself.
What these extensions actually do
Under the hood, 520 of the 522 extensions Socket could analyze with code set Chrome’s proxy settings (chrome.proxy.settings) to a fixed SOCKS5 server on port 1082, with a bypass list that only includes loopback addresses. The practical effect: once you connect, every browser request — not just the one you think the VPN is handling — gets funnelled through the operator’s relay.
Socket puts the impact plainly: the operator sits in an adversary-in-the-middle position, able to see the destinations your browser reaches, the TLS SNI value of every HTTPS connection, your source IP address, and the complete contents of any request sent over plain HTTP. If you typed a password into a non-HTTPS page while connected, that password crossed a server the threat actor controls.
Three behaviors stood out across the corpus:
- Traffic interception. 520 of the 522 analyzed extensions pointed at the same SOCKS5 infrastructure — a single relay for the whole campaign.
- Detection evasion. 104 extensions resolved their proxy hostnames through Cloudflare and Google DNS-over-HTTPS and handed Chrome a raw IP address, so your machine never emits a plaintext DNS query for the attacker’s domains.
- Subscription fraud. The paid tier advertised servers in Japan, Singapore, Canada, Australia, and Turkey. Not one of those 200 hostnames actually resolved.
None of this was an accident. The listings mimicked real product names and icons, and the extensions even shipped a polished fake connection interface with a working “connecting” animation that fails every attempt. Socket traced the operation to a subscription VPN business in Russia, complete with a tax-registered contractor and a billing dashboard under the “myxa” branding.
Step 1: List what is actually installed
Open chrome://extensions and scroll through the list. You are looking for any VPN- or proxy-related tool you don’t remember installing, or an extension carrying a brand name but added by a publisher you’ve never heard of. Every Chrome extension has a unique 32-character ID — jot down the IDs of anything suspicious, because that is what you’ll match against the published indicator list in Step 4.
Step 2: Verify the publisher, not just the name
The store’s detail page tells you who published an extension and roughly how many people use it. I tested this live while writing this guide. For the real Windscribe extension (ID hnmpcagpplmpfojmgmnngilcnanddlhb), the page shows publisher Windscribe Limited and 2,000,000 users. A legitimate product has a real company behind it and years of accumulated installs; the fakes in this campaign came from freshly created accounts with tiny install counts and no matching corporate identity. It’s the same publisher check I walked through in my guide to vetting VS Code extensions — that market had its own evil-twin problem this month.
If you’re comfortable in a terminal, the check takes seconds:
curl -s "https://chromewebstore.google.com/detail/windscribe-vpn/hnmpcagpplmpfojmgmnngilcnanddlhb?hl=en" -A "Mozilla/5.0" | grep -oE "<title>[^<]+"That returns the listing title straight from the page. Swap in the extension ID you’re checking, and read the “Offered by” line and user count the same way — or just open the detail page in a browser and look at them directly. The pattern that matters: does the publisher match the brand, and does the install count look like a real product’s history?
Step 3: Look at the permissions
Click Details on any extension, then View permissions. A VPN extension needs the proxy permission — that’s the mechanism it runs on. But treat that permission the way Socket does: narrow in appearance and total in effect. Any extension holding proxy can redirect all of your traffic, and in this campaign the permission footprint stayed at ["proxy"] even after a post-approval update added an entire remote-configuration layer. Permission diffs alone won’t catch capability changes, so pair this check with the publisher check above.
Also be wary of a VPN tool asking for Read your browsing history or Read and change all your data on all websites — a proxy doesn’t need to read your tabs to work.
Step 4: Match IDs against the published list
Socket published the full indicators of compromise: 516 extension IDs that were still live in the store when the corpus was collected, and 221 that had already been delisted. Compare the IDs you noted in Step 1 against that list. One example straight from the report is aaeiefggdeljohngedhpmgidkjcdoebb (“myxa vpn”), and the network indicators include the billing dashboard myxavpn[.]pro and a block of proxy IP ranges. If any of your installed IDs show up, remove the extension and treat the machine as exposed.
Matching installed IDs against a published indicator list is the same discipline as detecting compromised npm packages in your project — the list changes faster than your memory, so always check the live source.
Step 5: Remove, reset, and rotate
Remove the extension first. Then open chrome://settings, search for “proxy,” and confirm Chrome is back to using your system proxy settings (or none at all). Change any credentials you entered on a non-HTTPS site while the extension was connected — those went through the relay in plain text. And assume your browsing history from that period was observed by a third party.
For anyone running machines for other people, the same cleanup applies at scale: uninstall the extension from every profile, check the proxy settings on each device, and rotate shared credentials that could have crossed the relay.
A quick red-flag checklist
If you only remember one section of this guide, make it this table. Any one of these signs on a VPN extension is reason to remove it:
| Red flag | What it usually means |
|---|---|
| Publisher name doesn’t match the brand | The listing is impersonating a real product |
| Tiny install count on a famous name | Freshly created account, no real history |
Requests proxy plus read-all-data permissions | Overreach — a proxy doesn’t need your tabs |
| Premium locations that never connect | Subscription fraud, selling servers that don’t exist |
| A “connecting” animation that never succeeds | Fake interface hiding a real relay |
| Update changes behavior after approval | Post-approval code substitution |
None of these signs alone is proof, but two or three together are a strong signal. The extensions in this campaign showed several of them at once.
How to avoid the next one
Treat the proxy permission like <all_urls> — the highest-risk permission an extension can hold. Install VPN software from the official app or the vendor’s verified store page, never from a random search result. Check the publisher every time, especially for brand-name extensions you didn’t seek out.
If you manage an organization’s browsers, Socket’s recommendations are worth copying: block the campaign’s domains and IP ranges at DNS and egress — DNS blocking alone fails against the extensions that resolve through DNS-over-HTTPS and pin raw IPs — and inventory which installed extensions hold the proxy permission. None of this replaces patching the browser itself — Google’s AI-assisted pipeline just fixed 1,072 Chrome security bugs in two releases, and staying current is the cheapest defense you have.
The bottom line
A “free VPN” extension that funnels every request through a stranger’s relay is worse than no VPN at all — it hands an unknown party a map of your browsing and the keys to anything you type on plain HTTP. The good news is that the check is short: list your extensions, verify the publisher, read the permissions, match the IDs, and clean up when something’s off.
This is the same trust question I keep coming back to with any tool that gets power over your machine. If you use coding assistants, the same reasoning applies to auditing the MCP servers they run; if you ship code, it applies to the packages you pull in. None of this is paranoia — it’s just verifying who actually holds the door you’re walking through.