CSS nelle email: falso login su Gmail e Outlook
Il ricercatore Gareth Heyes di PortSwigger ha dimostrato a Black Hat USA che HTML e CSS presenti in una semplice email possono trasformarsi in un vettore d'attacco contro Gmail, Outlook, Yahoo Mail e altri servizi di webmail. Nessun allegato eseguibile, nessun JavaScript: le tecniche dimostrate usano solo codice di stile, in combinazione con condizioni specifiche per ciascun servizio. In questa guida spiego cosa è stato dimostrato, quali servizi sono coinvolti, cosa si sa sullo stato delle correzioni e cosa fare.
In breve
La ricerca di Gareth Heyes, pubblicata il 6 agosto 2026 e presentata a Black Hat USA, mostra che le istruzioni di stile presenti in una email — il CSS — possono essere usate per manipolare l'interfaccia delle webmail e, in scenari che richiedono condizioni specifiche, costruire false schermate di accesso o interferire con ciò che l'utente digita. La dimostrazione più impattante riguarda Outlook su Firefox: tramite label-jacking CSS il ricercatore ha simulato una falsa pagina di login Microsoft; la tecnica richiede però che l'utente interagisca con la schermata e inserisca le credenziali. Per Yahoo Mail e AOL, un proof of concept prevedeva che la vittima copiasse e incollasse contenuto CSS in una bozza, permettendo poi di ricostruire un token. Una tecnica su Gmail è stata combinata con una prompt injection contro Claude Cowork, arrivando all'esfiltrazione di un token Slack in un proof of concept che richiede condizioni multiple. Fastmail aveva già risolto due vulnerabilità prima della pubblicazione; il label-jacking di Outlook risultava ancora funzionante alla data di pubblicazione.
- Fonte primaria: ricerca originale di Gareth Heyes pubblicata da PortSwigger il 6 agosto 2026 ("CSS: the bomb inside your inbox"), presentata a Black Hat USA 2026.
- Non ho riprodotto personalmente nessuna delle tecniche descritte né verificato i proof of concept in ambienti reali: le informazioni derivano esclusivamente dalle fonti citate.
- Dato non disponibile pubblicamente: non risultano, nelle fonti consultate, prove di sfruttamento criminale attivo di queste tecniche. Si tratta di proof of concept presentati in un contesto di ricerca etica.
- Ultima verifica dell'articolo: 9 agosto 2026.
Quando si parla di email pericolose, il pensiero va subito a un allegato infetto o a un link di phishing. Questa ricerca sposta il problema un passo indietro: il vettore d'attacco è il codice di stile dell'email stessa — il CSS — che alcuni servizi di webmail non filtrano in modo sufficientemente rigoroso prima di visualizzarlo nell'interfaccia. Il risultato, in certi scenari, è che il contenuto di un messaggio visualizzato nella webmail può manipolare l'interfaccia fino a mostrare elementi che assomigliano a una pagina di login legittima, ma non lo sono. Non è fantascienza: è un proof of concept dimostrato davanti ai partecipanti di Black Hat USA 2026.
- Cos'è stato scoperto: la ricerca di Gareth Heyes
- Come funziona: HTML e CSS come vettore d'attacco
- La dimostrazione più impattante: Outlook su Firefox
- Gli altri servizi coinvolti: Yahoo, Gmail, Proton Mail
- Il collegamento con l'intelligenza artificiale
- Cosa è già stato corretto e cosa no
- Qual è il rischio reale oggi
- Cosa fare concretamente
- Cosa sappiamo
- Domande frequenti
Cos'è stato scoperto: la ricerca di Gareth Heyes
Gareth Heyes è un ricercatore di sicurezza di PortSwigger, l'azienda nota soprattutto per Burp Suite, uno degli strumenti più utilizzati dai professionisti della sicurezza web. La sua ricerca, pubblicata il 6 agosto 2026 con il titolo "CSS: the bomb inside your inbox" e presentata a Black Hat USA, analizza il modo in cui sei grandi servizi di webmail gestiscono HTML e CSS presenti nelle email ricevute.
Il problema di fondo è strutturale. Quando un servizio di webmail visualizza un messaggio nel browser, deve inserire il contenuto di quell'email all'interno della propria interfaccia — che a sua volta è costruita in HTML e CSS. Se il filtraggio del codice presente nell'email non è sufficientemente rigoroso, alcune istruzioni di stile possono "sfuggire" al contesto del messaggio e interagire con l'interfaccia della webmail stessa. Il risultato, nei casi più gravi dimostrati dalla ricerca, è la possibilità di sovrapporre elementi falsi all'interfaccia reale, intercettare input dell'utente o ricostruire informazioni sensibili come token di accesso.
Ciò che rende questa ricerca particolarmente rilevante per un utente comune — non solo per i tecnici di sicurezza — è che le tecniche dimostrate non richiedono JavaScript né allegati eseguibili. I filtri antispam e gli antivirus tradizionali sono progettati per rilevare codice malevolo e link sospetti: non necessariamente istruzioni CSS apparentemente innocue. Questo non significa che i sistemi di sicurezza siano inutili, ma che questa classe di attacchi si muove in un territorio che molti strumenti di protezione tradizionali non presiedono in modo specifico.
Come funziona: HTML e CSS come vettore d'attacco
Per capire la natura del problema vale la pena partire da una domanda semplice: cos'è il CSS in un'email?
Il CSS (Cascading Style Sheets) è il linguaggio che definisce l'aspetto visivo di una pagina web o di un messaggio HTML: colori, dimensioni, posizioni, tipografia. Un'email moderna in formato HTML può contenere istruzioni CSS per definire lo stile del testo, lo sfondo, la disposizione degli elementi. In sé, non è nulla di insolito: praticamente ogni newsletter o email commerciale contiene CSS.
Il problema nasce quando un servizio di webmail visualizza quell'email all'interno del proprio browser. L'interfaccia della webmail — la barra laterale, i pulsanti, i menu — è a sua volta una pagina web costruita in HTML e CSS. Se il servizio non isola correttamente il CSS dell'email da quello dell'interfaccia, alcune istruzioni possono "traboccare" dal contesto del messaggio e modificare l'aspetto o il comportamento dell'interfaccia che lo circonda.
Le tecniche dimostrate da Heyes seguono diverse varianti di questo principio. Alcune sfruttano regole CSS che selezionano elementi dell'interfaccia della webmail (non solo del messaggio). Altre usano la capacità del CSS di sovrapporre elementi visivi, creando layer che coprono parti dell'interfaccia reale e le sostituiscono con contenuti controllati dall'aggressore. Un'altra ancora usa funzionalità CSS normalmente innocue in modo tale da inferire informazioni dal comportamento dell'interfaccia — ad esempio ricostruendo un token di accesso attraverso l'osservazione di quali selettori CSS producono una risposta.
Il concetto chiave che vale la pena tenere a mente è questo: il pericolo, in alcuni di questi proof of concept, non è il link dentro l'email né l'allegato. È il contenuto dell'email stessa che, visualizzato nell'interfaccia web del servizio, interagisce con quell'interfaccia in modi non previsti e non desiderati.
La dimostrazione più impattante: Outlook su Firefox
La dimostrazione che ha maggiore impatto per la comprensione del rischio concreto riguarda Outlook nella versione web, su Firefox. Heyes ha costruito un'email capace di sovrapporre all'interfaccia di Outlook una falsa schermata di accesso Microsoft — visivamente indistinguibile da quella reale — e una tecnica che intercetta i caratteri digitati dall'utente nell'interfaccia.
Per essere precisi su cosa significa "intercettare i caratteri": la tecnica non installa un keylogger nel sistema operativo, non accede al clipboard e non usa JavaScript. Sfrutta invece caratteristiche del CSS per rilevare l'interazione dell'utente con certi elementi dell'interfaccia. Il risultato pratico, nel proof of concept, è che un aggressore potrebbe teoricamente ricevere le credenziali inserite dall'utente in una falsa schermata di login che lui stesso ha costruito attraverso il CSS dell'email.
Questo scenario — una falsa pagina di accesso Microsoft che appare all'interno dell'interfaccia autentica di Outlook, senza che l'URL del browser cambi — rappresenta una forma di phishing molto più difficile da riconoscere rispetto a un link che porta a un sito esterno. L'utente non esce da Outlook, non vede un URL diverso, non riceve nessun avviso dall'antivirus. La trappola è costruita all'interno dell'ambiente che l'utente considera sicuro. La tecnica richiede però che l'utente interagisca con la schermata e inserisca le credenziali: non si attiva in modo completamente passivo.
Riguardo allo stato delle correzioni: il label-jacking su Outlook risultava ancora funzionante alla data di pubblicazione della ricerca, secondo quanto dichiarato da Heyes. La ricerca non chiarisce in modo definitivo se l'intera catena di acquisizione delle credenziali fosse stata già parzialmente mitigata da Microsoft. Non risultano dichiarazioni pubbliche di Microsoft sullo stato complessivo delle correzioni nelle fonti consultate.
Gli altri servizi coinvolti: Yahoo, Gmail, Proton Mail
La ricerca non si limita a Outlook. Heyes ha analizzato sei servizi di webmail e ha trovato vulnerabilità di diversa natura e gravità in ciascuno di essi — con differenze importanti nello stato attuale delle correzioni.
Yahoo Mail e AOL. In questi due servizi — che condividono parte dell'infrastruttura — il ricercatore ha dimostrato tecniche che permettono di ricostruire un token di accesso. Il proof of concept prevedeva che la vittima copiasse e incollasse contenuto CSS in una bozza: a quel punto il token poteva essere ricostruito tramite le reazioni del CSS all'interfaccia. I token sono le credenziali temporanee che le applicazioni usano per autenticare l'utente senza richiedere la password a ogni richiesta; ottenerne uno valido può consentire accesso all'account senza conoscere la password.
Gmail. Nel caso di Gmail, la tecnica dimostrata da sola ha effetti più limitati. La sua rilevanza cresce però nel contesto del paragrafo successivo, dove viene combinata con una prompt injection contro un assistente IA collegato alla posta elettronica.
Proton Mail. Un bypass inizialmente dimostrato per Proton Mail non era più riproducibile al momento del secondo test del ricercatore. Ciò indica che Proton Mail aveva già introdotto una correzione nel periodo intercorso tra i due test, anche se non risulta una comunicazione pubblica ufficiale al riguardo nelle fonti consultate.
Fastmail. Fastmail aveva già corretto due delle vulnerabilità segnalate prima della pubblicazione. È il servizio che risulta aver risposto più rapidamente, anche se non è possibile stabilire con certezza, dalle fonti disponibili, se la segnalazione di Heyes abbia preceduto la correzione o se i bug fossero stati individuati in modo indipendente.
Il quadro complessivo mostra quindi una situazione eterogenea: alcuni servizi avevano già agito, altri mostravano problemi ancora riproducibili al momento della pubblicazione. La ricerca non descrive una singola vulnerabilità, ma una classe di tecniche che colpisce in modo diverso servizi diversi, a seconda di come ciascuno implementa il filtraggio del CSS nelle email.
Il collegamento con l'intelligenza artificiale
Uno degli scenari più interessanti — e preoccupanti — della ricerca riguarda la combinazione di una tecnica CSS su Gmail con una prompt injection contro un assistente IA collegato alla posta elettronica.
Molti servizi di posta offrono oggi funzioni basate su modelli linguistici: riassunti automatici, risposte suggerite, ricerche avanzate nella casella. Questi assistenti analizzano il contenuto delle email per produrre le loro risposte. La prompt injection — una tecnica già nota nel settore della sicurezza IA — sfrutta la difficoltà dei modelli linguistici di distinguere tra i dati che devono elaborare e le istruzioni che devono seguire.
Nel proof of concept descritto da Heyes, una tecnica CSS su Gmail è stata usata per preparare il terreno a una prompt injection contro l'assistente IA collegato alla posta. Il risultato nel test è stato l'esfiltrazione di un token Slack — ovvero un token di accesso per un servizio esterno che l'assistente potrebbe aver trovato nelle email della casella.
Questo scenario è particolarmente significativo perché combina due classi di vulnerabilità distinte — un problema di CSS nelle webmail e un problema di prompt injection nei modelli linguistici — in una catena che produce un effetto maggiore di ciascuna presa singolarmente. È importante però essere precisi sulle condizioni necessarie: la catena non si attiva in modo completamente automatico. Nel proof of concept, la vittima deve chiedere a Cowork di elaborare le email; Cowork crea poi una bozza, e la vittima deve successivamente visitare quella bozza affinché la richiesta esterna esfiltrasse il token. Non è un'esecuzione silenziosa in background: richiede che l'utente utilizzi attivamente l'assistente IA e interagisca con il risultato prodotto. Il punto rilevante non è l'automaticità, ma il fatto che nessuno dei passaggi richiede un'interazione esplicitamente sospetta: per la vittima sembra tutto normale.
È importante precisare che si tratta di un proof of concept, non di una campagna osservata. Non risultano, nelle fonti consultate, casi in cui questa catena di attacco sia stata usata in modo criminale. Ma il principio dimostrato — un'email che istruisce l'assistente IA della vittima a compiere azioni non volute — è concreto e ripetibile.
Cosa è già stato corretto e cosa no
Una delle informazioni più importanti per valutare il rischio attuale è lo stato delle correzioni al momento della pubblicazione di questa ricerca. Il quadro, come anticipato, è differenziato per servizio.
- Fastmail: due vulnerabilità corrette prima della pubblicazione. Tra i servizi analizzati, quello che ha risposto in modo più tempestivo.
- Proton Mail: il bypass specifico analizzato dal ricercatore non era più riproducibile al secondo test. La correzione sembra avvenuta nel periodo intercorso, anche se non risulta una comunicazione pubblica dedicata.
- Outlook (webmail su Firefox): il label-jacking risultava ancora funzionante alla data di pubblicazione, secondo quanto dichiarato da Heyes. La ricerca non chiarisce in modo definitivo se l'intera catena di acquisizione delle credenziali fosse già stata parzialmente mitigata da Microsoft. Non risultano dichiarazioni pubbliche di correzione nelle fonti consultate.
- Gmail: il bypass image-set() era ancora riproducibile al momento della pubblicazione. Google non ha rilasciato dichiarazioni pubbliche sullo stato della correzione nelle fonti consultate.
- Yahoo Mail e AOL: le vulnerabilità relative ai token erano ancora riproducibili al momento della pubblicazione. Non risultano dichiarazioni pubbliche di correzione nelle fonti consultate.
Questa situazione può cambiare rapidamente: le aziende di solito accelerano le correzioni dopo la pubblicazione pubblica di una ricerca, specialmente se presentata a una conferenza di sicurezza di rilievo come Black Hat. Il consiglio è di verificare eventuali comunicazioni ufficiali dai singoli servizi nei giorni successivi alla pubblicazione di questo articolo.
Qual è il rischio reale oggi
Come per qualsiasi ricerca di sicurezza presentata in un contesto accademico o professionale, è importante non sopravvalutare né sottovalutare le conclusioni. Alcune precisazioni che reputo fondamentali:
- Gmail e Outlook non sono stati "hackerati". La ricerca descrive vulnerabilità che richiedono condizioni specifiche: a seconda del proof of concept possono essere necessari una determinata webmail o browser e ulteriori interazioni dell'utente. Le app native per smartphone o desktop potrebbero non essere esposte alle stesse tecniche.
- Non risultano campagne criminali attive. Nelle fonti consultate non emergono prove di sfruttamento reale di queste tecniche da parte di aggressori. La ricerca di Heyes è una dimostrazione etica in un contesto controllato.
- Lo scenario con l'assistente IA richiede condizioni multiple. Il proof of concept che porta all'esfiltrazione del token presuppone che la vittima abbia un assistente IA collegato alla casella, che lo usi attivamente e che interagisca con la bozza generata. Non è uno scenario universale né automatico.
- I sistemi di sicurezza tradizionali potrebbero non rilevarlo. Questa classe di attacchi usa HTML e CSS, non malware, macro o codice eseguibile. Un antivirus tradizionale potrebbe non segnalare nulla di anomalo. Ciò non significa che nessun sistema di sicurezza sia in grado di rilevarlo, ma che lo strumento specifico non è quello a cui siamo abituati a pensare.
- Alcuni servizi hanno già corretto le vulnerabilità. Fastmail e, in parte, Proton Mail hanno reagito prima della pubblicazione. Le correzioni per gli altri servizi potrebbero arrivare nelle prossime settimane.
Il punto che mi sembra più rilevante per un utente comune non è il rischio immediato di essere colpiti oggi — che resta limitato, date le condizioni necessarie — ma il principio che emerge: le email HTML non sono ambienti neutri, e il CSS che contengono può interagire con l'interfaccia della webmail in modi che non ci aspettiamo. Questo vale indipendentemente dalle specifiche tecniche dimostrate da Heyes, e probabilmente continuerà a valere anche quando queste specifiche vulnerabilità saranno corrette.
Cosa fare concretamente
Non esiste una contromisura singola che elimini il rischio in modo definitivo, perché il problema nasce dall'interazione tra le email HTML e l'infrastruttura delle webmail — un'area su cui l'utente finale ha controllo limitato. Ci sono però alcune scelte che riducono l'esposizione in modo significativo.
- Preferisci l'app nativa alla webmail per la posta di lavoro o sensibile. I client email nativi (Outlook per Windows o Mac, l'app Gmail su Android o iOS) usano motori di rendering diversi dalla webmail nel browser e potrebbero non essere esposti alle stesse tecniche. Non c'è una garanzia assoluta, ma riduce la superficie d'attacco specifica dimostrata da questa ricerca.
- Disabilita la visualizzazione delle email in formato HTML se il tuo client lo permette. La modalità solo testo elimina alla radice la possibilità che CSS o HTML presenti in un messaggio interagiscano con l'interfaccia. È un compromesso in termini di usabilità, ma il più efficace disponibile all'utente finale.
- Se compare una schermata di login mentre leggi un'email, non inserire nulla. Questa è la regola più importante. Una falsa schermata costruita via CSS appare all'interno dell'interfaccia autentica della webmail: l'URL del browser può restare identico a quello del servizio legittimo. Controllare l'URL non è sufficiente. Se durante la lettura di un messaggio appare improvvisamente una richiesta di credenziali, chiudi il messaggio e apri il servizio direttamente in una nuova scheda, digitando l'indirizzo o usando un segnalibro verificato.
- Rivedi le integrazioni tra la tua casella di posta e gli assistenti IA. Se hai collegato un assistente IA alla casella di posta, verifica quali autorizzazioni ha e a quali servizi esterni può accedere. Riduci le autorizzazioni al minimo necessario.
- Mantieni attiva l'autenticazione a due fattori su tutti gli account di posta e sui servizi collegati. La 2FA resta una protezione fondamentale contro il furto delle credenziali. Va però precisato che un token di sessione già valido può in alcuni scenari consentire accesso senza ripetere password e secondo fattore: la 2FA non garantisce protezione dall'abuso di un token già ottenuto, ma riduce significativamente il rischio nelle fasi precedenti.
- Tieni d'occhio le comunicazioni ufficiali dei servizi che usi. Nei giorni successivi alla pubblicazione di questa ricerca, Gmail, Outlook, Yahoo e AOL potrebbero rilasciare aggiornamenti o dichiarazioni. Seguire i blog di sicurezza ufficiali dei servizi che utilizzi ti permette di sapere quando una correzione viene distribuita.
Cosa sappiamo
- Ricerca originale di Gareth Heyes — PortSwigger — "CSS: the bomb inside your inbox", analisi tecnica completa con proof of concept
Domande frequenti
La posta elettronica è uno dei pochi strumenti digitali che usiamo ogni giorno senza mettere in discussione il fatto che il suo contenuto sia, per definizione, materiale proveniente dall'esterno. Questa ricerca ricorda che anche ciò che consideriamo "solo grafica" — i colori, i caratteri, la disposizione di un'email — può essere usato in modi che vanno oltre l'aspetto visivo. Non è un motivo per smettere di usare la posta elettronica. È un motivo per capire meglio come funziona. Segui ScelgoIo per restare aggiornato sui rischi concreti, senza allarmismo.
E tu: usi la webmail nel browser o preferisci l'app nativa? Lo scenario descritto in questo articolo cambia qualcosa nel modo in cui gestisci la posta? Scrivilo nei commenti.
Autore: Rocco Caiazza – Fondatore di ScelgoIo
