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 conosceLe 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 dimostrateOutlook: un menu a tendina travestito da campo passwordNella 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-incollaSu 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 esterneQuando 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’utenteLa 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 postaLe 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.ConclusioneQuesta 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.

Nessun login richiestoIl 17 luglio 2026 il team di sicurezza di WordPress ha rilasciato in silenzio, e con qualche ora di anticipo condiviso solo con i principali fornitori di infrastruttura, la patch per due vulnerabilità che insieme formano una catena di attacco particolarmente pericolosa: una SQL injection e una remote code execution non autenticata. Nessuna delle due richiede che l’attaccante possieda credenziali o interagisca con un utente reale: basta una richiesta HTTP costruita ad arte contro l’endpoint batch della REST API.Se gestisci anche un solo sito WordPress — e in Italia sono milioni, molti dei quali proprio su blog tecnici o aziendali come questo — questa è una di quelle vulnerabilità da trattare come priorità operativa immediata, non come lettura per il weekend.Le due CVE, in breveLe vulnerabilità colpiscono punti diversi della catena di elaborazione di una richiesta:CVE-2026-60137 — SQL injection. Presente da WordPress 6.8 in poi. Un input malformato riesce ad alterare una query verso il database. Severità: Alta.CVE-2026-63030 — Remote Code Execution non autenticata. Presente da WordPress 6.9 in poi, e collegata direttamente alla SQL injection precedente. Sfrutta l’endpoint batch della REST API quando il sito non utilizza una cache a oggetti persistente (persistent object cache). Severità: Critica.La combinazione delle due — nella comunità di sicurezza già ribattezzata informalmente “wp2shell” — permette a un attaccante di passare da un parametro malformato a esecuzione di codice arbitrario sul server, senza autenticazione e senza alcuna interazione da parte di amministratori o utenti.Perché la object cache fa la differenzaIl dettaglio tecnico più interessante per chi amministra WordPress è che la RCE si manifesta specificamente quando manca una cache a oggetti persistente (tipicamente basata su Redis o Memcached). Molte installazioni WordPress “di default” — senza un livello di caching applicativo esterno a PHP — si affidano a una cache in memoria che vive solo per la durata della singola richiesta: è proprio l’assenza di persistenza a lasciare aperta la finestra che l’endpoint batch della REST API sfrutta per concatenare SQL injection ed esecuzione di codice. In altre parole, i siti più “semplici”, senza uno stack di caching avanzato, sono paradossalmente più esposti di quelli con un’infrastruttura più sofisticata.La risposta di WordPressTrattandosi della classe di severità più alta prevista dal team di sicurezza di WordPress, il rilascio della patch è stato accompagnato da aggiornamento automatico forzato per la maggior parte dei siti, un meccanismo che WordPress riserva solo alle emergenze più critiche. Le versioni corrette sono:7.0.2 — release principale, corregge entrambe le vulnerabilità6.9.5 — backport, corregge entrambe le vulnerabilità6.8.6 — backport, corregge solo la SQL injection (la RCE non è presente su questo ramo)7.1 Beta 2 — corregge entrambeLe versioni precedenti alla 6.8 non risultano affette. Anche con l’aggiornamento automatico attivo, è buona norma verificare manualmente la versione installata:# Da riga di comando, con WP-CLI wp core version # Oppure dalla dashboard: Bacheca → AggiornamentiIl ruolo del WAF: difesa in profondità, non sostituto della patchCloudflare, informata in anticipo dal team WordPress, ha distribuito due regole WAF dedicate alle 17:03 UTC del 17 luglio, attive automaticamente per tutti i clienti — inclusi quelli su piano gratuito — il cui traffico passa attraverso il proxy Cloudflare:RegolaCVEAzione predefinitaWordPress – SQL InjectionCVE-2026-60137BlockWordPress – Remote Code ExecutionCVE-2026-63030BlockLa prima regola intercetta i valori dei parametri malformati prima che raggiungano WordPress; la seconda blocca le richieste dirette verso il percorso di esecuzione del codice. Insieme coprono due punti distinti della catena di attacco. Cloudflare è però esplicita su un punto che vale la pena ribadire: le regole WAF riducono l’esposizione, non sostituiscono la patch. Chi utilizza Cloudflare su piano Pro, Business o Enterprise dovrebbe verificare che il Managed Ruleset sia attivo e che non vi siano override che trasformano l’azione da “Block” a “Log” — una configurazione non rara in ambienti dove si è voluto in passato ridurre i falsi positivi.Checklist operativaPer chi amministra siti WordPress, indipendentemente dal fatto che si usi o meno Cloudflare, questi sono i passi concreti da seguire subito:Verificare la versione di WordPress su tutte le installazioni gestite (non solo quella principale — anche i sotto-siti, gli ambienti di staging e i multisite dimenticati).Forzare l’aggiornamento a 7.0.2, 6.9.5 o 6.8.6 se l’auto-update non è ancora scattato: wp core update --version=7.0.2 wp core update-dbSe dietro Cloudflare: controllare in dashboard che le due regole (ID gestito 7dfb2bd4708d4b88b9911dc0550664b6 per la RCE e 1c060d3a371549219ee290d7ed933fcc per la SQLi) siano impostate su Block, e monitorare i Security Events per richieste bloccate su questi ID.Se non si usa un WAF: valutare regole custom su ModSecurity con OWASP CRS mirate all’endpoint /wp-json/*/batch, oppure disabilitare temporaneamente il batch endpoint tramite un mu-plugin, in attesa che l’aggiornamento venga completato su tutta la flotta: <?php // mu-plugins/disable-rest-batch.php add_filter('rest_pre_dispatch', function ($result, $server, $request) { if (strpos($request->get_route(), '/batch') !== false) { return new WP_Error('batch_disabled', 'Endpoint batch temporaneamente disabilitato', ['status' => 403]); } return $result; }, 10, 3);Abilitare una object cache persistente (Redis o Memcached) come mitigazione indiretta aggiuntiva, oltre ai benefici di performance che porta comunque.Controllare i log delle ultime settimane per richieste sospette verso gli endpoint REST batch, prima di considerare l’incidente chiuso.In conclusioneQuesta vicenda è un promemoria utile su due fronti. Il primo è tecnico: un endpoint REST pensato per efficienza (il batching di più operazioni in un’unica chiamata) può diventare superficie di attacco se la validazione dei parametri non è sufficientemente rigorosa lungo tutta la catena. Il secondo è organizzativo: la differenza tra un incidente e un mancato incidente, in casi come questo, si misura in ore — quelle tra la disclosure coordinata e la disponibilità pubblica dei dettagli, durante le quali chi ha automatizzato patching e monitoraggio dorme sonni più tranquilli di chi deve intervenire manualmente su decine di installazioni.Fonte: The Cloudflare Blog.