Blog · Avviso di sicurezza · Aggiornato il 14 luglio 2026
Rimuovere il malware ModHeader e ripulire tutto ciò che ha lasciato
A inizio luglio 2026 Google ha classificato ModHeader v7.0.18 come malware e Microsoft l'ha rimosso dallo store di Edge, dopo che alcuni ricercatori avevano segnalato un SDK nascosto di raccolta dati al suo interno. Questa è una checklist pratica, senza allarmismi: verifica se sei coinvolto, rimuovilo, elimina i residui su Mac e Windows e metti in sicurezza ciò che avrebbe potuto toccare.
Questa guida è pensata per esserti utile a prescindere dal fatto che tu scelga o meno VibeHeader. Tutte le affermazioni su ModHeader riportate qui sotto sono attribuite a Google, Microsoft e ai ricercatori indipendenti linkati nelle fonti in fondo alla pagina: nessuna è una nostra analisi. Se Chrome o Edge ha già disattivato l'estensione al posto tuo, è un buon segnale che i passaggi di pulizia qui sotto ti riguardano.
Hai fretta? Le mosse essenziali sono quattro (i dettagli sotto):
Rimuovi l'estensione da Chrome ed Edge.
Elimina le sue cartelle di archiviazione residue su Mac o Windows.
Blocca api.stanfordstudies.com nel DNS o nel file hosts.
Ruota tutte le credenziali che vi hai incollato.
Cosa è successo (versione da 60 secondi)
A inizio luglio 2026 Google ha contrassegnato ModHeader come malware e l'ha disattivato, e Microsoft l'ha rimosso dallo store dei componenti aggiuntivi di Edge (intorno al 3 luglio; la scheda sul Chrome Web Store è sparita verso il 10 luglio).
I ricercatori hanno segnalato che la build 7.0.18 di ModHeader includeva un SDK nascosto — camuffato in un file che si finge una libreria di date (dayjs.min-*.js) — che raccoglieva i domini che visitavi, li cifrava con AES-GCM e li inviava con un POST una volta al giorno a un collettore di terze parti su api.stanfordstudies.com/app/log (un sito che si presenta come "Stanford Studies" ma non ha alcun legame reale con Stanford).
Portata riportata: circa 900.000 installazioni su Chrome più circa 700.000 su Edge (≈1,6 milioni in totale). Alcuni articoli citano solo il dato di circa 800.000 su Chrome.
Sfumatura importante: secondo i ricercatori il collettore è stato distribuito dormiente dietro una allowlist vuota — nei loro test non veniva inviato nulla — ma endpoint, chiave e scheduler erano già pronti e un aggiornamento futuro avrebbe potuto attivarli. È quindi più corretto parlare di un serio rischio di esposizione, non di una fuga di dati di massa confermata.
Se hai ancora ModHeader installato, la raccomandazione condivisa è rimuoverlo. Ecco come farlo per bene.
Passo 1 — Verifica se sei coinvolto
Apri chrome://extensions (e edge://extensions se usi Edge) e attiva la Modalità sviluppatore per rendere visibili i numeri di versione.
Nome: ModHeader — Modify HTTP headers
ID estensione:idgpnmonknjnojddfkpgkljpfnnfcklj
Versione segnalata:7.0.18 (se hai questa build, considerati coinvolto)
Se il Controllo di sicurezza di Chrome mostra già "Questa estensione contiene malware", sei nel posto giusto: non limitarti a chiudere l'avviso, completa tutta la pulizia qui sotto. Ecco l'avviso reale da cercare:
Il Controllo di sicurezza di Chrome segnala ModHeader come malware e ne consiglia la rimozione.
Passo 2 — Rimuovi l'estensione (Chrome ed Edge)
Vai su chrome://extensions → trova ModHeader → clicca su Rimuovi → conferma. Ripeti su edge://extensions.
Se il browser l'ha già disattivata, lasciala disattivata e clicca comunque su Rimuovi: la disattivazione ne blocca l'esecuzione, ma non elimina i dati in cache.
Ripeti l'operazione in ogni profilo del browser in cui l'avevi installata (ogni profilo di Chrome è indipendente).
Passo 3 — Elimina i dati locali residui
La disinstallazione di solito ripulisce quasi tutto, ma i dati in cache dell'estensione — che secondo i ricercatori potevano superare abbondantemente i 100 MB di header di richiesta/risposta memorizzati, potenzialmente inclusi token e cookie — a volte restano sul disco. Per andare sul sicuro, elimina le cartelle qui sotto che esistono ancora. Sostituisci Default con la cartella del tuo profilo effettivo (controlla anche Profile 1, Profile 2, …).
macOS
Sotto ~/Library/Application Support/Google/Chrome/ (per Edge, la directory equivalente sotto Microsoft Edge):
Chiudi completamente il browser prima di eliminare queste cartelle, altrimenti i file potrebbero risultare bloccati.
💡 Suggerimento: affida la scansione a un coding agent. Se usi un agente di programmazione come Claude Code o Codex, incollagli l'URL di questa guida (o l'elenco delle cartelle qui sopra) e chiedigli di individuare ed eliminare le cartelle residue di ModHeader in tutti i tuoi profili del browser — particolarmente utile quando i profili sono tanti e temi di dimenticarne uno. Due accortezze: chiudi prima completamente il browser e fatti elencare le cartelle trovate, dando la tua conferma prima che cancelli qualsiasi cosa.
Passo 4 — Blocca il dominio di esfiltrazione
Blocca il collettore e registra il traffico, così nemmeno un'eventuale copia residua in cache potrà inviare dati:
Singoli utenti: aggiungi la riga 0.0.0.0 api.stanfordstudies.com al file hosts (/etc/hosts su macOS/Linux, C:\Windows\System32\drivers\etc\hosts su Windows), oppure bloccalo nel tuo resolver DNS / Pi-hole.
Team: aggiungi api.stanfordstudies.com (e il dominio padre stanfordstudies.com) alla blocklist DNS / al firewall in uscita, e cerca nei log del proxy e del DNS eventuali POST /app/log storici verso quell'host.
Passo 5 — Ruota tutto ciò che di sensibile gli hai dato
Poiché l'estensione poteva leggere e memorizzare gli header in transito nel tuo browser, tratta come potenzialmente esposto tutto ciò che vi incollavi abitualmente e rigeneralo:
Token Authorization / Bearer e chiavi API usati nelle configurazioni di header.
Cookie di sessione impostati via header per i test.
Eventuali hostname interni o credenziali di staging presenti nei tuoi set di header.
Vista la segnalazione dello stato dormiente, si tratta di una misura precauzionale — ma ruotare un token costa molto meno che dare per scontato che sia andato tutto bene.
Indicatori di compromissione (per team di sicurezza / IT)
Cerca i seguenti indicatori sugli endpoint gestiti. Quelli più solidi sono l'ID dell'estensione, la versione, l'endpoint di esfiltrazione e il nome del file camuffato; le voci contrassegnate con (come riportato) provengono dall'articolo originale di reverse engineering e sono incluse per completezza.
Tipo
Indicatore
ID estensione
idgpnmonknjnojddfkpgkljpfnnfcklj
Versione
7.0.18
Rete (esfiltrazione)
POST in uscita verso api.stanfordstudies.com/app/log
Domini
api.stanfordstudies.com, stanfordstudies.com
File camuffato
dayjs.min-*.js (SDK di raccolta dati)
File correlato (come riportato)
background-94ad634d.js
Chiave AES hardcoded (come riportato)
aWfU3yG_wksZaQdSnxPJBOId0cAN8KK/UIlZbli7-bE
Salt del fingerprint (come riportato)
mod盐header
Comportamento riportato: raccolta dei soli domini (niente URL completi, valori dei cookie o password), cifratura AES-GCM, un upload cumulativo al giorno secondo una pianificazione randomizzata per dispositivo, nessuna esecuzione di codice remoto e nessun caricamento di script esterni.
Domande frequenti
I miei dati di navigazione sono stati davvero rubati?
Secondo i ricercatori che hanno decompilato la build 7.0.18, il collettore è stato distribuito dormiente dietro una allowlist vuota: nel loro ambiente di test non veniva inviato nulla. Ma endpoint, chiave e scheduler erano già tutti presenti, quindi un aggiornamento successivo avrebbe potuto attivarlo. Trattalo come un rischio reale di esposizione, non come una fuga confermata: rimuovilo, cancella i suoi dati e ruota le credenziali che vi hai incollato.
Chrome l'ha già disattivato: ho finito?
Non del tutto. La disattivazione ne blocca l'esecuzione ma non elimina i dati memorizzati localmente (che secondo i report potevano superare abbondantemente i 100 MB di header, token e cookie). Rimuovilo completamente ed elimina le cartelle residue come nel Passo 3.
Quale versione è coinvolta?
I ricercatori hanno attribuito l'SDK nascosto alla build 7.0.18 (ID idgpnmonknjnojddfkpgkljpfnnfcklj). A inizio luglio 2026 Google l'ha contrassegnata e disattivata e Microsoft l'ha rimossa da Edge.
Cosa usare al suo posto?
Scegli un editor di header leggero, nativo MV3, senza pubblicità, senza analytics e con permessi comprensibili a colpo d'occhio. VibeHeader è costruito così (e viene rilasciato open source perché sia verificabile); se ti serve un motore di regole più potente, guarda Requestly e Header Editor (in inglese).
Se ti serve un editor di header per sostituirlo
Per i test dovrai comunque continuare a modificare gli header — quindi la vera domanda è di chi fidarsi adesso. La checklist che conta: un set di funzioni piccolo e mirato; nativo Manifest V3; niente pubblicità e niente analytics; permessi su cui puoi davvero ragionare; e un meccanismo di condivisione che non fa passare le tue configurazioni dal server di qualcun altro.
VibeHeader è costruito esattamente su queste specifiche: niente pubblicità, niente tracciamento, e la condivisione via link codifica la configurazione nel frammento dell'URL (#c=), che viene elaborato localmente nel tuo browser — nulla viene inviato a un server. È inoltre in corso il rilascio open source, così non dovrai fidarti solo della nostra parola. Per la storia completa e le altre opzioni mantenute, vedi il racconto del fondatore (in inglese) e il confronto tra le alternative a ModHeader (in inglese).
VibeHeader: un editor di header mirato, condivisione via link con un clic, niente pubblicità né analytics.
Tutte le affermazioni su ModHeader presenti in questa pagina sono attribuite a Google, Microsoft e ai ricercatori linkati qui sopra. Gli indicatori contrassegnati con "(come riportato)" provengono dall'articolo di HackIndex e non sono stati riverificati in modo indipendente da noi.
