ModHeader Malware Warning: Remove Extension 7.0.18 Safely

If Chrome or Edge disabled ModHeader or marked it as malware, leave it disabled and remove it. Researchers verified that the official, Web Store-signed Chrome 7.0.18 build contained a complete but dormant pipeline for collecting and uploading visited domains. An empty allowlist prevented that history-upload path from running in the examined build, but separate install/update telemetry was active and real request metadata was stored locally. Remove the exact extension ID, check whether sync or policy restores it, and review sensitive sessions or developer tokens according to how that browser profile was used.

Is ModHeader malware?

The safest current verdict is conditional: the official Chrome 7.0.18 build should not be trusted or restored, but the evidence does not show that every installed copy actively uploaded browsing history. Stripe OLT verified the suspicious service-worker files against Google’s Web Store content signature, which rules out the simple explanation that researchers examined an unrelated sideloaded clone [1].

Stripe OLT analyzed the live Chrome build on July 6, 2026. Microsoft removed the Edge listing on July 3, and Google removed the Chrome listing on July 10 after disclosure, according to dated reporting [2]. Direct checks on July 23 found that the Chrome URL redirects to an empty item [3] and the Edge URL returns no extension details [4]. Search caches may still show an older version or an install button, so use the direct store page rather than a cached result to judge availability.

The verified Chrome code could fingerprint a device, encrypt visited hostnames, stage up to 1,000 distinct domains, and prepare a daily POST to api.stanfordstudies.com/app/log. The hard-coded browser allowlist was empty, so the history collector returned before gathering or uploading domains in that build. Other behavior was live: install, update, and uninstall events contacted extensions-hub.com, while a content script recorded request metadata in local browser storage. Keep those facts separate from an unsupported claim that all passwords or complete browsing histories were stolen.

Which ModHeader version and IDs are involved?

Open chrome://extensions or edge://extensions, enable developer details if necessary, and compare the full 32-character ID. A similar name is not enough. The detailed signature verification cited here covers the Chrome 7.0.18 package; the Edge ID identifies the removed product listing but should not be used to claim that every Edge build was independently matched byte for byte.

The primary investigation reported about 900,000 Chrome users [1], while contemporary coverage put the combined Chrome and Edge reach near 1.6 million installations [2]. That scale describes possible exposure, not evidence that 1.6 million browsers uploaded data. This warning also should not be applied automatically to unrelated Firefox add-ons or header-testing extensions with different publishers and IDs.

Before deleting anything, note the browser profile, extension ID, version, permissions, and whether the browser says the item was installed by policy. Gridinsoft’s browser extension safety checklist explains why broad access can be legitimate for a developer tool while still creating serious privacy consequences when trust breaks.

What data may be at risk?

The dormant history pipeline targeted hostnames, not full page paths, cookies, or page content, and the investigators did not observe it uploading browsing domains from the examined build. Active telemetry was narrower: install, update, and uninstall events reported the product, version, and browser to extensions-hub.com. Separately, the all-sites content script and request observers had written real request metadata into local IndexedDB storage.

Request and response headers can contain authorization tokens, session cookies, internal hostnames, API endpoints, and other developer or account context. The examined header history remained local, which is not the same as theft, but it raises the impact of profile access, backups, shared computers, and later malware. Developers who used ModHeader on staging panels, internal dashboards, cloud consoles, CI/CD systems, or production admin pages should treat that browser profile as potentially sensitive.

How to remove ModHeader from Chrome or Edge

1. Leave the extension disabled. Do not use Developer mode to reload it and do not download an archived CRX or ZIP from a third-party extension database.
2. Record the clues. Save the extension ID, version, browser profile name, permissions, and the wording of the warning. On a work-managed browser, contact the administrator before changing policy or profile files.
3. Pause browser sync temporarily. This prevents another signed-in device or an old profile from restoring the extension while you clean it.
4. Remove ModHeader in the browser UI. Use the Remove button on chrome://extensions or edge://extensions.
5. Close every browser process. Exit Chrome or Edge completely and verify in Task Manager or Activity Monitor that background browser processes have stopped.
6. Remove only the ID-specific residual storage. Use the paths below. Do not delete the entire browser profile.
7. Restart the browser and recheck extensions. If ModHeader returns, keep sync paused and follow the returning browser extension cleanup guide for policy, sync, app, startup, and scheduled-task checks.

Remove residual ModHeader browser storage

Back up the profile before editing it, and replace <Profile> with the affected folder such as Default or Profile 1. Delete only folders whose name contains the exact ModHeader extension ID.

For Chrome on Windows, start under:

%LOCALAPPDATA%\Google\Chrome\User Data\<Profile>

For Edge on Windows, start under:

%LOCALAPPDATA%\Microsoft\Edge\User Data\<Profile>

Check these profile subfolders for the matching ID:

• Extensions\<extension-ID>
• Local Extension Settings\<extension-ID>
• Sync Extension Settings\<extension-ID>
• Managed Extension Settings\<extension-ID>
• IndexedDB\chrome-extension_<extension-ID>_0.indexeddb.leveldb

On macOS, the analyzed Chrome profile was under ~/Library/Application Support/Google/Chrome/<Profile>. The same rule applies: close the browser, keep a backup, and remove only the exact ID-specific extension and storage entries. Do not wipe all IndexedDB or the whole profile unless you intentionally want a full browser reset.

If a later antivirus scan flags a general .ldb or .log record outside the exact ModHeader ID folders, follow the Chrome LevelDB alert triage before deleting broad profile storage.

Should you change passwords or revoke sessions?

Do not assume that every password was stolen. The analyzed pipeline collected hostnames and was dormant, while the local header history remained on disk. Use a risk-based response:

• Higher priority: you used the affected profile for email administration, cloud consoles, source control, CI/CD, corporate SSO, finance, crypto, password management, or production dashboards.
• Higher priority: another person or malware had access to the browser profile, the computer was shared, or profile folders were copied into support bundles or backups.
• Lower priority: ModHeader was installed but disabled, you did not use sensitive signed-in sites in that profile, and there are no other compromise indicators.

For higher-risk profiles, sign out active sessions and rotate important credentials from a clean browser or device. Start with email and identity-provider accounts because they can reset other accounts. Developers should also revoke exposed API tokens, personal access tokens, and test credentials that may have appeared in request headers. Removing the extension does not invalidate an already copied token.

This response is narrower than a confirmed credential-stealing campaign such as StegoAd’s malicious Edge extensions. The evidence for ModHeader 7.0.18 does not establish active cookie or password theft, so avoid panic-driven resets on the same untrusted browser.

What IT teams should check across managed browsers

A store takedown reduces new installs but does not prove that every browser profile removed the extension or its data. For a managed environment, treat the exact IDs as the inventory key and separate presence, network evidence, and confirmed exposure:

• Inventory Chrome and Edge profiles. Check managed and unmanaged devices, inactive user profiles, VDI images, build machines, and shared test workstations for either exact ID. A device that no longer shows the toolbar icon may still retain extension folders or IndexedDB data.
• Remove deployment paths. Block or remove the IDs in browser management, remove any force-install entry, and verify on endpoints that policy and profile sync do not restore them.
• Review historical network records. Search DNS, proxy, firewall, and endpoint telemetry for stanfordstudies.com, extensions-hub.com, and the /app/log path. Contact with extensions-hub.com can show active extension telemetry; it is not by itself proof that the dormant domain-history upload ran.
• Protect developer and administrator secrets. Preserve relevant browser and network evidence before cleanup when an incident review is required, then revoke API keys, bearer tokens, sessions, and credentials that may have appeared in stored headers.

When a Windows malware scan is useful

A browser extension can usually be removed without treating the whole PC as infected. A full system check becomes important when ModHeader came with an unknown installer, other extensions appeared without consent, ads or redirects continue, browser policy forces the item back, or you find unfamiliar startup entries, scheduled tasks, services, proxy changes, or downloaded files.

In those cases, removing the visible extension may leave a bundled app, policy, scheduled task, or startup component that restores browser changes. Gridinsoft Anti-Malware can check the Windows system for detections, hidden files, installed bundles, startup entries, scheduled tasks, browser changes, and persistence. It cannot prove that no data was exposed or restore a session token that has already left the device.

How to choose a replacement header tool

Do not replace ModHeader by installing the first alternative promoted in a forum thread. Header tools often need broad access by design, so compare the publisher, source code, update history, permissions, privacy policy, and external connections. Prefer a tool that can limit access to specific test domains and store profiles locally. Remove it when the testing task ends, and never keep production authorization headers in a shared browser profile.

For teams, a separate testing browser profile with no personal accounts is safer than running a header-modification extension beside daily email, finance, and admin sessions. Document the approved extension ID and version so an unexpected publisher or update change is easier to detect.

FAQ

References

1. Kelly, C.; Moor, J.; Lacatusu, S.; Bryant, S. “Hidden Exfiltration Capability Discovered in a Trusted, 900,000-User Chrome Web Store Extension.” Stripe OLT Threat Research, published July 13 and updated July 17, 2026; accessed July 23, 2026. https://stripeolt.com/knowledge-hub/threat-research/chrome-extension-hidden-data-exfiltration-900k-users/
2. Khandelwal, S. “Google and Microsoft Pull ModHeader With 1.6 Million Installs After Dormant Collector Found.” The Hacker News, July 13, 2026; accessed July 23, 2026. https://thehackernews.com/2026/07/google-and-microsoft-pull-modheader.html
3. Google Chrome Web Store. “ModHeader – Modify HTTP Headers,” extension ID idgpnmonknjnojddfkpgkljpfnnfcklj; direct listing checked July 23, 2026. https://chromewebstore.google.com/detail/modheader-modify-http-hea/idgpnmonknjnojddfkpgkljpfnnfcklj
4. Microsoft Edge Add-ons. “ModHeader – Modify HTTP Headers,” extension ID opgbiafapkbbnbnjcdomjaghbckfkglc; direct listing checked July 23, 2026. https://microsoftedge.microsoft.com/addons/detail/opgbiafapkbbnbnjcdomjaghbckfkglc