737 Fake VPN Extensions Piped Chrome Through a Proxy

The mechanism is boring, which is exactly why it worked. No zero day, no obfuscated payload, no supply chain compromise. Just one legitimate Chrome API, used as documented, by an extension the browser had no reason to distrust. The question is not how the code worked but why nothing in the install flow gave it away.

Key Takeaways

• Socket documented 737 Chrome extensions published through more than 40 developer accounts, with 75,486 combined installs, in research published on 12 August 2026.
• 520 of the 522 packages Socket retrieved configured Chrome to send traffic to a fixed SOCKS5 server on port 1082, with a bypass list containing only localhost, 127.0.0.1 and ::1.
• 274 of the extensions copied the names or branding of 66 real VPN and privacy services, including Proton VPN, NordVPN, ExpressVPN, Surfshark and Cloudflare's 1.1.1.1 resolver.
• 497 of 522 packages requested a single permission, proxy, which Chrome surfaces to users with the warning "Read and change all your data on all websites."
• Google removed 221 of the extensions, but Socket found 516 still live on the Chrome Web Store when it published, holding 58,318 of the installs.

How Did One Permission Redirect an Entire Browser?

By calling chrome.proxy.settings in fixed_servers mode, which is a supported, documented Chrome extension API that overrides the browser's network path for every tab at once.

Google's chrome.proxy reference describes fixed_servers as a mode where "the proxy configuration is codified in a ProxyRules object", alongside a bypassList of "servers to connect to without a proxy server." That pairing is the whole attack: point the rules at your own SOCKS5 host, leave nothing meaningful in the bypass list, and every request the browser makes goes to you.

Socket found the bypass lists in this campaign contained exactly three entries: ["localhost", "127.0.0.1", "::1"]. Loopback only. Nothing on the public internet was excluded. 302 packages hardcoded proxy addresses from a shared pool of just 15 IPs, and 104 layered DNS over HTTPS through Cloudflare and Google resolvers, hiding the lookups from the user's own network while the operator kept full visibility.

None of that is a bug in Chrome. It is a VPN extension doing the one thing a VPN extension is supposed to do, pointed at the wrong server.

What Can a SOCKS5 Operator Actually See?

Every destination you visit, the TLS SNI value for each one, your real source IP, and the full body of anything sent over plain HTTP. Not the contents of your HTTPS sessions.

Socket's phrasing is worth quoting rather than paraphrasing: 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." That is the honest boundary, and much of the coverage blurred it.

The hostname leaks even under TLS because Server Name Indication travels in the clear during the handshake. It is defined in RFC 6066 as an extension the client sends before encryption is established, so the server knows which certificate to present. A SOCKS5 proxy, per RFC 1928, is separately handed the destination address in the connect request. The operator learns the target twice over.

Here is the part people underrate. You do not need message contents to build a devastating profile. A timestamped list of every host a browser reaches, tied to a stable source IP, is a complete browsing history delivered live. It shows which bank you use, which clinic portal you log into, which opposition news site you read, and whose intranet you touch at 9am. Advertising networks pay real money to reconstruct a worse version of that from fragments. This campaign got it free, from users who installed the extension specifically to prevent it.

Why Didn't the Chrome Web Store Catch 737 of Them?

Some of it did get caught, slowly and incompletely. Google pulled 221 extensions, which left 516 live and holding most of the installs at the moment Socket published.

The brand copying alone should have been disqualifying. Chrome's impersonation policy tells developers plainly: "Don't pretend to be someone else, and don't represent that your product is authorized by, endorsed by, or produced by another company or organization, if that is not the case." An extension called 1.1.1.1 VPN that is not from Cloudflare is not a borderline case requiring nuanced judgement.

Timing makes the enforcement gap concrete. Socket notes Palo Alto Networks disclosed 18 extension IDs from this operation on 5 June 2026, and 14 of 15 checked were removed within seven weeks. Seven weeks per batch, against 40 publisher accounts that can mint new listings in an afternoon, is losing arithmetic: takedown runs at the pace of individual reports, publication at the pace of automation.

This is not a one off, either. It follows the same pattern as the 77 evil twin extensions found on Open VSX and the fake Perplexity extension that logged users' searches: a trusted name, a plausible function, and a store review process that scales worse than the abuse does.

How Do You Audit Your Own Extensions?

Four checks, in order, and none of them take longer than a few minutes.

• Open chrome://extensions and read the list properly. Turn on Developer mode to see each extension's ID. Anything you do not remember installing, or cannot name the purpose of, goes.
• Click Details and read the permissions. Google's permissions reference confirms the proxy permission carries the warning "Read and change all your data on all websites." If something that is not a network tool holds it, that is your answer.
• Check who actually controls your proxy setting. Visit chrome://settings/system. If an extension has taken over the proxy configuration, Chrome says so there by name and offers no way to change it except removing that extension. A single line, and it settles the question.
• Look up the publisher before installing anything. Real VPN vendors link to their extension from their own domain, so follow that link rather than searching the Web Store, because search results are exactly where impersonators compete.

If you want a shortlist of tools that have survived scrutiny, our roundup of anti tracking browser extensions is a safer starting point than a store search.

What This Means for Your Inbox

If you read mail in a browser tab, a proxy extension is upstream of your webmail. It cannot read your messages, because Gmail, Outlook and Proton Mail are all HTTPS and the proxy only carries the encrypted stream. What it does get is a timestamped record that this IP address connected to mail.google.com, over and over, in a pattern that maps your working hours precisely.

The sharper risk is structural rather than specific. Every extension you grant access to a webmail tab operates inside the same trust model that failed here: a name you recognise, a permission that sounds justified, a review process that catches things weeks after the installs happen. That applies to the extensions that read your inbox even more than it applies to a proxy that only sees the outside of it, and we saw the same failure play out with ModHeader, a developer tool that turned into a browsing collector.

The practical rule: keep the count of extensions with broad access low enough that you can name each one and say what it does. Most Chrome profiles fail that test badly.

The Irony Is the Point

Roughly 75,000 people, many of them Russian users trying to reach services blocked where they live, went looking for a tool to stop somebody watching their traffic and handed that traffic to a stranger instead. Socket tied the extension farm to a commercial storefront through eight Yandex Metrika analytics counters, which means the operation was run as a business, with dashboards.

The users who most need a working VPN are the ones with the least ability to verify one, and store search rewards whoever ships the most listings. Until enforcement moves faster than publication, "it was on the Chrome Web Store" carries about as much assurance as "it was on the internet."