ModHeader Chrome Extension Exposed 900K Users — Dormant History‑Exfiltration Found

ModHeader, a widely used Chrome extension for modifying HTTP headers, shipped a signed release (version 7.0.187.0.187.0.18) that contained dormant but fully formed surveillance capabilities capable of collecting and exfiltrating browsing history from an estimated 900,000 users, researchers disclosed on July 13, 2026.

The analysis, published by the Stripe OLT SOC after a July 6 code review, found the publicly available Web Store build included a minified service worker that implemented device fingerprinting, an AES‑GCM encrypted domain-collection mechanism, IndexedDB staging, and a jittered daily upload scheduler pointing at attacker-controlled endpoints.

Although the release continued to operate as a header-editing tool for users, the service worker contained the full pipeline for data collection.

ModHeader Chrome Extension

URL domain extraction, encryption with a hardcoded AES‑GCM key, local counting and storage in an IndexedDB “temp” store, packaging of encrypted entries with a device fingerprint and browser identifier, and POSTing the bundle to endpoints.

The inspection revealed implementation details including functions that extracted domains from visited URLs, encrypted them using a static key and initialization vector, and incremented per-domain counts up to a 1,000‑domain cap, demonstrating an intent to build a compact, cumulative view of user browsing activity for exfiltration.

Crucially, the code also included retry logic, cleanup routines, and scheduling metadata; together these components indicate readiness to operate at scale if triggered.

At present, active transmission of browsing history did not occur because collection was gated by an allow‑list check that, in the signed release, was empty; the tab‑update handler exits early when the current browser is not found in the allow list.

However, researchers warned that a future update could populate the allow list server‑side or via a config change without requesting additional permissions or prompting users, enabling collection silently given the extension’s existing privileges, which include <all_urls>, webRequest, storage, alarms, and content script injection.

The team also observed telemetry activity consistent with operational monitoring: install, update, and uninstall events were being beaconed to the extensions-hub domain, and investigators found local plaintext request metadata from normal browsing sessions in IndexedDB, evidence that parts of the monitoring code had executed in some environments.

Importantly, the analysis confirmed the malicious-capable code was distributed through the official Chrome Web Store rather than through repackaged or sideloaded variants:

Chrome’s _metadata/verified_contents.json listed the official extension ID (idgpnmonknjnojddfkpgkljpfnnfcklj), version 7.0.187.0.187.0.18, and matching Google‑signed hashes;

Recomputed tree hashes for the service worker and content script matched the signatures, verifying the surveillance code was present in the store-distributed bundle. Indicators of compromise include the extension ID.

The hardcoded AES‑GCM key (aWfU3yG_wksZaQdSnxPJBOId0cAN8KK/UIlZbli7-bE), the IndexedDB artifacts (“temp” and “settings”), and the exfiltration and telemetry domains, with related infrastructure observed on a shared AWS host in us‑east‑2.

Google removed the extension from the Chrome Web Store on July 10 after responsible disclosure, and organizations are advised to identify and remove the extension from both managed and unmanaged endpoints, audit the IndexedDB artifacts for historical data, and investigate any connections to the listed infrastructure and IPs.

Repositories and SIEMs should ingest the provided IOCs, while detection efforts should look for the extension ID, suspicious POSTs to the noted endpoints, and IndexedDB entries matching encrypted domain records.