Al Black Hat USA 2026, i ricercatori hanno dimostrato che i Cascading Style Sheets (CSS) possono essere trasformati in un'arma per costringere gli agenti email basati sull'IA a leggere contenuti invisibili agli utenti umani. La tecnica ha aggirato Outlook, Gmail, Yahoo e Proton, permettendo agli agenti di esfiltrare password, token di autenticazione e indirizzi IP.
Perché il CSS è importante per la sicurezza delle email
Per anni, i fornitori di webmail si sono difesi dall'HTML malevolo rimuovendo gli script, isolando gli iframe in sandbox e limitando le azioni possibili di un messaggio. Queste misure bloccano gli attacchi classici che si basano su JavaScript o oggetti incorporati. Il CSS, tuttavia, è sempre stato considerato un codice di presentazione innocuo. I suoi selettori avanzati — selettori di attributi, container query e simili — permettono a una pagina di reagire alla struttura del DOM senza l'uso di scripting.
Le demo di Black Hat hanno dimostrato che questi selettori "innocui" possono diventare un canale laterale per la fuga di dati. Creando regole di stile che si applicano solo quando esistono determinati elementi nascosti, gli attaccanti rendono il testo invisibile all'utente, ma lo mantengono presente nella pagina renderizzata che viene analizzata da un agente IA.
Come funzionano gli attacchi
Una prova di concetto (PoC) ha inviato un'email che appariva ordinaria al destinatario. Al suo interno erano nascoste regole CSS che cambiavano il colore di un testo specifico per farlo coincidere con quello dello sfondo, mascherandolo efficacemente. Un essere umano non vedrà mai quel testo, ma un agente IA che estrae il DOM o l'albero di accessibilità non applica il filtro visivo. Quando l'agente ha elaborato l'email, ha letto il testo mascherato e lo ha trasmesso in un frammento URL — una parte di un indirizzo web che i browser normalmente ignorano durante il caricamento di una pagina.
Un'altra variante ha utilizzato l'iniezione indiretta di prompt (indirect prompt injection). L'email conteneva un token Slack nascosto. Il CSS rendeva il token invisibile all'utente ma lo manteneva nel markup. L'agente IA, addestrato a seguire le istruzioni incorporate nell'email, ha interpretato il token come un comando e lo ha inviato al server dell'attaccante.
Entrambi gli attacchi hanno avuto successo contro lo stesso gruppo di popolari fornitori, dimostrando che la vulnerabilità deriva dal modo fondamentale in cui il CSS viene renderizzato, e non dall'implementazione di una singola piattaforma.
Agenti IA vs. lettori umani
Gli esseri umani ignorano istintivamente il testo che non possono vedere; ci fidiamo del layout visivo per dirci cosa è importante. Gli agenti IA, al contrario, operano sul DOM grezzo o su un albero di accessibilità che registra ogni elemento indipendentemente dal suo stato visivo. Quando un'IA legge una pagina, non applica la regola "se non lo vedo, lo ignoro". Questa discrepanza crea un punto cieco: le pipeline di sanificazione costruite per il consumo umano non garantiscono più la sicurezza per i lettori automatizzati.
Il problema non è un nuovo difetto dell'IA. È un vecchio difetto del web — la capacità del CSS di influenzare il layout senza codice — che incontra un nuovo tipo di consumatore. Qualsiasi servizio che affida il contenuto di un'email a un assistente, un riassuntore o un classificatore basato sull'IA affronta ora il rischio che l'assistente agisca su dati che un essere umano non vedrà mai.
Chi è responsabile della difesa?
Gli attacchi sollevano una questione di competenza. I fornitori di webmail puliscono già l'HTML per proteggere gli utenti umani; i browser applicano già le stesse regole per il rendering. Eppure, nessuno di questi livelli tiene conto di un'IA a valle che analizzerà lo stesso markup. Il servizio email dovrebbe aggiungere una sanificazione CSS più profonda? I browser dovrebbero esporre un flag che segni gli elementi come "invisibili agli script"? O i fornitori di IA devono costruire filtri che scartino i nodi nascosti prima dell'elaborazione?
Ai team di sicurezza che sviluppano strumenti email basati sull'IA viene detto di sottoporre ad audit l'intera pipeline di rendering, non solo l'HTML che raggiunge la casella di posta. Ciò significa controllare il DOM dopo l'applicazione del CSS, ispezionare l'albero di accessibilità e rimuovere o contrassegnare esplicitamente qualsiasi contenuto che non sia visibile all'occhio umano.
Cosa monitorare in futuro
- Test dei fornitori – Ci si aspetta che i fornitori di IA incorporino vettori di attacco CSS reali nelle loro suite di test. Il web ha trent'anni di ricerca sulle vulnerabilità; gli agenti IA ne hanno solo pochi.
Se un assistente IA può essere ingannato per far trapelare credenziali semplicemente nascondendo il testo con il CSS, il modello di sicurezza che protegge le caselle di posta odierne non è più sufficiente. Sviluppatori, fornitori e regolatori devono considerare la pagina renderizzata — non solo l'HTML grezzo — come il confine di sicurezza per qualsiasi consumatore automatizzato. Il problema del testo nascosto ci ricorda che una tecnologia un tempo relegata al "solo styling" può diventare un condotto per il furto di dati. La prossima ondata di difese dovrà riconoscere il CSS come una potenziale superficie di attacco, non solo come un ausilio visivo.
