ModHeader was flagged as malware and pulled from Edge — here's how to audit any header-editing extension before you trust it

What happened

On July 3, 2026, Microsoft removed ModHeader — a header-editing extension with roughly 1.6M combined installs across Chrome and Edge — from the Edge Add-ons store after Google flagged it as malware.

Independent security researchers who analyzed build 7.0.18 found a hidden module disguised as a date-formatting library. It was capable of collecting visited domains and preparing a daily encrypted upload to an external endpoint. To be precise about what was and wasn't confirmed: the researchers reported the collector was dormant in the build they tested, and they found no confirmed evidence of data actually leaving a test profile. Still, the capability being present at all — undisclosed, in a widely-installed dev tool — is the story.

Sources (do your own reading, don't just take my word for it):

• HackIndex — "ModHeader Malware: Inside the Chrome Spyware Google Removed"
• GridinSoft — "ModHeader Malware Warning: Remove Extension 7.0.18"
• OffSeq Threat Radar — "ModHeader removed for malware"
• Koi Security — "Is ModHeader safe?"

Why this matters beyond ModHeader

Header-editing extensions are a uniquely sensitive category. To do their job they need broad host permissions (<all_urls> or close to it) and they sit in the request/response path of literally everything you browse — including whatever internal APIs, staging environments, and authenticated sessions you're debugging. A malicious or compromised one is a bigger blast radius than almost any other extension class.

If you rely on one of these for API development, this is a good moment to actually check what yours does, not just assume it's fine because it has a lot of installs.

A quick checklist for auditing your header extension

1. Read the permissions it actually requests. Does it need <all_urls>, or could it be scoped to specific origins?
2. Check what network requests the extension itself makes — not the pages you're on, the extension's own background/service worker. chrome://extensions → enable Developer mode → inspect the service worker → Network tab.
3. Look for bundled dependencies that don't match what a header tool needs. A hidden analytics/upload module dressed up as a date library is exactly the kind of thing that hides in plain sight in a large bundle.
4. Prefer extensions where captured/stored values are visible, not hidden. If a tool captures a session token or API key from a response header, you should be able to see the actual value it captured, not just a black box confirming "captured."
5. Prefer declarativeNetRequest over raw webRequest blocking where possible — it's a narrower, more sandboxed API for attaching headers, and easier to audit.

Where I'm coming from

I maintain Header Relay, a Chrome extension in the same category (attach fixed or captured headers to requests for local/staging/internal API development). I'm not neutral here, so take the following with that in mind — but the checklist above applies to Header Relay too, and you should hold it to the same bar:

• No bundled code that talks to any external endpoint — header relay logic lives in one reviewable module, and requests are attached entirely via Chrome's declarativeNetRequest + local storage.
• Captured and fixed header values are shown in plain text in the popup and options page.
• Runtime behavior is scoped to the origins enabled in your active profile — nothing else gets touched.
• Full source and privacy policy are linked from the project site if you want to verify any of this yourself rather than trust the bullet points.

If you're migrating off ModHeader (or auditing whatever extension you currently use, header-related or not), migration is 3 steps: create a profile with your target origins, re-add any fixed headers (API keys, client IDs) as Fixed Headers, and set up Captured Headers for anything you were previously copy-pasting from responses (session tokens, trace IDs).

Full writeup with sources: https://hsblabs.github.io/header-relay/modheader-alternative

Not affiliated with ModHeader or its developers — everything above is based on the third-party research linked, published July 2026.