ModHeader Chrome Extension Exposes 900,000 Users to Potential Browsing History Theft

ModHeader version 7.0.187.0.187.0.18, a popular Chrome extension used for modifying HTTP headers, contained dormant code capable of collecting and exfiltrating browsing history data from an estimated 900,000 users, according to research disclosed on July 13, 2026.

Google removed the extension from the Chrome Web Store on Friday, July 10, following a responsible disclosure. Organizations should now identify existing installations, remove the extension from both managed and unmanaged endpoints, and investigate any historical connections to the associated infrastructure.

ModHeader Chrome Extension Exposes 900,000 Users

The Stripe OLT SOC analyzed ModHeader version 7.0.187.0.187.0.18, the publicly available build on the Web Store, on July 6. While the extension remained functional as a header-editing tool, its minified service worker contained a complete surveillance architecture.

The code included device fingerprinting, an AES-GCM encrypted domain-collection mechanism, IndexedDB staging, and a daily, jittered upload routine targeting:

• https://api.stanfordstudies.com/app/log
• https://www.extensions-hub.com/partners/

The browsing history collector extracted domains from visited URLs, encrypted them using a hardcoded AES-GCM key, and stored counts in an IndexedDB database named “temp.” A separate settings store retained a device fingerprint, an initialization vector, and scheduling information.

function onVisit(url) {
  const domain = extractDomain(url);
  const encrypted = aesGcmEncrypt(hardcodedKey, domain, aesIv);
  temp[encrypted] = (temp[encrypted] || 0) + 1;
}

The code capped storage at 1,000 distinct domains and was designed to package the encrypted browsing activity, along with a fingerprint and a browser identifier, before POSTing it to the remote endpoint.

Researchers emphasized that version 7.0.187.0.187.0.18 did not actively transmit browsing history because an empty allow-list controlled its collection trigger.

if (allowList.indexOf(currentBrowser()) === -1) {
  return;
}
collectAndMaybeUpload(tab.url);

Since the allow-list was empty, the tab-update handler exited before collecting any URLs. However, the encryption key, storage routines, upload scheduler, endpoint, retry logic, and cleanup functionality were already present in the signed release.

A future extension update could enable collection by populating the allow-list without requiring new permissions or prompting users. The extension had already acquired broad access through `<all_urls>`, webRequest, storage, alarms, and content-script injection permissions.

Meanwhile, active telemetry sent install, update, and uninstall events to extensions-hub.com. Researchers also discovered local plaintext request metadata from normal browsing sessions stored in IndexedDB, indicating that monitoring components had been executed.

The investigation confirmed that the code was distributed through the official Chrome Web Store and was not a repackaged or sideloaded clone. Chrome’s `_metadata/verified_contents.json` showed the official extension ID (idgpnmonknjnojddfkpgkljpfnnfcklj), version 7.0.187.0.187.0.18, and both the publisher and Google Web Store signatures.

The researchers recomputed content verification hashes for the service worker and content script, confirming that they matched Google-signed tree hashes. This verifies that the surveillance-related code was included in the store-distributed bundle.

Ioc

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Interact with Cyber Threats in Windows, Linux, macOS VMs to Trigger Full Attack Chain - Analyse Malware & Phishing with ANY RUN