Chrome Extension Used by 1.6 Million Users Silently Included Data Exfiltration Capabilities

A widely used browser extension, ModHeader, has been removed from the Chrome Web Store after researchers found that its signed release contained a dormant capability to collect, encrypt, and potentially upload users’ browsing-domain data.

The extension reportedly had about 1.6 million combined installations across Chrome and Microsoft Edge. ModHeader is a legitimate developer utility for modifying HTTP request and response headers.

Its broad permissions are expected for that function. However, they also give it the ability to interact with traffic and pages across all websites a user visits.

Stripeolt discovered code in ModHeader version 7.0.18 related to a browsing history collection pipeline within the extension’s background service worker.

The logic was designed to extract domains from visited URLs, encrypt them with a hardcoded AES-GCM key, and store the encrypted records in IndexedDB.

Chrome Extension for Users Data Exfiltration

The pipeline used two local data stores: a settings store for a persistent installation fingerprint, encryption initialization vector, and upload timing data, and a temp store for encrypted domain records and visit counters.

The implementation was reportedly configured to retain up to 1,000 distinct domains before forcing an upload. The code also included an outbound POST routine pointing to https://api.stanfordstudies.com/app/log.

According to StripeOlt’s analysis, the payload contained encrypted browsing data, device fingerprint information, and browser details.

The uploader was built to retry failed requests and erase locally staged domain data after a successful transmission, reducing available forensic evidence.

However, researchers stressed an important distinction: the history-collection function in the analyzed build was gated by an empty allow-list.

Because no browser identifier was included in that list, the collection and upload path did not execute in that version.

The concern is that the complete collection, encryption, storage, scheduling, and transmission framework was already in place and could be enabled via a routine extension update without requesting new permissions.

The extension also contained active telemetry functionality tied to extensions-hub.com, reporting install, update, and uninstall events.

This tracking is separate from the dormant browsing-history upload capability. However, it demonstrates that the extension was already communicating with third-party infrastructure.

Google and Microsoft have reportedly pulled ModHeader from their respective extension stores, with Microsoft’s removal occurring on July 3 and Google subsequently flagging the extension as malware.

Organizations should hunt for extension ID idgpnmonknjnojddfkpgkljpfnnfcklj, block or monitor stanfordstudies.com and extensions-hub.com, and remove the extension from managed browser environments.

Users who relied on ModHeader for API testing should also review and rotate sensitive values previously placed in custom headers, including API keys, authorization tokens, and session cookies.

Aaydinnyunus also noted that the incident exposes a long-standing browser supply chain issue: while Chrome Web Store signatures confirm an extension’s origin, they do not ensure that every capability introduced in later updates is safe.

High-permission extensions should be governed as third-party software, with allowlists, inventory monitoring, and periodic behavioral review.

Indicator of Compromise

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.