Google and Microsoft have pulled ModHeader, a popular header-editing extension with roughly 1.6 million installs across Chrome and Edge, after researchers found a hidden browsing-history collector built into its official store version.

The collector was dormant. An empty allow-list kept it switched off, and no proof has emerged that it ever gathered or sent a single browsing domain.

The analysis came from Stripe OLT, a UK security firm, which checked the code against Google's own Web Store signature and confirmed the collector shipped inside the genuine extension, not a counterfeit.

Its review covers the Chrome build and its roughly 900,000 users; third-party trackers put another 700,000 or so on Edge. Microsoft pulled the Edge listing on July 3, and Google removed the Chrome one a week later, on July 10.

Version 7.0.18 (extension ID idgpnmonknjnojddfkpgkljpfnnfcklj) still edits HTTP headers as advertised. The same minified background code also contains a second system. On first run, it builds a device fingerprint and loads a hardcoded encryption key. As you browse, it takes the domain from each page you open, encrypts it, and stores it locally, up to 1000 distinct domains.

Once a day, a scheduler bundles the encrypted list with your fingerprint, posts it to api.stanfordstudies[.]com, and wipes the local copy. The upload time is offset per install, so browsers running it would not all beacon at once if the collector were switched on. Separate teardowns, by HackIndex on version 7.0.18 and researcher Yunus Aydin on 7.0.17, describe the same pipeline.

The collector runs only if your browser matches an entry on an internal allow-list, and that list ships empty. The check fails every time, so the pipeline stops before it collects a single domain. Populating that list is a small change, with no new permissions and no click from you, delivered as a routine update. The hardcoded key, the endpoint URL, the scheduler, and the storage logic are already on the machine.

Not everything was asleep. On install, update, and uninstall, the extension pinged a second domain, extensions-hub[.]com, with the product, version, and browser. And a script that runs on every page had already logged real request metadata to local storage in plain text, so that piece had clearly been running.

Automated checkers had rated ModHeader low risk, some as high as 95 out of 100. Each part of the design can frustrate a different kind of check. The data is encrypted, so a scanner sees ciphertext. The upload is gated off, so a sandbox sees nothing leave.

The malicious code is minified into a legitimate codebase. The endpoints had no established malicious reputation to flag. And a signed, popular extension reads as trusted. A store signature proves where a file came from, not what it does.

Where the domains lead

Stripe OLT tied the domains to real, maintained infrastructure. stanfordstudies[.]com has no link to Stanford; it is a repurposed old domain fronting an OpenSearch back end, while extensions-hub[.]com is set up for advertising.

The two API endpoints resolved to the same Amazon server at the time of analysis, which fits one operator without proving it. A handful of weak signals point loosely toward a Chinese-speaking operator: a Simplified Chinese locale, a "salt" marker written with the character 盐, and a China-origin mail provider. The researchers name no group, and neither do we.

The warning signs came earlier. ModHeader drew complaints for injecting ads into search results in 2023 and reportedly went ad-supported around then. Who took it over is unconfirmed, and the researchers make no claim about the original author.

ModHeader's own site still publishes an ad plan that says it collects no user data, which is hard to square with a built-in browsing-history collector, even a switched-off one. The developer has not responded publicly to the findings as of publication.

The Hacker News has contacted ModHeader for comment and put further questions to Stripe OLT, and will update this story with any response.

In 2021, Brian Krebs described how popular extensions get quietly bought and turned into data pipes. This resembles that pattern, now with encryption and a gate that keeps scanners from seeing the upload. This year alone, a run of Chrome extensions was caught collecting data under an "anonymous analytics" label, and a separate set impersonated Workday and NetSuite to steal session cookies. Header editors and cookie managers need broad access to work, and when trust breaks, the blast radius is wide.

What to do

If you have ModHeader, remove it from Chrome and Edge; your browser may have disabled it already. Uninstalling clears its stored data, so the thing to double-check is that profile sync or a managed extension policy will not put it back.

If you pasted secrets into it, API keys, bearer tokens, and session cookies, rotate them, since researchers found its header-history feature storing full HTTP headers on disk.

For defenders, block and log stanfordstudies[.]com and extensions-hub[.]com at DNS and proxy, and search logs for the extension ID and any POST to api.stanfordstudies[.]com/app/log. Stripe OLT published ready-to-run KQL hunting queries for Defender and Sentinel.

The takedowns handle this one extension. The design is the part that should worry people: a complete, store-verified collector sat inside a trusted, popular tool, one apparently built to switch on once an ordinary update populated the empty list. The automated scanners rated it low risk, and the next tool built this way may look just as clean.

The practical lesson is narrow: extension review has to watch for dormant code paths that testing never triggers, new call-home endpoints, and a capability a routine update can add after a change of hands.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.