Google and Microsoft yanked a widely used browser extension from their stores this month after security researchers uncovered a hidden mechanism that could log every website a user visited. The tool, ModHeader, once sat comfortably in the trusted category for developers who tweak HTTP headers during testing. Now it stands as a fresh example of how quickly that trust can evaporate.
The move came fast. Microsoft removed the Edge version on July 3. Google followed a week later, flagging the Chrome listing as malware. Combined, the extension had racked up about 1.6 million installs. The Hacker News first reported the details, citing analysis from Stripe OLT, a UK-based security research team.
But here’s what makes the case stick in the mind. The suspicious code wasn’t actively stealing data when researchers looked at it. An empty allow-list kept the collector switched off. One small update could have flipped the switch. And the whole package carried Google’s own Web Store signature.
Stripe OLT dissected version 7.0.18. The extension ID, idgpnmonknjnojddfkpgkljpfnnfcklj, matched the official Chrome build. Inside the minified background script sat a second system. On first launch it built a device fingerprint. As pages loaded, it grabbed each domain, encrypted it with a hardcoded key, and stored up to 1,000 entries locally. A daily scheduler would bundle the list, send it to api.stanfordstudies.com, then wipe the slate clean.
The upload never happened in the version under review. The allow-list stayed blank. Still, the pipeline existed. Ready. Signed. Approved by automated store scanners that gave the extension scores as high as 95 out of 100. Stripe OLT published its full breakdown, complete with KQL queries for defenders hunting similar artifacts in Microsoft Sentinel.
Other researchers reached the same conclusions. HackIndex and independent analyst Yunus Aydin examined nearby versions and mapped the same flow. Their work appeared on personal sites and GitHub, adding weight to the original findings. The domains resolved to the same Amazon infrastructure. One carried a faint Chinese-language marker in the code. None of the reports pinned the activity to a specific group.
ModHeader had shown warning signs before. Users complained in 2023 about injected ads. The extension reportedly shifted to an ad-supported model around that time. Its own website once promised no user data collection under the paid plan. That claim now clashes with the discovered collector, even if the collector sat dormant.
The developer has stayed silent. No public statement has appeared as of July 13. The original ModHeader site still promotes the tool, though the store pages have gone dark. Users who visit the Chrome Web Store now see a blank notice. Edge listings have vanished entirely.
Industry watchers took notice quickly. Cybersecurity professionals flooded X with links to the story within hours of publication. One post from security analyst Eric Vanderburg captured the mood. “Another reminder that extensions with broad permissions need constant scrutiny,” he wrote, attaching the report. Similar messages spread across the platform, many echoing the 1.6 million install figure.
The incident follows a pattern that has grown familiar. Popular extensions change hands. New owners slip in data collection routines. Automated review systems miss the subtle additions. Brian Krebs documented similar cases years ago, noting how some extensions quietly became botnet backdoors after acquisition. This time the code carried encryption and a gate that kept it invisible to sandbox tests.
Other recent examples add context. Earlier this year researchers caught multiple Chrome extensions harvesting data under the guise of anonymous analytics. A separate batch impersonated enterprise software to swipe session cookies. Header modification tools require elevated access by design. When that access turns against the user, the consequences multiply.
Security teams now face practical questions. Should organizations block all unsigned or infrequently audited extensions? Can store review processes catch dormant code paths that only activate after an update? The answers remain unsettled. What is clear is that the old model, trust the store badge, no longer suffices.
Users who had ModHeader installed received automatic disable notices in many cases. Google and Microsoft pushed updates that neutered the extension before full removal. Still, the advice from researchers is straightforward. Remove it. Check that profile sync or enterprise policy won’t reinstall it. If API keys or tokens passed through its interface, rotate them immediately. The extension stored full request headers on disk in plain text for its legitimate features.
Defenders can take additional steps. Block stanfordstudies.com and extensions-hub.com at the network level. Search logs for the extension ID and any outbound POST requests to the collector endpoint. Stripe OLT’s published queries make that hunt easier in environments already using Microsoft tools.
The broader lesson lands harder than any single takedown. A complete data exfiltration system sat inside a popular, signed extension for who knows how long. Store scanners missed it. The allow-list kept it quiet. One policy change could have activated collection across hundreds of thousands of browsers. And the next version of this playbook may hide even better.
Browser vendors have tightened extension policies in recent years. Manifest V3 limited some background capabilities. Google expanded its review staff. Microsoft added more behavioral checks. Yet cases like ModHeader show gaps remain. The code hid in plain sight, minified alongside legitimate header-editing logic. Its call-home domains had no prior malicious reputation.
Enterprise security teams are reassessing their extension allow lists in the wake of the news. Some now require manual approval for any tool that touches HTTP traffic. Others have turned to dedicated header modification proxies instead of browser extensions. The shift adds friction but reduces the attack surface.
Developers who relied on ModHeader are hunting replacements. Several open-source alternatives surfaced quickly on GitHub. One privacy-focused fork, posted in September 2025, gained new attention after the removal. Its creator noted on X that random ad pop-ups had driven the rewrite long before the malware report.
The speed of the response from Google and Microsoft deserves credit. They acted within days of the technical disclosure. Yet the fact that the collector reached production in the first place raises tough questions about upstream supply chain controls for browser add-ons.
Researchers continue to dig. New teardowns may reveal exactly when the collector code first appeared. Attribution efforts could link the infrastructure to known operators. For now the public picture remains incomplete. The extension is gone from the stores. The infrastructure it targeted still exists.
Security professionals will watch the next chapter closely. Will similar dormant collectors appear in other high-install extensions? Can automated analysis improve enough to catch them before they ship? The ModHeader case offers a live test of those questions. Its code was sophisticated enough to evade review. Its gate was simple enough to bypass with one update. That combination should keep extension reviewers up at night.
And the users? Many never knew the extension carried anything beyond header tweaks. They installed it for debugging APIs or bypassing test restrictions. Now they face the realization that their browsing history could have been one policy flip away from export. The incident won’t end extension use. It will, however, change how carefully many choose them.
WebProNews is an iEntry Publication