About 1.6 million users had ModHeader installed across Chrome and Edge when researchers found a hidden browsing‑history collector embedded in the official store build — a collector that, fortunately, remained dormant because an internal allow‑list shipped empty.
Stripe OLT's analysis and confirmation
UK security firm Stripe OLT examined ModHeader's Chrome build and matched the code to Google's Web Store signature, confirming the collector was present inside the genuine extension rather than a counterfeit. The firm's review covered the Chrome build and its roughly 900,000 users; third‑party trackers estimate another 700,000 installs on Edge. Microsoft pulled the Edge listing on July 3, and Google removed the Chrome listing on July 10.
Stripe OLT's teardown — corroborated by separate analyses from HackIndex (version 7.0.18) and researcher Yunus Aydin (version 7.0.17) — found that the extension still edits HTTP headers as advertised, but also contains a second, minified background system that implements the collector pipeline.
How the dormant collector was built to operate
On first run the minified code builds a device fingerprint and loads a hardcoded encryption key. As a user browses, the extension takes the domain from each page, encrypts it, and stores it locally, up to 1,000 distinct domains. A scheduler bundles the encrypted list with the fingerprint once a day, posts it to api.stanfordstudies[.]com, and then wipes the local copy. The upload time is offset per install so installs would not beacon all at once if the collector were switched on.
Critically, the collector runs only when the browser matches an entry on an internal allow‑list — and that list ships empty. The check therefore fails every time and the pipeline stops before it collects a single domain. The analysis notes that populating that allow‑list is a small change, requires no new permissions, and would not require any click from a user: the hardcoded key, endpoint URL, scheduler and storage logic are already present on a machine running the extension.
Not everything in the build was dormant: on install, update and uninstall the extension pinged a second domain, extensions‑hub[.]com, with the product, version and browser. A page‑running script had already logged real request metadata to local storage in plain text, and the extension's header‑history feature was found storing full HTTP headers on disk.
Where the domains lead and what signals were visible
Stripe OLT tied the endpoints to real infrastructure. The domain stanfordstudies[.]com has no link to Stanford; it is a repurposed old domain fronting an OpenSearch back end. extensions‑hub[.]com is set up for advertising. At the time of analysis the two API endpoints resolved to the same Amazon server, consistent with a single operator but not proving it.
The researchers highlight a handful of weak signals pointing toward a Chinese‑speaking operator — a Simplified Chinese locale, a "salt" marker using the character 盐, and a China‑origin mail provider — but they name no group, and Stripe OLT made no attribution claim.
Responses, containment steps, and recommended mitigations
- Market takedowns: Microsoft removed the Edge listing on July 3; Google removed the Chrome listing on July 10.
- User actions: If you have ModHeader, remove it from Chrome and Edge; your browser may have disabled it already. Uninstalling clears its stored data, but check whether profile sync or a managed extension policy could reinstall it.
- Secrets and keys: If you pasted API keys, bearer tokens or session cookies into the extension, rotate them — researchers found full HTTP headers were written to disk by the header‑history feature.
- Defender guidance: Block and log stanfordstudies[.]com and extensions‑hub[.]com at DNS and proxy, and search logs for the extension ID idgpnmonknjnojddfkpgkljpfnnfcklj and any POST to api.stanfordstudies[.]com/app/log. Stripe OLT published ready‑to‑run KQL hunting queries for Defender and Sentinel to assist enterprise hunts.
- Communications: The developer had not responded publicly as of publication; The Hacker News has contacted ModHeader for comment and put questions to Stripe OLT.
What this means for technologists, defenders, and end users
Technologists and security teams should watch for dormant code paths and minified malicious payloads embedded in otherwise legitimate codebases: the collector was encrypted, gated, and minified precisely to frustrate automated scanners. Defenders and enterprise IT are advised to implement the recommended blocks and hunts now — Stripe OLT supplied KQL queries and precise indicators, including the extension ID and upload endpoint. End users should remove the extension, verify it is not being reinstalled by sync or managed policy, and rotate any secrets that may have been pasted into the tool.
The sharp takeaway from the analysis is narrow and concrete: a store‑verified, signed extension used by a large user base contained a complete collector designed to switch on via a routine update, yet it remained hidden from automated scanners because its upload was gated and its payload encrypted. Extension review and enterprise hunting should now include checks for dormant paths, new call‑home endpoints, and empty or remotely updateable allow‑lists — the precise mechanisms Stripe OLT found in ModHeader's official build.
