How to Remove the ModHeader Malware and Clean Up What It Left Behind

What was reported (the 60-second version)

• In early July 2026, Google flagged ModHeader as malware and disabled it, and Microsoft removed it from the Edge Add-ons store (around July 3; the Chrome listing was down by ~July 10).
• Researchers reported that ModHeader build 7.0.18 bundled a hidden SDK — hidden inside a file disguised as a date library (dayjs.min-*.js) — that collected the domains you visited, AES-GCM–encrypted them, and POSTed them once a day to a third-party collector at api.stanfordstudies.com/app/log (a site titled "Stanford Studies" with no actual link to Stanford).
• Reported scale: roughly ~900k Chrome installs plus ~700k on Edge (~1.6M combined). Some write-ups cite the ~800k Chrome figure alone.
• Important nuance: researchers said the collector shipped dormant behind an empty allowlist — so in their testing nothing was sent out — but the endpoint, key and scheduler were all present and could be switched on by a future update. So this is best treated as a serious exposure risk, not a confirmed mass leak.

If you still have ModHeader installed, the widely recommended step is to remove it. Here's how to do that cleanly.

Step 1 — Confirm whether you're affected

Open chrome://extensions (and edge://extensions if you use Edge) and turn on Developer mode so version numbers show.

• Name: ModHeader — Modify HTTP headers
• Extension ID: idgpnmonknjnojddfkpgkljpfnnfcklj
• Flagged version: 7.0.18 (if you're on this build, treat yourself as affected)

If Chrome's Safety Check already shows "This extension contains malware", you're in the right place — don't just click away the warning; finish the cleanup below. Here's the actual warning to look for:

Step 2 — Remove the extension (Chrome and Edge)

1. Go to chrome://extensions → find ModHeader → click Remove → confirm. Repeat at edge://extensions.
2. If the browser already disabled it, leave it disabled and still click Remove — disabling stops it running but does not delete its cached data.
3. Do this in every browser profile where you had it installed (each Chrome profile is separate).

Step 3 — Delete the leftover local storage

Uninstalling usually clears most of this, but the extension's cached data — which researchers reported could grow to well over 100 MB of stored request/response headers, potentially including tokens and cookies — can linger. To be thorough, delete any of these folders that still exist. Replace Default with your actual profile folder (also check Profile 1, Profile 2, …).

macOS

Under ~/Library/Application Support/Google/Chrome/ (and the Edge equivalent under Microsoft Edge):

• Default/Extensions/idgpnmonknjnojddfkpgkljpfnnfcklj
• Default/Local Extension Settings/idgpnmonknjnojddfkpgkljpfnnfcklj
• Default/Sync Extension Settings/idgpnmonknjnojddfkpgkljpfnnfcklj
• Default/IndexedDB/chrome-extension_idgpnmonknjnojddfkpgkljpfnnfcklj_0.indexeddb.leveldb

Windows

Under %LOCALAPPDATA%\Google\Chrome\User Data\ (Edge: %LOCALAPPDATA%\Microsoft\Edge\User Data\):

• Default\Extensions\idgpnmonknjnojddfkpgkljpfnnfcklj
• Default\Local Extension Settings\idgpnmonknjnojddfkpgkljpfnnfcklj
• Default\Sync Extension Settings\idgpnmonknjnojddfkpgkljpfnnfcklj
• Default\Managed Extension Settings\idgpnmonknjnojddfkpgkljpfnnfcklj
• Default\IndexedDB\chrome-extension_idgpnmonknjnojddfkpgkljpfnnfcklj_0.indexeddb.leveldb

Fully quit the browser before deleting these folders, or the files may be locked.

Step 4 — Block the exfiltration domain

Block and log the collector so nothing can reach it, even from a stray cached copy:

• Individuals: add 0.0.0.0 api.stanfordstudies.com to your hosts file (/etc/hosts on macOS/Linux, C:\Windows\System32\drivers\etc\hosts on Windows), or block it in your DNS resolver / Pi-hole.
• Teams: add api.stanfordstudies.com (and the parent stanfordstudies.com) to your DNS blocklist / egress firewall, and search proxy and DNS logs for any historical POST /app/log to that host.

Step 5 — Rotate anything sensitive you fed it

Because the extension could read and store the headers flowing through your browser, treat anything you routinely pasted into it as potentially exposed and rotate it:

• Authorization / Bearer tokens and API keys used in header configs.
• Session cookies you set via headers for testing.
• Any internal hostnames or staging credentials that lived in your header sets.

This is precautionary given the reported dormant state — but rotating a token is cheap insurance compared to assuming it's fine.

Indicators of compromise (for security / IT teams)

Hunt across managed endpoints for the following. The strongly corroborated indicators are the extension ID, version, exfil endpoint, and disguised filename; items marked (as reported) come from the original reverse-engineering write-up and are included for completeness.

Reported behavior: domain-only collection (not full URLs, not cookie values, not passwords), AES-GCM encryption, one batched upload per day on a per-device randomized schedule, and no remote-code-execution / no external script loading.

If you need a header editor to replace it

You'll still need to modify headers for testing — so the practical question is what to trust next. The checklist that matters: a small, focused feature set; Manifest V3 native; no ads and no analytics; permissions you can actually reason about; and a sharing model that doesn't route your configs through someone else's server.

VibeHeader was built to that spec: no ads, no tracking, and link-based sharing that encodes the config in the URL fragment (#c=) so it's processed in your browser and nothing is sent to a server. It's also being open-sourced, so you won't have to take our word for it. For the fuller story and other maintained options, see the founder's take and the ModHeader alternatives comparison.

No pressure — the goal of this page is to help you clean up safely, whatever you switch to.