Millions Installed These Chrome Extensions. What Were They Really Doing Behind the Scenes?

Not a Medium member? You can read it for free using the official Friend Link.

You need to open a PDF manual.

A search result advertises a convenient browser extension. The Chrome Web Store page looks normal, installation takes a few seconds, and a small icon appears beside the address bar.

Maybe the tool even works.

Nothing crashes. No ransomware screen appears. There is no suspicious executable sitting on the desktop, and the next time you search from Chrome, you still end up looking at familiar results.

From the user's perspective, almost nothing has changed.

Behind the interface, however, the browser may now trust a piece of third-party software to influence one of the most information-rich workflows on the machine.

On October 29, 2026, Socket researcher John Tuckner published an investigation identifying 319 browser extensions associated with roughly 13.4 million reported installations across about a decade. Many were marketed as ordinary utilities: manual finders, PDF tools, safe-search products, and AI-search extensions. Socket found extensions taking over the browser's default search configuration, routing queries through operator-controlled infrastructure, and attaching referral identifiers associated with Yahoo or Bing search traffic.

The scale is striking.

The mechanism is more interesting.

In at least one of the examples Socket examined, surprisingly little executable code was needed.

Sometimes the "Malware" Is Almost Just Configuration

When engineers review a suspicious extension, they naturally look for code.

What background scripts does it run? Which pages receive injected JavaScript? What permissions does it request? Does it read tabs, history, cookies, or page content?

Those questions matter.

But an extension manifest is not merely metadata describing the package. It can also tell the browser how parts of the browser itself should behave.

Chrome supports a manifest setting called chrome_settings_overrides, which can be used by extensions that legitimately provide search functionality. A simplified example looks like this:

{
  "chrome_settings_overrides": {
    "search_provider": {
      "name": "Example Search",
      "is_default": true,
      "search_url": "https://search.example.com/?q={searchTerms}"
    }
  }
}

{
  "chrome_settings_overrides": {
    "search_provider": {
      "name": "Example Search",
      "is_default": true,
      "search_url": "https://search.example.com/?q={searchTerms}"
    }
  }
}

The domain here is fictional. The important part is the mechanism.

Chrome substitutes {searchTerms} with whatever the user typed into the address bar and sends the query to the configured endpoint.

There is nothing inherently malicious about that capability. Search extensions have legitimate reasons to provide their own search provider, and the browser has supported mechanisms around changing search configuration.

Now imagine that the configured endpoint belongs to the extension operator.

The extension does not need to inject code into every page to influence the search. Chrome itself performs the routing based on the declared configuration.

Socket documented one analyzed extension that essentially consisted of its manifest and icons, with no background script, content script, or declared permissions. That should not be generalized to all 319 extensions, since other members of the broader campaign requested more sensitive capabilities. But the example is valuable precisely because it challenges an intuitive review habit.

Very little local code does not necessarily mean very little security impact.

The extension has changed the path through which user intent travels.

Once the query reaches an intermediary server, that server can observe it. It can also decide what happens next.

That distinction pushes the interesting security boundary away from the amount of JavaScript inside the package and toward the authority created by configuration.

The important primitive was not simply code execution.

It was control over the path.

The Extension You Review Is Not Necessarily the Behavior You Keep

At installation time, users tend to think about an extension as a static object.

You are installing version 1.4 of a particular package. You see its description, perhaps glance at its permissions, and make a trust decision.

Real extension behavior can depend on much more than that package.

Remote APIs can change. A backend can return different instructions. Publishers can push updates. Ownership can change. Functionality can activate only after a delay or for a subset of users.

The security object is therefore larger than:

extension version 1.4

It is closer to the extension, its privileges, browser APIs, publisher, update channel, remote infrastructure, and whatever control those external systems retain after installation.

Socket's search-hijacking investigation illustrates one version of this. Once searches reached the intermediary, the installed extension did not need to change for different outcomes to occur. The server could make routing decisions remotely.

Other 2026 investigations show how much further that separation can go.

In June, Microsoft's Edge Extensions Security Team disclosed StegoAd, a campaign involving 119 malicious extensions with a combined install base of up to 2.6 million. Microsoft reported delayed execution, probabilistic activation, server-side validation, and malicious payload material concealed inside image and later font resources. Crucially, Microsoft noted that not every installation caused the payload to execute because the campaign deliberately gated activation.

That gives defenders an uncomfortable distinction:

Installed does not necessarily mean activated.

And benign behavior during one analysis window does not prove benign behavior indefinitely.

Akamai documented another version of the same trust problem in its February investigation of 30 fake AI-assistant extensions affecting more than 260,000 users. Those extensions displayed functionality through remotely hosted iframes and used privileged extension code as a bridge to browser capabilities. Because substantial portions of the interface and logic were hosted remotely, the operator could change behavior without publishing an equivalent new extension package through the store.

That is a different mechanism from Searchjacked, and it should not be collapsed into the same campaign.

But architecturally, both incidents point toward the same broader concern.

Trust is usually granted at one moment.

Behavior can evolve afterward.

This makes extension security a lifecycle problem rather than merely an installation-time review problem.

The Browser Is Where Too Many Valuable Things Meet

Browser extensions are especially attractive because of where they live.

Your browser is no longer just a document viewer.

It is where you open email, source-control platforms, cloud dashboards, banking services, internal admin tools, company SaaS products, AI assistants, customer applications, and development interfaces.

A traditional malicious program might have to discover where valuable information lives on the machine.

A browser extension can begin life already attached to the environment where much of that information is handled.

It may not need complete control of the operating system.

It may only need the right visibility at the right layer.

Microsoft demonstrated how valuable that boundary has become in March 2026 when it reported malicious Chromium extensions impersonating AI-assistant tools and collecting browsing information along with LLM conversation histories. Microsoft said public reporting placed the extensions at roughly 900,000 installs, while its own telemetry showed related activity across more than 20,000 enterprise tenants.

That matters because AI conversations increasingly contain information that previously lived in separate development tools.

An engineer pastes a stack trace into ChatGPT.

Another pastes internal source code.

Someone asks for help interpreting infrastructure logs.

A product manager discusses unreleased strategy. An employee includes customer information while asking for help drafting a response.

The browser becomes an aggregation point for organizational context.

Microsoft reported that the malicious extensions collected full URLs and excerpts of AI conversations and periodically transmitted that information to external infrastructure. The issue was not that the extension controlled the entire machine. It was positioned where valuable information already flowed.

That changes how extension risk should be framed.

Security discussions often focus on whether software has broad or "full" access. But modern systems create strategically valuable boundaries that are much narrower than full machine control.

The right browser visibility can expose authenticated applications.

The right search-provider configuration can reveal user queries.

The right content-script permissions can expose information rendered inside sensitive pages.

The right remote bridge can allow external infrastructure to influence privileged browser functionality.

For developers, this is not merely a consumer-security concern.

A development browser may contain GitHub sessions, cloud consoles, observability dashboards, local development applications, API management systems, deployment tools, internal documentation, and production administration interfaces.

The extension is small.

The trust boundary it enters is enormous.

Browser Extensions Belong in the Supply-Chain Threat Model

Engineering organizations already understand this style of risk in other places.

When adopting an npm package, teams may ask who maintains it, how frequently it changes, what dependencies it brings in, whether it communicates externally, and what would happen if the maintainer account were compromised.

IDE plugins increasingly receive similar scrutiny.

Browser extensions deserve the same mental model.

The first step is to review authority, not merely count permissions.

A long permissions list can certainly indicate significant access. But the Searchjacked investigation shows why a short list does not automatically imply a trivial security boundary. Declarative configuration may alter browser behavior even when the package contains little executable logic.

The useful question is:

What can this extension cause the browser to do?

Then look outward.

If an extension communicates with remote infrastructure, what is that infrastructure responsible for? Is it simple telemetry? Does it supply configuration? Can it influence routing? Does core functionality come from remote content?

This is where network destinations become part of architectural review rather than just incident-response evidence.

For organizations, there is also a much simpler control that is easy to overlook: know what is installed.

If a new security advisory names a browser extension ID tomorrow, an engineering team should be able to determine whether that extension exists anywhere in the organization.

Without an inventory, a security team can have excellent threat intelligence and still struggle to answer the most basic incident question:

Are we affected?

Updates deserve similar attention.

An extension that deserved trust six months ago is not frozen in time. New code can arrive. A publisher account can be compromised. The project can be sold. A remote backend can change even without a package update.

That suggests a better question than:

Was this extension safe when we installed it?

Ask:

What continues to deserve trust after installation?

Finally, browser policy should reflect workload sensitivity.

A browser used primarily for casual personal browsing does not have the same consequence profile as one used to administer production AWS infrastructure, access a secrets manager, review customer data, or operate financial systems.

The more privileged the work, the more conservative the extension environment should become.

This does not require treating every add-on as hostile.

It means recognizing that convenience software can occupy privileged positions.

We already treat application dependencies as part of the software supply chain because small external components can influence systems far larger than themselves.

Browser extensions deserve similar scrutiny because they execute beside the applications engineers use to build, deploy, debug, and operate everything else.

The ordinary PDF extension from the beginning may have looked like a simple trade: useful feature in exchange for a small amount of browser access.

The actual transaction can be larger.

The user is granting persistent placement inside a trusted computing boundary.

That does not mean every extension is dangerous, and the Searchjacked findings do not mean 13.4 million unique people were simultaneously infected with malware. Socket's figure spans hundreds of extensions and roughly a decade, and its demonstrated activity centered primarily on search interception, proxy routing, and referral monetization rather than confirmed credential theft or malware delivery.

The restraint matters because the verified mechanism is already consequential.

A piece of software does not need to look powerful to occupy a powerful position.

And once it sits inside a trusted boundary, the security question is no longer only what it does today.

It is what that continuing trust could allow it to become tomorrow.

Contents

Sometimes the "Malware" Is Almost Just Configuration

The Extension You Review Is Not Necessarily the Behavior You Keep

The Browser Is Where Too Many Valuable Things Meet

Browser Extensions Belong in the Supply-Chain Threat Model