ModHeader HTTP header editor found with dormant data exfiltration code

Google and Microsoft have removed the popular HTTP header editing tool ModHeader (around 1.6 million installations on Chrome and Edge) from their extension stores after researchers discovered a hidden browsing history collection mechanism in its code. According to the researchers, the mechanism was inactive — the internal allowlist was shipped empty, and no evidence of actual data exfiltration was found. However, the entire exfiltration infrastructure — encryption, endpoint, scheduler — was already present in the signed and verified extension, ready to be activated by a routine update without requesting any additional permissions from the user. Users are advised to immediately remove the extension and rotate any secrets (API keys, tokens, cookies) that were entered through it.

What was found in the code

The analysis was carried out by the UK-based company Stripe OLT, which examined the extension code using the Chrome Web Store signature and confirmed that the hidden collector was present in the genuine version of the extension, not in a counterfeit. Independent analyses by HackIndex (version 7.0.18) and researcher Yunus Aydin (version 7.0.17) describe the same mechanism.

Version 7.0.18 (extension identifier idgpnmonknjnojddfkpgkljpfnnfcklj) performed its advertised function of editing headers. However, the same minified background code contained a second system with the following logic:

• On first run, it generated a digital fingerprint of the device and loaded a hard-coded encryption key.
• While pages were being viewed, it extracted the domain of each open page, encrypted it, and stored it locally — up to 1000 unique domains.
• A daily scheduler was supposed to collect the encrypted list together with the device fingerprint, send a POST request to api.stanfordstudies[.]com, and clear the local copy.
• The sending time was offset for each installation so that extensions on different machines would not contact the server simultaneously.

The key element: the collector only ran if the browser matched an entry in an internal allowlist, which was shipped empty. The check always failed, and the pipeline stopped before the first domain was collected. However, populating this list would be a minimal change, delivered via a routine update, without any new permissions and without user interaction.

Active components

Not everything was inactive. According to the researchers, on installation, update, and removal, the extension sent a request to the extensions-hub[.]com domain containing information about the product, version, and browser. In addition, the script that ran on every page was already recording metadata of real requests in local storage in cleartext — this component was functioning.

Why automatic scanners did not detect the threat

Reportedly, automatic checks rated ModHeader as a low-risk extension, some giving it up to 95 points out of 100. Each element of the architecture was designed to evade a particular type of check: the data are encrypted — the scanner sees only ciphertext; sending is blocked — the sandbox does not record outbound traffic; the malicious code is minified into a legitimate codebase; the endpoints had no malicious reputation; a signed, popular extension is treated as trusted. The store signature confirms the origin of the file, but not its behavior.

Infrastructure and context

Stripe OLT linked the domains to a real, maintained infrastructure. The domain stanfordstudies[.]com is not related to Stanford University — it is a repurposed older domain backed by an OpenSearch-based backend. The domain extensions-hub[.]com is configured for advertising purposes. At the time of the analysis, both API endpoints resolved to the same Amazon server.

ModHeader had already been drawing user complaints back in 2023 for injecting ads into search results and reportedly switched to an ad-supported model around the same time. It has not been confirmed who exactly gained control over the extension. At the same time, the official ModHeader page still claims that the extension does not collect user data — which is hard to reconcile with the presence of a built-in browsing history collector, even if dormant.

This case fits a pattern described by Brian Krebs back in 2021: popular extensions are quietly acquired and turned into data collection channels. The difference now is that the mechanism has been augmented with encryption and a gateway that hides data exfiltration from scanners.

Impact assessment

Developers and testing specialists — the primary audience for HTTP header editing tools — are at the greatest risk. This group routinely works with API keys, authorization tokens, and session cookies that are entered directly into the extension. The researchers found that the ModHeader header history feature was saving full HTTP headers to disk, which creates a risk of secret compromise even without activation of the main domain collector.

By their nature, header editing and cookie management extensions require broad permissions to function. When trust is broken, the blast radius becomes significant.

Practical recommendations

For users

• Remove ModHeader from Chrome and Edge — the browser may already have disabled it automatically.
• Make sure that profile sync or a managed extensions policy does not restore it.
• If you entered API keys, bearer tokens, or session cookies via ModHeader — rotate them immediately.

For defense teams

• Block and enable logging for the domains stanfordstudies[.]com and extensions-hub[.]com at the DNS and proxy level.
• Search your logs for the extension identifier idgpnmonknjnojddfkpgkljpfnnfcklj and for any POST requests to api.stanfordstudies[.]com/app/log.
• Stripe OLT has published ready-made KQL queries for Microsoft Defender and Sentinel to detect this activity.

Removing the extension from the stores resolves the issue for this specific tool but does not eliminate the systemic risk. This case illustrates a concrete architectural threat: a fully prepared data collector, passed through store verification, embedded in a trusted popular tool and designed to be activated via a routine update. Organizations should revisit their extension control procedures: check for dormant code execution paths, new endpoints for communicating with external servers, and capabilities that a routine update may add after a change of extension ownership.