ModHeader Extension Pulled After Hidden Domain Collector Found

Google and Microsoft have pulled or flagged ModHeader, a widely used browser extension for changing HTTP headers, after researchers found a hidden domain-history collector inside the extension code. The most important detail for users is the nuance: the collector was present and ready to run, but the analyzed build kept it dormant behind an empty allowlist. That makes this a serious cleanup issue, not proof that every install leaked browsing history.

The Hacker News reported on July 13, 2026 that the extension had roughly 1.6 million installs across Chrome and Edge before the store action. A separate HackIndex teardown of ModHeader version 7.0.18 describes code that could collect visited domains, encrypt them, and post them to api.stanfordstudies[.]com/app/log.

Why this matters

Header-editing extensions need broad browser permissions to do their job. That is useful for developers and testers, but it also means a bad update can sit very close to sensitive browsing activity, cookies, authentication headers, and internal web apps. The risk is similar to other recent browser-extension incidents, including clipboard-stealing extensions, StegoAd Edge extensions, and SearchJack search-hijacking extensions.

This is also different from a normal scareware pop-up or browser notification scam. If ModHeader was installed, the concern is not a page asking for permission; it is code already running inside a trusted extension profile.

What researchers found

• Chrome extension ID: idgpnmonknjnojddfkpgkljpfnnfcklj.
• Edge extension ID: opgbiafapkbbnbnjcdomjaghbckfkglc.
• Hidden collection path: the technical teardown says helper code was disguised inside a dayjs.min-* JavaScript file rather than belonging to the extension’s normal header-editing feature.
• Data targeted: visited domain names, a browser fingerprint, and browser type. The reported collector stored domains locally, encrypted them, and had upload logic for api.stanfordstudies[.]com.
• Dormant gate: the checked build used an empty internal allowlist, so the upload path did not fire in that analysis. A later update could have changed that without asking for new permissions.
• Adware behavior: the same research describes unwanted ad-tab behavior tied to extensions-hub[.]com.

Quick check for Chrome and Edge users

1. Open chrome://extensions or edge://extensions and enable Developer mode so extension IDs are visible.
2. Look for ModHeader – Modify HTTP headers, especially version 7.0.18 or either extension ID listed above.
3. If it is present or disabled by the browser, remove it from every browser profile. Disabling is not the same as cleaning up leftover extension storage.
4. If you used ModHeader with API tokens, session cookies, bearer tokens, internal headers, or admin systems, rotate those secrets. The public evidence does not prove theft from every install, but the permission scope justifies treating sensitive pasted headers as exposed.
5. Review other extensions with <all_urls>, request-header, webRequest, or scripting permissions. Remove tools you no longer use.
6. On managed machines, block or log stanfordstudies[.]com and extensions-hub[.]com while checking browser-extension inventory.

Takeaway

Do not panic over claims of a confirmed mass leak, but do not keep the extension installed either. A dormant collector inside a trusted browser extension is enough reason to remove it, clear leftovers where practical, rotate sensitive headers, and replace it only with a tool you actively trust.