ModHeader carried a dormant collector to 1.6M installs
Stripe OLT found a browsing-history collector inside the store-signed ModHeader extension. Edge pulled it July 3; Chrome pulled it July 10. The allow-list shipped empty.
Confirmed: Google and Microsoft removed ModHeader — a header-editing developer extension with ~900,000 Chrome installs and ~700,000 Edge installs — after Stripe OLT reported a browsing-history collector shipped inside the store-signed build. Microsoft delisted on July 3, 2026. Google delisted on July 10, 2026. Confidence on the removals, the install counts, and the collector’s structure: high, per Stripe OLT’s writeup as reported by The Hacker News. Confidence on whether the collector ever exfiltrated a single domain: no evidence it did — see below.
What Stripe OLT found in versions 7.0.17 and 7.0.18
A dormant pipeline. Not runtime-injected. Not a compromised update served to a subset. Present in the code that both Google and Microsoft signed.
Shape, as reported:
- The extension observes the domains of pages the user opens, encrypts them locally, and stores up to 1,000 distinct domains.
- A scheduler runs once a day. It bundles the encrypted list with a browser fingerprint, posts the bundle to
api.stanfordstudies[.]com, and wipes the local copy. - The whole pipeline is gated on an internal allow-list. The collector runs only if the browser matches an entry on that list.
- The allow-list ships empty. Nothing matches. The pipeline never fires.
Stripe OLT verified the code against Google’s own Web Store signature — the collector was in the genuine extension, not a sideloaded copy or a tampered mirror. Extension ID as analyzed: idgpnmonknjnojddfkpgkljpfnnfcklj. Confidence: as-reported.
What we can and cannot say about impact
Can say: the mechanism to collect and exfiltrate browsing domains was present in a signed extension used by roughly 1.6 million people — many of them developers, QA engineers, red-teamers, and security researchers, because header-editing is a workflow tool. Confidence: high.
Cannot say: whether the allow-list was ever populated remotely, whether any Chrome or Edge profile matched, whether any bundle was ever posted to stanfordstudies[.]com. Stripe OLT reports no evidence that a single domain was ever collected or sent — the empty allow-list stops the pipeline before it runs. Confidence: as-reported, worth restating because “no evidence” is not “proof of no.” If you kept forensic logs of extension network activity, stanfordstudies[.]com is the domain to grep for.
Unconfirmed — treat accordingly: the developer’s intent, whether this was pushed by the original maintainer or a compromised update chain, and who registered stanfordstudies[.]com. The developer has not responded publicly as of Stripe OLT’s disclosure. No CVE has been assigned. No threat-actor attribution has been offered by either store or by Stripe OLT.
Timeline
- Versions 7.0.17 and 7.0.18 — the two builds Stripe OLT analyzed contained the collector. Confidence: as-reported.
- July 3, 2026 — Microsoft removed the extension from Edge Add-ons. Confidence: confirmed by store status.
- July 10, 2026 — Google removed the extension from the Chrome Web Store. Confidence: confirmed by store status.
- July 13, 2026 — Stripe OLT’s analysis published; The Hacker News summary runs.
The seven-day gap between the two removals is not explained in the public reporting. Unconfirmed — treat accordingly.
What the pattern rhymes with
A signed, vetted, store-hosted artifact carrying a dormant collector is the same shape as the HKUST SkillCloak result — static scanners missing repackaged skill malware in AI agent marketplaces — and the same shape as the Injective SDK npm compromise, where a legitimate publish path carried the payload. Whichever direction ModHeader’s story turns — insider, compromise, or bug that never lit — the trust boundary was the store signature, and the store signature carried the collector.
Unconfirmed — treat accordingly: whether Stripe OLT’s find will produce a formal CVE, whether either store will publish post-mortems, whether the developer surfaces. We will update when one of those lands.
What to actually do
If you or your team had ModHeader installed:
- Uninstall it now if any browser profile is still carrying the last store build. Removal from the store does not uninstall existing copies.
- Grep proxy or DNS logs for
stanfordstudies[.]comacross the retention window. If you get hits, you have a scope question the public reporting cannot answer. Confidence on the exfil domain: as-reported by Stripe OLT. - Replace it with a header-editor whose maintainer and code path you can name. There are several. This is a workflow tool, not a control plane; the switching cost is small compared to what the collector could have carried.
None of the above assumes actual exfiltration occurred. All three assume the store signature no longer means what your policy still says it means.
Sources
- The Hacker News — “Google and Microsoft Pull ModHeader With 1.6 Million Installs After Dormant Collector Found” — July 13, 2026, summarizing Stripe OLT’s analysis.
Found this useful? Share it.
