Google and Microsoft have removed ModHeader, a popular browser extension used to edit HTTP headers, after researchers found a hidden browsing-history collection system inside the official store version.
The extension had around 1.6 million installs across Chrome and Edge. According to the research, the collector was present in the genuine signed extension, not a counterfeit copy.
The most important detail is that the collector appears to have been dormant. An empty internal allow-list kept it switched off, and researchers found no evidence that it actually collected or uploaded browsing domains.
But the design still raises serious concerns.
A complete collection pipeline was already present on users’ machines. A routine update could have activated it without requiring new permissions or any additional user action.
What ModHeader Is
ModHeader is a browser extension designed for developers, testers, and security professionals.
Its normal purpose is legitimate: it allows users to modify HTTP request and response headers. This can be useful for debugging APIs, testing authentication flows, changing user-agent values, working with CORS, or simulating different browser conditions.
Because of that functionality, header-editing extensions often require broad access.
That is exactly why trust matters.
When a tool that can observe or modify browser traffic contains hidden collection logic, the risk is much larger than with a simple visual extension or theme.
What Researchers Found
The analysis came from Stripe OLT, a UK-based security firm.
Researchers reviewed the official Chrome Web Store build and confirmed that the suspicious code was included in the genuine extension package. This matters because it rules out a simple fake-extension scenario.
The affected Chrome build reportedly had around 900,000 users, while third-party trackers estimated around 700,000 additional users on Edge.
Microsoft removed the Edge listing on July 3, and Google removed the Chrome listing on July 10.
The version highlighted in the report was ModHeader 7.0.18, with extension ID:
idgpnmonknjnojddfkpgkljpfnnfcklj
The Hidden Collection Pipeline
ModHeader still performed its advertised header-editing function.
But the same minified background code also contained a second system.
On first run, the extension could build a device fingerprint and load a hardcoded encryption key. As a user browsed, the collector was designed to take the domain from each visited page, encrypt it, and store it locally.
The local store could hold up to 1,000 distinct domains.
A scheduled process was then designed to bundle the encrypted domain list with the device fingerprint and send it once per day to:
api.stanfordstudies[.]com
After upload, the local copy would be cleared.
The upload timing was also offset per installation, meaning browsers would not all beacon at once if the system were activated.
That kind of design looks deliberate and operationally aware.
Why It Did Not Activate
The collector only ran if the browser matched an internal allow-list.
That allow-list shipped empty.
Because of that, the check failed every time and the pipeline stopped before collecting browsing domains.
This is why researchers found no proof that the browsing-history collector actually exfiltrated data.
However, the concern is that the inactive state could change quickly.
Populating the allow-list would be a small update. It would not necessarily require new permissions, and users would not need to click anything.
The key components were already present:
- hardcoded encryption key
- endpoint URL
- scheduler
- fingerprinting logic
- local encrypted domain storage
- upload mechanism
That is what makes the dormant code path so concerning.
Not Everything Was Dormant
Although the main browsing-domain collector was disabled, other activity was already live.
The extension reportedly contacted a second domain:
extensions-hub[.]com
This happened on install, update, and uninstall, sending details such as product, version, and browser.
Researchers also found that a script running on every page had already logged real request metadata into local storage in plain text.
So while the most sensitive browsing-domain upload pipeline appears to have remained inactive, the extension was not completely quiet.
Why Automated Scanners Missed It
One of the biggest lessons from this case is that automated extension checks can be fooled by design.
Some automated tools reportedly rated ModHeader as low risk, with scores as high as 95 out of 100.
That is not surprising when you look at how the system was built.
The code was minified inside a legitimate extension. The upload path was gated, so sandbox testing would not necessarily see outbound exfiltration. The collected data was encrypted, so static scanners would see ciphertext rather than obvious browsing history. The domains did not already have strong malicious reputations. And the extension was signed and popular, which often creates a false sense of trust.
A store signature proves that the file came from the official store.
It does not prove that the code is safe.
Suspicious Infrastructure
Stripe OLT tied the domains to real, maintained infrastructure.
The domain stanfordstudies[.]com reportedly had no link to Stanford and appeared to be a repurposed old domain connected to an OpenSearch backend.
The second domain, extensions-hub[.]com, was associated with advertising infrastructure.
At the time of analysis, both API endpoints reportedly resolved to the same Amazon-hosted server. That suggests a possible shared operator, although it does not prove attribution.
Researchers also noted weak signals that could point toward a Chinese-speaking operator, including locale and naming clues, but no specific threat group has been named.
Attribution remains uncertain.
Warning Signs Before the Takedown
The ModHeader situation did not appear completely out of nowhere.
The extension reportedly drew complaints in 2023 for injecting ads into search results and was said to have become ad-supported around that period.
That does not prove who was responsible for the hidden collector.
It also does not prove whether ownership changed hands or whether the original developer was involved.
But it fits a broader pattern seen in the browser-extension ecosystem: popular tools can be acquired, monetized, modified, or slowly turned into data-collection vehicles.
Browser extensions are attractive because they already sit inside the user’s daily workflow and often hold broad permissions.
Why This Matters
This case is not only about ModHeader.
It is about the risk of trusted extensions carrying dormant functionality that can be activated later.
A browser extension can look legitimate, work as advertised, pass automated checks, receive good ratings, and still contain a hidden system that only activates under specific conditions.
That creates a difficult problem for defenders.
Security reviews cannot only check what happens during a short test run. They also need to examine dormant code paths, suspicious endpoints, update mechanisms, and hidden logic that can be switched on later.
The next extension built this way may look just as clean.
What Users Should Do
Anyone who has ModHeader installed should remove it from Chrome and Edge.
Browsers may already have disabled it automatically, but users should still check manually.
Important steps include:
- remove ModHeader from Chrome and Edge
- confirm browser sync does not reinstall it
- check managed extension policies in corporate environments
- rotate any secrets pasted into the extension
- rotate API keys, bearer tokens, and session cookies if they were handled through ModHeader
- review browser extension permissions more broadly
The header-history feature is especially important because researchers found full HTTP headers stored on disk. If sensitive tokens or cookies were used there, they should be treated as exposed.
What Defenders Should Do
Security teams should treat this as a browser-extension supply-chain event.
Recommended actions include blocking and logging:
stanfordstudies[.]comextensions-hub[.]com
Teams should also search endpoint, proxy, DNS, and browser-management logs for the ModHeader extension ID:
idgpnmonknjnojddfkpgkljpfnnfcklj
Useful hunting areas include:
- POST requests to
api.stanfordstudies[.]com - extension install and update events
- unexpected browser extension sync behavior
- stored HTTP header history
- use of sensitive tokens inside browser extensions
- managed policies that may reinstall the extension
Organizations should also review whether developer tools and browser extensions are approved, monitored, and periodically reassessed.
Final Thoughts
ModHeader’s removal from Chrome and Edge shows how fragile browser-extension trust can be.
The extension was popular, signed, functional, and widely installed. Yet researchers found a complete browsing-history collection pipeline hidden inside the official version.
The fact that the main collector was dormant is important.But it does not make the design harmless.
The system was already present, and an ordinary update could have activated it by changing the allow-list.
Browser extension security cannot rely only on reputation, install count, store signatures, or automated sandbox behavior. Dormant code paths, suspicious endpoints, hidden telemetry, and broad permissions need much closer review, especially in extensions that can see or modify browser traffic.
