ModHeader Extension With 1.6 Million Installs Contained Dormant Data Exfiltration Code

Google and Microsoft have removed ModHeader from their browser extension stores after researchers found dormant surveillance code inside the legitimate, signed extension. The code could collect visited domains, encrypt the records and upload them to external infrastructure if activated.

The affected Chrome release, ModHeader 7.0.18, had about 900,000 users. The Stripe OLT investigation confirmed that the surveillance-related service worker came from the official Chrome Web Store package rather than a counterfeit or sideloaded copy.

Third-party estimates placed the extension’s combined reach at approximately 1.6 million installations, including about 700,000 on Microsoft Edge. According to a report on the ModHeader removals, Microsoft pulled the Edge listing on July 3, 2026, and Google removed the Chrome listing on July 10.

What Is ModHeader?

ModHeader is a browser extension that lets developers modify HTTP request and response headers. Developers, quality-assurance teams and security professionals can use it to test APIs, troubleshoot web applications and simulate different browser or server conditions.

The extension needs broad browser permissions to perform those tasks. Version 7.0.18 could run scripts across all visited websites and observe web requests. Those permissions fit the extension’s stated purpose, but they also create significant risk if unsafe code enters an update.

ModHeader detail	Finding
Chrome extension ID	idgpnmonknjnojddfkpgkljpfnnfcklj
Analyzed Chrome version	7.0.18
Estimated Chrome users	About 900,000
Estimated Edge users	About 700,000
Combined estimated installations	About 1.6 million
Chrome Web Store removal	July 10, 2026
Edge Add-ons removal	July 3, 2026

The extension continued to perform its advertised header-editing function. Researchers found the dormant collection framework mixed into the extension’s minified background code alongside its legitimate features.

How the Dormant Collection Pipeline Worked

The suspicious code appeared in a background service worker named assets/src/background-94ad634d.js. The technical analysis of ModHeader 7.0.18 found code for device fingerprinting, domain collection, encryption, local storage, upload scheduling and external transmission.

On its first run, the framework could create a persistent device identifier based on the current timestamp. It also generated an initialization vector and imported a static AES-GCM encryption key embedded in the extension.

The pipeline was designed to perform the following actions:

1. Detect a page visit through the browser’s tab-update event.
2. Extract the domain from the visited URL.
3. Encrypt the domain with a hardcoded AES-GCM key.
4. Store the encrypted domain and visit count in IndexedDB.
5. Retain records for as many as 1,000 distinct domains.
6. Prepare an upload about once per day using a per-device time offset.
7. Send the encrypted records with a fingerprint and browser identifier.
8. Retry failed transmissions and clear staged records after a successful upload.

The intended receiver was api.stanfordstudies[.]com/app/log. Researchers said the domain has no connection to Stanford University. They found infrastructure consistent with a log-ingestion backend, although its presence does not prove that the dormant ModHeader pipeline transmitted user records.

Why Researchers Did Not Confirm Active Domain Exfiltration

The collection function checked whether the current browser appeared in an internal allow-list. That list was empty in the analyzed version, so the check always failed and stopped the function before it collected a browsing domain.

Researchers therefore found a complete data collection and transmission capability but no evidence that version 7.0.18 used it to upload browsing-domain data. This distinction separates proven behavior from potential behavior.

Component	Status in analyzed build
Device fingerprinting code	Present
AES-GCM encryption key	Present
Domain collection logic	Present but blocked by the empty allow-list
IndexedDB staging	Present
Daily upload scheduler	Present
External upload function	Present but dormant
Install, update and uninstall telemetry	Active
Local request-metadata logging	Observed as active

A routine extension update could have populated the allow-list without requesting additional permissions. Browser extensions normally update in the background, so such a change could have activated the framework without another approval prompt.

Some Tracking Functions Were Active

Although the browsing-domain upload was dormant, ModHeader communicated with extensions-hub[.]com during install, update and uninstall events. The extension reported information such as its product name, version and browser type.

Researchers also found that an all-sites content script and web-request observers had stored real request metadata in local IndexedDB records. The observed entries included requests connected to advertising, analytics and consent-management services.

This local logging does not prove that the extension transmitted complete HTTP headers or credentials to an external server. However, it increases the sensitivity of the browser data stored on affected devices and supports removing the extension.

Google and Microsoft Remove ModHeader

The signed package carried the surveillance code under Chrome extension ID idgpnmonknjnojddfkpgkljpfnnfcklj. Researchers verified the service worker against Google’s Web Store content-verification data and found that its calculated hash matched the signed record.

That verification shows that the official package contained the code. A Web Store signature confirms the package’s source and integrity, but it does not guarantee that every capability inside the package is safe.

The ModHeader investigation timeline places Microsoft’s store removal on July 3 and Google’s removal on July 10. Removing a listing prevents new official-store installations, but it may not remove existing copies from every browser profile or managed endpoint.

What Users Should Do

Users should check Chrome and Edge for the affected extension ID rather than relying only on the displayed extension name. Similar names or unrelated extensions should not automatically be treated as part of the same incident.

• Remove ModHeader from every Chrome and Edge browser profile.
• Check whether browser synchronization restores the extension.
• Do not reinstall it from archived packages or third-party extension sites.
• Clear associated browser extension data after documenting evidence needed for an investigation.
• Review sensitive headers previously entered into the extension.
• Rotate API keys, bearer tokens, session values and other secrets when exposure could create material risk.
• End active sessions linked to credentials that may have been stored in header configurations.

Users should rotate secrets from a clean browser or separate trusted device. Organizations conducting a formal investigation may want to preserve the browser profile and extension storage before removal.

Enterprise Hunting and Mitigation Steps

Security teams should search endpoint inventories, browser-management consoles and filesystem telemetry for the Chrome extension ID. Edge administrators should also review the corresponding Edge listing ID and managed extension policies.

Indicator	Context
idgpnmonknjnojddfkpgkljpfnnfcklj	ModHeader Chrome extension ID
7.0.18	Chrome version analyzed by Stripe OLT
api.stanfordstudies[.]com/app/log	Dormant upload destination
stanfordstudies[.]com	Collection infrastructure domain
extensions-hub[.]com	Active install, update and uninstall telemetry
3.147.61[.]167	Shared AWS address observed during the research
assets/src/background-94ad634d.js	Service worker containing the pipeline
settings and temp	IndexedDB stores used by the framework
mod盐header	Static marker found in the code
modhader@	Misspelled manifest author string

Network teams should review historical DNS, proxy and firewall logs for connections to the two identified domains. A connection to extensions-hub[.]com may reflect the active telemetry rather than browsing-history theft. A POST request to the specific stanfordstudies endpoint deserves higher-priority investigation.

Organizations should manage browser extensions as third-party software. A deny-by-default policy, approved extension list, continuous inventory and periodic review of high-permission add-ons can reduce exposure to unsafe updates.

FAQ