A Black Hat USA 2026 il ricercatore di PortSwigger Gareth Heyes ha presentato una raccolta di tecniche che sfruttano il CSS per rompere il confine di sicurezza tra il contenuto di un’email e l’interfaccia della webmail che lo visualizza. Il lavoro, intitolato “CSS: the bomb inside your inbox”, dimostra catene di attacco funzionanti contro Outlook, Gmail, Yahoo Mail, AOL Mail, Fastmail e Proton Mail, capaci di catturare password, rubare token di sessione, dirottare azioni dell’interfaccia e persino manipolare gli assistenti AI collegati alla casella di posta.
Per chi amministra sistemi di posta aziendali, gestisce client webmail personalizzati o integra connettori email in strumenti AI, si tratta di una ricerca da conoscere: non è un singolo bug da patchare, ma una classe di vulnerabilità che nasce da un problema architetturale ricorrente.
Il problema di fondo: un confine che il browser non conosce
Le webmail moderne sanificano l’HTML delle email in arrivo per impedire l’esecuzione di script, ma devono comunque permettere una quantità significativa di CSS per preservare la formattazione (colori, layout, media query per la resa su mobile). Il CSS, però, non è “innocuo” quanto sembra: può leggere lo stato del DOM, condizionare la visibilità di elementi in base a selettori d’attributo, generare richieste di rete (per immagini e font) e persino inferire il contenuto testuale di un elemento carattere per carattere.
Heyes distingue due strategie generali:
- Abuso diretto di HTML e CSS che la webmail permette esplicitamente (selettori, media query,
image-set(), elementi<label>). - Discrepanza tra sanitizer e browser: il sanificatore approva un markup ritenendolo sicuro, ma il motore di rendering o il JavaScript dell’applicazione lo trasforma in qualcosa di diverso da quanto previsto.
Entrambe le strade permettono al contenuto di un messaggio non fidato di “uscire” dal proprio confine e interferire con l’interfaccia fidata che lo circonda.
Le catene di attacco dimostrate
Outlook: un menu a tendina travestito da campo password
Nella catena più sofisticata, elementi <label> consentiti dal sanitizer vengono usati per attivare controlli esterni al messaggio. Il JavaScript applicativo di Outlook trasforma poi attributi personalizzati “sanificati” in nuovi nodi del DOM che portano con sé CSS fuori dalla lista consentita dal sanitizer, e un trucco nel parsing delle media query fornisce infine CSS arbitrario. Il risultato è un <select> mascherato visivamente da campo password: poiché Firefox azzera il timer di selezione delle opzioni (circa un secondo) quando il menu esce dallo schermo, l’attacco riesce a catturare quasi in tempo reale ciò che la vittima digita, ricostruendo una schermata di login Microsoft credibile.
Yahoo e AOL: furto di token via race condition sul copia-incolla
Su Firefox, l’HTML incollato negli appunti può mantenere per un breve istante il CSS attivo prima che il sanificatore intervenga. Nella dimostrazione, l’attaccante avvia un flusso di login via email su Medium, la vittima copia del CSS fornito dall’attaccante e lo incolla in una bozza Yahoo o AOL: le richieste generate rivelano abbastanza cifre del token di login a 12 caratteri da permettere all’attaccante di ricostruirlo e autenticarsi come la vittima.
Exfiltration via click quando CSP blocca le risorse esterne
Quando la Content Security Policy impedisce richieste verso domini esterni, il paper introduce una tecnica alternativa basata sul click: dato un token numerico visualizzato come testo nell’email, il CSS iniettato può determinare quali cifre compaiono e con quale frequenza, nascondere i link che non corrispondono e lasciare visibile solo quello corretto. Un singolo click della vittima invia cifre e frequenza al server dell’attaccante.
Quando il bersaglio è l’AI, non l’utente
La parte più rilevante per chi lavora con assistenti AI collegati alla posta è la catena su Gmail: il fallback di image-set() genera una richiesta esterna nonostante la sanificazione. Heyes e il collega Pete Hendy l’hanno incatenata a una prompt injection indiretta processata da un assistente AI collegato via connettore Gmail: dopo che l’attaccante ha innescato un’email di conferma token Slack e la vittima ha chiesto all’assistente di processare la posta, le istruzioni iniettate hanno fatto recuperare il token e inserirlo in una bozza HTML, che lo ha esposto alla semplice visualizzazione.
Una dimostrazione su Fastmail ha colpito un browser AI: pseudo-elementi CSS e opacità rendevano visibile all’utente solo testo innocuo, mentre il modello leggeva istruzioni nascoste. Quando l’utente chiedeva di tradurre il testo visibile, il prompt nascosto faceva aprire tab e codificare dati nei frammenti URL.
Cosa è stato corretto (e cosa no)
Alla data della pubblicazione della ricerca (6 agosto 2026), Fastmail aveva corretto due bug di mutazione CSS e il bypass del proxy di Proton Mail non funzionava più al retest. Il label-jacking su Outlook e il bypass image-set() su Gmail risultavano invece ancora funzionanti, e il paper non specifica se l’intera catena di cattura password su Outlook sia stata risolta. I proof-of-concept sono pubblici su repository GitHub del team PortSwigger.
Le contromisure per chi gestisce infrastrutture di posta
Le raccomandazioni della ricerca, applicabili sia a chi sviluppa client webmail sia a chi ne valuta la postura di sicurezza, si riassumono in cinque punti:
- Isolamento rigoroso: rendere l’HTML delle email in un iframe sandboxed, separato dal contesto dell’applicazione principale.
- Allowlist di caratteri per la validazione CSS, non semplici blocklist di proprietà pericolose.
- Verifica dei “CSS gadget” prima di permettere attributi personalizzati che il JavaScript applicativo potrebbe trasformare in markup non sanificato.
- Blocco di elementi
<select>e selettori pericolosi (attributo, sibling, media query complesse) nel contenuto delle email. - Prevenzione delle richieste immagine controllate dall’attaccante, con proxy per le immagini remote e allowlist di domini stretta.
Per chi integra assistenti AI con connettori email (Gmail, Outlook, Slack), vale inoltre la pena trattare ogni contenuto proveniente dalla posta come potenzialmente ostile nei confronti del modello, non solo dell’utente umano: la prompt injection indiretta via CSS dimostra che la superficie di attacco si è spostata anche sull’agente stesso.
Conclusione
Questa ricerca conferma un pattern che si ripete da anni nella sicurezza web: qualsiasi linguaggio dichiarativo abbastanza espressivo da controllare visibilità, layout e generazione di richieste di rete può essere usato per exfiltrare dati, anche senza esecuzione di JavaScript. Con l’aggiunta di assistenti AI che leggono e agiscono sulla posta, il perimetro da difendere si allarga: non basta più proteggere l’utente dalla pagina, bisogna proteggere anche il modello dal contenuto che gli viene dato in pasto.
Fonte: The Hacker News – “New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens”, ricerca originale di Gareth Heyes su PortSwigger Research.