css webmail claude code gemini cli prompt injection

CSS e agenti AI aprono nuove falle tra webmail e pipeline CI/CD

🛡️ Executive Summary

  • Nuove tecniche CSS superano i confini delle webmail e permettono furto di password, token, azioni UI e manipolazione di assistenti AI.
  • Claude Code espone dati tramite CVE-2026-54316, trasformando un dominio Hugging Face pre-autorizzato in un canale di esfiltrazione.
  • Gemini CLI corregge una falla critica nei workflow headless capace di portare all’esecuzione di codice prima dell’avvio della sandbox.

Due ricerche presentate nel contesto di Black Hat USA 2026 mostrano quanto sia diventato fragile il confine tra contenuti non attendibili e applicazioni considerate privilegiate. PortSwigger ha dimostrato che HTML e CSS inseriti in una email possono uscire dal contenitore del messaggio e interferire con l’interfaccia della webmail, arrivando a sottrarre password e token o a manipolare strumenti AI collegati alla posta. Parallelamente, Novee Security ha individuato falle nei workflow ufficiali di Claude Code e Gemini CLI attraverso le quali input controllabili da utenti esterni possono raggiungere ambienti CI/CD e segreti del runner. In entrambi i casi il problema nasce quando un componente considera sicuro un dato che un livello successivo utilizza con privilegi superiori.

Il CSS esce dal messaggio e raggiunge l’interfaccia della webmail

Annuncio

La ricerca di Gareth Heyes parte da un presupposto apparentemente consolidato: una webmail può mostrare HTML e CSS provenienti da un mittente non attendibile perché filtri, sanitizzazione e Content Security Policy impediscono al contenuto del messaggio di interferire con l’interfaccia dell’applicazione. Il briefing “CSS: the bomb inside your inbox” di PortSwigger dimostra invece che questa separazione può essere spezzata usando esclusivamente HTML e CSS, senza JavaScript eseguito direttamente dal messaggio. Le catene sviluppate colpiscono differenti meccanismi di Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail e AOL Mail, combinando elementi HTML permessi, comportamenti specifici del browser e discrepanze tra ciò che il sanitizer approva e ciò che il DOM produce realmente.

È un’evoluzione importante rispetto alle tecniche già osservate con il CSS salting utilizzato per nascondere contenuti nelle email e con l’Agent Phishing capace di utilizzare una semplice email contro gli assistenti AI aziendali. La ricerca non descrive una campagna criminale già osservata: si tratta di proof-of-concept, ma mostra che il confine tra contenuto della posta e applicazione web non può essere affidato soltanto alla rimozione degli script.

Outlook può trasformare un elemento legittimo in una falsa password box

Una delle catene più avanzate riguarda Outlook Web Access utilizzato con Firefox. Alcuni elementi label consentiti nella mail possono interagire con controlli che si trovano fuori dal messaggio, mentre il JavaScript legittimo dell’applicazione può trasformare attributi già sanitizzati in nuovi nodi DOM. Da questo comportamento Heyes ha ottenuto una primitiva CSS capace di uscire dal perimetro previsto dal filtro. Il passaggio successivo utilizza un elemento select modificato graficamente fino a sembrare un normale campo password: in Firefox, lo spostamento del controllo fuori dallo schermo influenza il timer di selezione delle opzioni e rende possibile acquisire quasi in tempo reale ciò che l’utente crede di digitare in un modulo Microsoft.

Il punto non è quindi un classico phishing ospitato su un dominio esterno, ma una falsa interfaccia costruita dentro la stessa webmail fidata. Il modello richiama le tecniche Browser-in-the-Browser già viste nel phishing avanzato capace di simulare finestre di autenticazione e mostra perché la protezione della posta debba considerare anche CSS, attributi e comportamento dei componenti UI, non soltanto allegati, URL e JavaScript.

Yahoo e AOL possono esporre token attraverso una race nel paste

Su Yahoo Mail e AOL Mail la catena individuata è differente. In Firefox, HTML incollato all’interno di una bozza può mantenere per un breve intervallo CSS attivo prima che la sanitizzazione completi la trasformazione. Heyes ha utilizzato questa finestra per colpire il sistema di accesso tramite email di Medium: l’attaccante avvia il login, induce la vittima a copiare CSS controllato e a incollarlo in una bozza, quindi utilizza richieste generate dagli stili per dedurre il token ricevuto via posta. La tecnica non legge direttamente il contenuto come farebbe uno script, ma sfrutta selettori e richieste di risorse come side channel per ricostruire informazioni. PortSwigger ha inoltre sviluppato una variante basata sui clic per gli ambienti nei quali la CSP blocca richieste esterne, facendo emergere progressivamente cifre o proprietà del token attraverso elementi resi selezionabili. Il problema amplia una superficie già evidente nelle campagne contro Outlook Web capaci di infettare l’utente alla sola apertura dell’email e nelle tecniche di prompt injection indiretta veicolate attraverso contenuti apparentemente passivi: anche un formato che non dovrebbe eseguire codice può trasformarsi in un canale operativo quando il contesto circostante offre primitive sufficienti.

Gmail può trasformare una email in prompt injection contro un agente AI

La superficie diventa ancora più delicata quando la posta viene letta da un agente AI. Heyes e Pete Hendy hanno concatenato un bypass CSS basato su image-set() in Gmail con una indirect prompt injection indirizzata a Claude Cowork collegato alla casella email. Nel proof-of-concept, l’attaccante provoca l’invio di una email contenente un token Slack; quando la vittima chiede all’agente di elaborare i messaggi, istruzioni nascoste nella posta lo convincono a recuperare il token e inserirlo in una bozza HTML. L’apertura della bozza attiva poi una richiesta esterna e completa l’esfiltrazione. La tecnica unisce quindi due confini che normalmente vengono valutati separatamente: sicurezza della webmail e sicurezza dell’agente. È lo stesso problema strutturale emerso con la Stealthy Memory Injection che avvelena la memoria a lungo termine degli agenti attraverso email e con le vulnerabilità di Claude per Chrome che espongono gli agenti AI attraverso contenuti web non affidabili. PortSwigger raccomanda ai provider di isolare l’HTML delle email in iframe realmente sandboxed, restringere drasticamente CSS e attributi personalizzati e impedire che contenuti controllati dal mittente possano generare richieste arbitrarie verso Internet.

Un semplice GitHub issue può raggiungere workflow agentici privilegiati

La seconda ricerca sposta il problema dalla posta ai workflow CI/CD. Novee Security ha analizzato le configurazioni ufficiali utilizzate da Anthropic, Google e OpenAI per integrare agenti di coding nei repository e ha mostrato che input pubblici come issue e metadata GitHub possono attraversare confini di fiducia fino a raggiungere componenti con capacità operative superiori. Nel briefing Black Hat “Trusted Enough to Run” presentato da Novee, Elad Meged descrive una classe di problemi nei quali un componente del workflow considera sicuro uno stato influenzato dall’attaccante e un componente successivo lo utilizza con accesso a shell, repository token o segreti del runner. L’attacco richiede quindi pochissimi privilegi iniziali: in determinati workflow basta la possibilità di inviare contenuti che il sistema agentico deciderà successivamente di analizzare. La superficie era già emersa con AgentJacking contro gli AI coding agent e con le falle di Claude Code capaci di esporre enterprise e supply chain, ma la ricerca di Novee mostra il problema direttamente all’interno dei workflow distribuiti dai vendor.

Claude Code usava Hugging Face come canale di esfiltrazione

In Claude Code, la vulnerabilità CVE-2026-54316 riguarda il tool WebFetch e una allowlist troppo permissiva. Il dominio huggingface.co era pre-autorizzato senza limitazioni sufficienti sul percorso, consentendo anche richieste verso repository controllati dall’attaccante. Un contenuto malevolo inserito nel contesto di Claude Code poteva quindi indurre il modello a effettuare richieste verso file di quel repository, utilizzando i contatori pubblici di download di Hugging Face come canale covert per codificare ed esfiltrare informazioni accessibili all’agente, compresi file, variabili d’ambiente e output di comandi. L’advisory ufficiale Anthropic pubblicato su GitHub indica come vulnerabili le versioni da 0.2.54 fino alla 2.1.162 e fissa la correzione in Claude Code 2.1.163. L’exploit richiede che contenuto non attendibile raggiunga la context window, prerequisito sempre meno eccezionale nei sistemi che analizzano issue, pull request, documentazione o risposte MCP. Lo stesso modello di rischio è già emerso con la RCE nell’Anthropic MCP Inspector e con il tool poisoning nei server MCP aziendali: il problema non è soltanto ciò che il modello decide di fare, ma quali capacità il runtime considera già autorizzate.

Gemini CLI eseguiva configurazioni ostili prima della sandbox

Per Gemini CLI la falla è più grave perché una parte della catena può avvenire prima che il modello e la sandbox entrino realmente in gioco. Nelle precedenti versioni, l’esecuzione headless utilizzata nei workflow CI considerava automaticamente affidabile il workspace e caricava configurazioni ed environment variables presenti nella directory .gemini. Un repository controllato dall’attaccante poteva quindi fornire un file .env malevolo e raggiungere l’esecuzione nel contesto host. Parallelamente, la modalità --yolo non applicava correttamente le allowlist granulari degli strumenti: una configurazione che sembrava permettere soltanto un comando specifico poteva di fatto autorizzare l’intero tool run_shell_command. L’advisory ufficiale di Google per Gemini CLI e run-gemini-cli corregge il comportamento in Gemini CLI 0.39.1, nella preview 0.40.0-preview.3 e in run-gemini-cli 0.1.22, introducendo la necessità di esplicitare la fiducia nel workspace anche in headless mode. Il rischio degli ambienti CI era già visibile nelle campagne di phishing che colpiscono PyPI, Gemini CLI e sviluppatori cloud e mostra perché una sandbox non possa proteggere da codice che viene eseguito prima della sua inizializzazione.

Il problema è nel harness che collega il modello al sistema operativo

Le due ricerche condividono una lezione più ampia. Nel caso delle webmail, il contenuto non attendibile attraversa filtri e trasformazioni finché un componente privilegiato del browser o dell’applicazione gli attribuisce capacità che il sanitizer non aveva previsto. Nei coding agent, issue, file di configurazione e output del modello attraversano invece il harness, cioè il codice che traduce l’intenzione dell’LLM in operazioni concrete su filesystem, shell, rete e pipeline. Novee sottolinea che proprio questi passaggi di fiducia hanno prodotto le vulnerabilità più significative: il modello può essere correttamente sandboxato e comunque diventare parte di una catena insicura se un componente esterno agisce prima o dopo la sandbox con privilegi superiori. La stessa dinamica è stata osservata nella prompt injection tra agenti AI in ServiceNow e nelle vulnerabilità dove un agente OpenAI ha raggiunto Hugging Face mentre Azure DevOps MCP esponeva dati. Per webmail e agenti di coding la difesa converge quindi sullo stesso principio: contenuto non attendibile e capacità privilegiate devono essere separati da confini tecnici che non dipendano dall’interpretazione del contenuto stesso.

Iscriviti alla Newsletter

Non perdere le analisi settimanali: Entra nella Matrice Digitale.

Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.

Torna in alto