Hidden Chrome extensions explained: what obfuscated tracking code can really do

Here's an uncomfortable fact about the Chrome Web Store: an extension can rack up hundreds of thousands of installs while staying invisible. Not removed. Not banned. Just configured so it never shows up in search.

In April 2025, security researcher John Tuckner of Secure Annex published research on 35 hidden Chrome extensions with about 4 million combined users. Within a week the count grew to 57 extensions and almost 6 million users, BleepingComputer reported.

Nearly all were unlisted. Their code was heavily obfuscated. And they shared one odd string: a misspelled domain, unknow.com.

Two red flags at once: an invisible listing and unreadable code. Either one deserves a hard look. Together they describe software built to avoid being seen. Here's what "hidden" means, why the obfuscation is the bigger alarm, and how to check your own browser.

What "hidden" means on the Chrome Web Store

Developers pick one of three visibility settings for an extension:

• Public: listed and searchable.
• Unlisted: anyone with the direct link can install it, but it never appears in search.
• Private: limited to specified users, typically testers before a launch.

The "hidden" extensions in this story were unlisted.

Unlisted doesn't mean unreviewed. Google's distribution docs say all three settings carry the same policy requirements and go through the same review. What unlisted changes is discovery: every install starts with someone handing you a direct link, like an ad or a bundled installer.

There are legitimate reasons to go unlisted: a companion extension for hardware, a beta for testers, an internal tool. Google even added a private publishing option for deploying extensions to outside organizations that approve them. In each case, the people installing know the extension exists. A hidden extension with hundreds of thousands of users inverts that, because the installs came through channels the store never sees.

The unknow.com campaign

Tuckner's investigation started with one extension: "Fire Shield Extension Protection." It was unlisted, had 300,000 users and a 2.2 rating, and claimed to warn you about problematic extensions. For that job it asked for far more than it needed: web traffic on all sites, cookies, tabs, and script execution.

Its background code contained unknow.com, a domain that did nothing. But searching for it surfaced 35 extensions, and Tuckner linked them through:

• the same code patterns
• near-identical callback domain structures
• matching permission sets across different listed owners
• that useless, misspelled domain

Most claimed to block ads, protect your privacy, or improve search, but the code for that purpose was often minimal or missing. Secure Annex later added Google Ads Transparency results, shared by another researcher, suggesting they were pushed through ads. Some even carried the store's Featured badge while unlisted. As Tuckner pointed out, a quality badge on something nobody can find makes no sense.

Google told BleepingComputer it was investigating, and Tuckner said many of the extensions came down after his report. The developer didn't answer BleepingComputer's questions.

In October 2026, I checked the IDs from Secure Annex's published list against the Chrome Web Store. All but one no longer have a listing. The holdout is a public coupon extension that Tuckner explicitly stopped short of calling malicious. Store status tells you what new users can install, not what's already in your browser.

Why the obfuscated code is the louder alarm

A hidden listing is a distribution choice. Obfuscated code is a concealment choice, and there are very few innocent reasons for it.

Minification — stripping whitespace, shortening variable names — is normal. Obfuscation goes further: string arrays decoded at runtime, hex-escaped identifiers, control flow flattened into nonsense loops. The goal isn't a smaller file. The goal is code that neither a human reviewer nor an automated scanner can read.

The Chrome Web Store developer program policies say it plainly: developers must not obfuscate code or conceal functionality. The rule also covers code the extension fetches from elsewhere. Manifest V3 adds another constraint: extension logic must ship inside the package, so the store reviews the bytes that actually run.

Tuckner's findings point to one way around that: keep the reviewed code quiet and steer it from outside. When he ran Fire Shield, it sent little more than click events and heartbeat pings. Then he loaded a configuration with one changed value, vLvl: 5, into a sibling extension, and a much deeper level of tracking switched on.

Tuckner believes the remote server controls that value, probably only after an install has been around for a while. One function also appears to run script from external URLs inside an embedded iframe. Obfuscation hides the switch; remote configuration flips it.

Tuckner also found privacy policies dated as far back as November 2019, a hint this had been running for years.

Concealment is an arms race. In my GhostPoster breakdown, the payload hid inside the extensions' own logo PNGs. Different trick, same goal: ship something the review pipeline can't read.

What that tracking can actually see

"Tracking code" covers a lot of ground, so here's what Tuckner documented in the code these extensions shared:

• grabbing all cookies for a given domain
• reading sensitive request headers, like Authorization and Cookie, before requests leave the browser
• setting a long-lived cookie that follows you across sites
• swapping your search provider and routing queries through referral links
• signs of remote-command features, like listing your top sites and opening or closing tabs

He never caught one stealing credentials, and some capabilities stayed unvalidated. Capability isn't proof of abuse. But an "extension protector" has no business reading your Authorization headers.

Even modest permissions allow real surveillance. An extension with host access to all sites can inject content scripts that report every URL you visit. No history permission required. My scripting permission breakdown covers how that injection works.

The privacy harm doesn't require reading your banking page. A job board, a divorce lawyer, a pregnancy forum, and a competitor's pricing page — in order, with timestamps — is already the product. A remotely configured tracker could collect that trail without ever touching a password.

The gap between what extensions declare and what they do goes beyond this campaign. An ACM study I covered in runtime tracking vs permissions found about 16% of 21,000 extensions started third-party tracking within 60 seconds of loading.

When unlisted is fine — and when it isn't

An extension being unlisted isn't a verdict on its own. Here's how I weigh it.

Fine: you know where it came from. Your employer pushed it, it's the companion to a device you bought, or a developer gave you a beta link. Either way, "how did this get into my browser?" has a one-sentence answer.

Concerning: you don't remember installing it, and searching its exact name in the store returns nothing. The name is vague reassurance — "protection," "shield," "safety," "secure" — and the listing explains nothing specific. It's worse if it also matches this campaign: unreadable code, unfamiliar outbound domains, and an install count organic discovery could never produce.

One hidden utility extension might be a developer avoiding attention for a benign reason. Dozens of them sharing code and a misspelled domain is an operation.

How to find hidden Chrome extensions

You can run this audit in about five minutes:

1. Open chrome://extensions and take inventory. Anything you don't recognize, or can't remember installing, is a removal candidate. The bar is "I use this," not "it seems harmless."
2. Search the exact name in the Chrome Web Store. If it doesn't show up, it's either unlisted or gone from the store. Neither proves malice, but if you can't reconstruct how it got installed, remove it.
3. Check how each keeper handles your data. Open its listing and read the privacy practices section, not the marketing text.
4. Report what you find. Every listing has a Flag Issue flow that goes to Google; the steps are documented in the Chrome Web Store Help.
5. Check the whole set at once. Extenshi Guard lists every extension across the browsers on your computer with npx @extenshi/guard list. No account needed, and nothing leaves your machine. With a free account, npx @extenshi/guard scan checks each one against the Extenshi catalog and marks it remove, disable, or review.

Check your permissions → Before your next install, paste the store link to see its safety score and permission breakdown. Or browse the catalog first — an extension's permission footprint is visible long before its behavior is.

Epilogue: where the researcher ended up

One more data point: on April 28, 2026, supply-chain security firm Socket acquired Secure Annex, extending its coverage beyond package managers to browser and editor extensions. Tuckner joined Socket.

Tuckner said he started Secure Annex after watching extensions become a major attack surface. "Most organizations had no visibility into what they were installing," he said in Socket's press release.

Hidden extensions are the consumer version of that blind spot. The store reviews a submission, but remote configuration can change the software long after review. Your browser is where you'd notice.

Sources

• Searching for something unknow — Secure Annex
• Chrome extensions with 6 million installs have hidden tracking code — BleepingComputer
• Socket has acquired Secure Annex — Socket
• Socket acquires Secure Annex to expand extension security across browsers and developer tools — EIN Presswire
• Chrome Web Store program policies — Chrome for Developers
• Prepare to publish: set up distribution — Chrome for Developers
• New enterprise publishing option in the Chrome Web Store — Chrome for Developers
• Flag issues & report copyright infringement — Chrome Web Store Help

---

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 you believe any information is inaccurate, please contact us at [email protected].