Anfang Juli 2026 stufte Google ModHeader v7.0.18 als Malware ein und Microsoft nahm die Extension aus dem Edge-Store, nachdem Researcher ein verstecktes Datensammel-SDK gemeldet hatten. Das hier ist eine nüchterne Cleanup-Checkliste ohne Drama: prüfen, ob du betroffen bist, die Extension entfernen, Datenreste auf Mac und Windows löschen und absichern, worauf sie Zugriff gehabt haben könnte.
Diese Anleitung ist so geschrieben, dass sie dir hilft — egal, ob du am Ende VibeHeader nutzt oder nicht. Alle Aussagen über ModHeader weiter unten stammen von Google, Microsoft und den unabhängigen Researchern, die unter Quellen verlinkt sind — nichts davon ist unsere eigene Analyse. Wenn Chrome oder Edge die Extension bei dir schon deaktiviert hat, ist das ein klares Zeichen, dass das Cleanup unten auf dich zutrifft.
Wenig Zeit? Die wichtigsten Schritte in der richtigen Reihenfolge (Details weiter unten):
Die Extension aus Chrome und Edge entfernen.
Auf Mac oder Windows die verbliebenen Speicherordner löschen.
api.stanfordstudies.com blockieren — per DNS oder hosts-Datei.
Alle Secrets rotieren, die du dort eingefügt hast.
Was gemeldet wurde (die 60-Sekunden-Version)
Anfang Juli 2026 stufte Google ModHeader als Malware ein und deaktivierte die Extension, Microsoft entfernte sie aus dem Edge-Add-ons-Store (um den 3. Juli; das Chrome-Listing war etwa am 10. Juli offline).
Researcher berichteten, dass ModHeader-Build 7.0.18 ein verstecktes SDK enthielt — getarnt in einer Datei, die sich als Datums-Library ausgab (dayjs.min-*.js) —, das die von dir besuchten Domains sammelte, per AES-GCM verschlüsselte und einmal täglich per POST an einen Drittanbieter-Collector unter api.stanfordstudies.com/app/log schickte (eine Website mit dem Titel „Stanford Studies“, die keinerlei Verbindung zur Stanford University hat).
Gemeldete Größenordnung: rund ~900.000 Chrome-Installationen plus ~700.000 auf Edge (zusammen ca. 1,6 Mio.). Manche Berichte nennen nur die ~800.000er-Zahl für Chrome.
Wichtige Nuance: Laut den Researchern wurde der Collector im Ruhezustand hinter einer leeren Allowlist ausgeliefert — in ihren Tests wurde also nichts nach außen gesendet —, aber Endpoint, Key und Scheduler waren komplett vorhanden und hätten durch ein späteres Update aktiviert werden können. Das Ganze ist daher als ernstes Expositionsrisiko einzuordnen, nicht als bestätigter Massen-Leak.
Wenn ModHeader bei dir noch installiert ist, lautet die allgemein empfohlene Maßnahme: entfernen. So machst du das sauber.
Schritt 1 — Prüfen, ob du betroffen bist
Öffne chrome://extensions (und edge://extensions, falls du Edge nutzt) und aktiviere den Entwicklermodus, damit die Versionsnummern angezeigt werden.
Name: ModHeader — Modify HTTP headers
Extension-ID:idgpnmonknjnojddfkpgkljpfnnfcklj
Betroffene Version:7.0.18 (wenn du diesen Build hast, behandle dich als betroffen)
Zeigt der Chrome-Sicherheitscheck bereits „Diese Erweiterung enthält Malware“, bist du hier richtig — klick die Warnung nicht einfach weg, sondern zieh das Cleanup unten komplett durch. So sieht die Warnung aus:
Chromes Sicherheitscheck stuft ModHeader als Malware ein und empfiehlt die Entfernung.
Hat der Browser die Extension bereits deaktiviert, lass sie deaktiviert und klicke trotzdem auf Entfernen — Deaktivieren stoppt nur die Ausführung, die gecachten Daten bleiben erhalten.
Führe das in jedem Browser-Profil durch, in dem die Extension installiert war (jedes Chrome-Profil ist eigenständig).
Schritt 3 — Verbliebene lokale Daten löschen
Die Deinstallation räumt normalerweise das meiste weg, aber die gecachten Daten der Extension — laut Researchern konnten das deutlich über 100 MB an gespeicherten Request-/Response-Headern sein, potenziell inklusive Tokens und Cookies — können zurückbleiben. Lösche zur Sicherheit alle der folgenden Ordner, die noch existieren. Ersetze Default durch deinen tatsächlichen Profilordner (prüfe auch Profile 1, Profile 2, …).
macOS
Unter ~/Library/Application Support/Google/Chrome/ (bei Edge entsprechend unter Microsoft Edge):
Beende den Browser vollständig, bevor du diese Ordner löschst — sonst sind die Dateien womöglich gesperrt.
💡 Tipp: Überlass den Sweep einem Coding-Agent. Wenn du einen Coding-Agent wie Claude Code oder Codex nutzt, füge einfach die URL dieser Anleitung (oder die Ordnerliste oben) ein und lass ihn die verbliebenen ModHeader-Ordner über alle deine Browser-Profile hinweg aufspüren und entfernen — besonders praktisch, wenn du mehrere Profile hast und Angst hast, eines zu übersehen. Zwei Sicherheitshinweise: Browser vorher komplett beenden, und lass den Agent erst auflisten, was er gefunden hat, und auf deine Bestätigung warten, bevor er irgendetwas löscht.
Schritt 4 — Exfiltrations-Domain blockieren
Blockiere und protokolliere den Collector, damit ihn nichts mehr erreichen kann — auch keine übrig gebliebene gecachte Kopie:
Einzelpersonen: Trage 0.0.0.0 api.stanfordstudies.com in deine hosts-Datei ein (/etc/hosts unter macOS/Linux, C:\Windows\System32\drivers\etc\hosts unter Windows) oder blockiere die Domain in deinem DNS-Resolver / Pi-hole.
Teams: Nimm api.stanfordstudies.com (und die übergeordnete Domain stanfordstudies.com) in eure DNS-Blockliste / Egress-Firewall auf und durchsucht Proxy- und DNS-Logs nach historischen POST /app/log-Requests an diesen Host.
Schritt 5 — Alles Sensible rotieren, was du der Extension gegeben hast
Da die Extension die Header lesen und speichern konnte, die durch deinen Browser liefen, behandle alles, was du regelmäßig dort eingefügt hast, als potenziell exponiert und stelle es neu aus:
Authorization- / Bearer-Tokens und API-Keys aus deinen Header-Configs.
Session-Cookies, die du zum Testen über Header gesetzt hast.
Alle internen Hostnamen oder Staging-Credentials, die in deinen Header-Sets vorkamen.
Angesichts des gemeldeten Ruhezustands ist das eine Vorsichtsmaßnahme — aber ein Token zu rotieren ist eine billige Versicherung, verglichen mit der Annahme, dass schon alles gut geht.
Indicators of Compromise (für Security- / IT-Teams)
Sucht auf verwalteten Endpoints nach den folgenden Indikatoren. Am stärksten belegt sind Extension-ID, Version, Exfil-Endpoint und der getarnte Dateiname; mit (laut Bericht) markierte Einträge stammen aus dem ursprünglichen Reverse-Engineering-Write-up und sind der Vollständigkeit halber aufgeführt.
Typ
Indikator
Extension-ID
idgpnmonknjnojddfkpgkljpfnnfcklj
Version
7.0.18
Netzwerk (Exfil)
ausgehender POST an api.stanfordstudies.com/app/log
Domain
api.stanfordstudies.com, stanfordstudies.com
Getarnte Datei
dayjs.min-*.js (Datensammel-SDK)
Zugehörige Datei (laut Bericht)
background-94ad634d.js
Hartkodierter AES-Key (laut Bericht)
aWfU3yG_wksZaQdSnxPJBOId0cAN8KK/UIlZbli7-bE
Fingerprint-Salt (laut Bericht)
mod盐header
Gemeldetes Verhalten: Sammlung nur der Domains (keine vollständigen URLs, keine Cookie-Werte, keine Passwörter), AES-GCM-Verschlüsselung, ein gebündelter Upload pro Tag mit pro Gerät randomisiertem Zeitplan, keine Remote-Code-Ausführung und kein Nachladen externer Scripts.
FAQ
Wurden meine Browserdaten tatsächlich gestohlen?
Laut den Researchern, die Build 7.0.18 reverse-engineert haben, wurde der Collector im Ruhezustand hinter einer leeren Allowlist ausgeliefert — in ihrer Testumgebung wurde also nichts nach außen gesendet. Endpoint, Key und Scheduler waren aber vorhanden, ein späteres Update hätte alles aktivieren können. Behandle es als reales Expositionsrisiko, nicht als bestätigten Leak: Extension entfernen, Daten löschen und die Secrets rotieren, die du dort eingefügt hast.
Chrome hat die Extension schon deaktiviert — bin ich damit fertig?
Nicht ganz. Deaktivieren stoppt nur die Ausführung, löscht aber nicht die lokal gecachten Daten (laut Berichten deutlich über 100 MB an gespeicherten Headern, Tokens und Cookies). Entferne sie vollständig und lösche die verbliebenen Speicherordner aus Schritt 3.
Welche Version war betroffen?
Researcher haben das versteckte SDK dem Build 7.0.18 zugeordnet (ID idgpnmonknjnojddfkpgkljpfnnfcklj). Google stufte die Extension Anfang Juli 2026 als Malware ein und deaktivierte sie, Microsoft entfernte sie aus dem Edge-Store.
Was soll ich stattdessen nutzen?
Wähle einen Header-Editor, der leichtgewichtig, MV3-nativ und werbefrei ist, keine Analytics einsetzt und nur die wirklich nötigen Berechtigungen anfordert. VibeHeader ist genau so gebaut (und wird gerade Open Source gestellt, damit der Code auditierbar ist); Requestly und Header Editor (englisch) sind weitere gepflegte Optionen für schwerere Rule-Engines.
Falls du einen Header-Editor als Ersatz brauchst
Zum Testen wirst du weiterhin Header ändern müssen — die eigentliche Frage ist also, wem du als Nächstes vertraust. Die Checkliste, die zählt: ein kleiner, fokussierter Funktionsumfang; Manifest-V3-nativ; keine Werbung und keine Analytics; Berechtigungen, die man wirklich nachvollziehen kann; und ein Sharing-Modell, das deine Configs nicht über fremde Server leitet.
VibeHeader wurde genau nach dieser Spezifikation gebaut: keine Werbung, kein Tracking, und linkbasiertes Teilen, das die Config im URL-Fragment (#c=) codiert — sie wird in deinem Browser verarbeitet und nichts wird an einen Server gesendet. Außerdem wird der Code gerade Open Source gestellt, du musst uns also nicht einfach glauben. Die ganze Geschichte und weitere gepflegte Optionen findest du im Bericht des Gründers (englisch) und im Vergleich der ModHeader-Alternativen (englisch).
VibeHeader: ein fokussierter Header-Editor mit Ein-Klick-Link-Sharing, ohne Werbung und ohne Analytics.
Alle Aussagen über ModHeader auf dieser Seite sind Google, Microsoft und den oben verlinkten Researchern zugeschrieben. Mit „(laut Bericht)“ markierte Indikatoren stammen aus dem HackIndex-Write-up und wurden von uns nicht unabhängig verifiziert.
