Un'unica estensione malevola, cinque assistenti AI diversi, lo stesso identico errore di progettazione. È il risultato della ricerca che Gal Weizman di Forever Security ha pubblicato il 16 settembre e che ha chiamato BragJack: un attacco dimostrativo che prende il controllo dell'agente AI integrato nel browser e gli fa eseguire le azioni dell'attaccante usando i privilegi che l'agente ha già.
I prodotti coinvolti sono Google Chrome con Gemini, Microsoft Edge con Copilot, Opera Neon, Perplexity Comet e Claude in Chrome. La ricerca ha fruttato oltre 20.000 dollari di bug bounty complessivi, da 600 dollari di Anthropic a 7.000 di Google, e due CVE: CVE-2026-0628 per Chrome, CVSS 8.8, corretta a gennaio nella build 143.0.7499.192, e CVE-2026-55945 per Edge, CVSS 4.2, corretta il 2 luglio nella 150.0.4078.48. Entrambe risultano risolte, così come i difetti segnalati agli altri tre fornitori.
Cosa è successo
Weizman descrive gli assistenti integrati nel browser come sistemi con un «cervello» e un «corpo». Il modello elabora le istruzioni e decide cosa fare; un componente privilegiato del browser esegue materialmente le azioni — apre schede, legge contenuti, cattura schermate, interagisce con i siti. Il problema, sostiene il ricercatore, è che le estensioni possono manipolare il traffico di rete e le pagine di cui quel componente privilegiato si fida.
Il grimaldello è sempre lo stesso: declarativeNetRequest (DNR), la funzionalità di Chromium che consente a un'estensione di modificare la gestione delle richieste di rete, comprese le intestazioni di risposta e la redirezione delle risorse. Su Chrome le estensioni non possono iniettare script nella pagina di Gemini né toccare direttamente il componente privilegiato chrome://glic; possono però intercettare con DNR le richieste che caricano l'applicazione web di Gemini. Indebolendo alcune intestazioni di sicurezza e sostituendo una risorsa JavaScript, Weizman ha eseguito codice dentro il contesto di Gemini e ha parlato direttamente con il componente AI privilegiato, saltando il normale flusso delle richieste. L'accesso che ne è risultato consente di leggere file locali, raggiungere contenuti web, catturare schermate e potenzialmente arrivare a fotocamera e microfono. Senza che l'utente clicchi nulla.
Sui browser agentici il salto è più ampio, perché i loro agenti non si limitano a leggere le pagine: ci agiscono. Su Perplexity Comet l'estensione dell'agente si fidava di diversi domini Perplexity, fra cui un dominio di test privo delle protezioni applicate al sito principale. Rimuovendo con DNR una redirezione verso quel dominio, il ricercatore lo ha caricato e vi ha iniettato uno script in grado di dialogare con l'agente integrato. La dimostrazione è esplicita: l'agente è stato costretto ad aprire Perplexity, riassumere le email della vittima e inviare il risultato a un altro indirizzo.
Su Microsoft Edge la difesa era più solida e sono servite due debolezze concatenate. Microsoft aveva separato l'agente in modalità «Think» e «Do» proprio per impedire che ricevesse istruzioni arbitrarie e compisse azioni nello stesso momento. Weizman ha individuato una pagina di marketing Microsoft dotata di privilegi speciali per inviare prompt all'agente e, sfruttando una race condition fra le due modalità, ha disattivato per un istante la restrizione, forzato il prompt e riabilitato la capacità di azione prima che l'agente verificasse il proprio stato. È la falla a cui Microsoft ha assegnato CVE-2026-55945.
La tecnica che tiene insieme i cinque casi Weizman la chiama Prompt Forcing, e la distingue nettamente dalla prompt injection. Nella prompt injection l'attaccante nasconde istruzioni dentro contenuti che l'agente leggerà, sperando che abbocchi. Qui l'attaccante consegna direttamente il prompt e tutte le istruzioni successive, una dopo l'altra, finché l'agente non è convinto. Non c'è aleatorietà: c'è un canale di comando.
La precondizione è che l'estensione malevola sia già installata nel browser della vittima. Da quel momento in poi non serve alcuna interazione dell'utente.
Cosa significa per le aziende italiane
Il punto più scomodo di questa ricerca non è nessuna delle due CVE, che sono già corrette da mesi. È che cinque implementazioni sviluppate in modo indipendente da cinque aziende diverse hanno sbagliato lo stesso confine di fiducia. Per vent'anni il modello di sicurezza delle estensioni si è retto su un assunto: un'estensione può fare danni dentro la pagina, non oltre. Gli agenti AI nel browser hanno spostato quel confine — ora dietro la pagina c'è un componente che legge file locali e agisce sui siti dove l'utente è autenticato — senza che l'assunto venisse rinegoziato. Le patch chiudono cinque istanze; il disallineamento architetturale resta, e la prossima istanza arriverà.
C'è poi un problema di rilevamento che merita attenzione operativa. In un attacco di questo tipo l'azione finale non è compiuta da codice malevolo: è software legittimo, aggiornato e firmato, a cui è stato detto di compiere l'attacco. Per un EDR è il browser che apre un file, è l'agente che visita la casella di posta, è una richiesta HTTPS verso un dominio del fornitore AI. Nessun binario sospetto, nessuna injection in un processo, nessun indicatore riutilizzabile. La logica di rilevamento costruita su processi e artefatti non ha molto a cui aggrapparsi.
Sul perimetro italiano concreto, il divario è evidente. Browser e assistenti AI sono stati adottati nelle PMI e negli studi professionali molto più rapidamente di quanto sia stata adottata una qualsiasi politica sulle estensioni. Nella maggior parte delle realtà sotto i 250 dipendenti il Chrome Web Store è aperto: l'utente installa il traduttore, il gestore di schede, il bloccante di pubblicità, l'estensione per le fatture, e a ciascuno concede il permesso «leggere e modificare i dati su tutti i siti web» senza che nessuno lo registri da qualche parte. Weizman stima che chiunque usasse uno dei cinque prodotti con almeno un'estensione installata fosse esposto: centinaia di milioni di utenti.
E qui sta il vero moltiplicatore: l'agente eredita le sessioni dell'utente. Non deve rubare credenziali né aggirare la MFA, perché opera dentro un browser già autenticato su Microsoft 365, sul gestionale, sul portale dei fornitori, sulla webmail. Un attaccante che ottiene il canale di comando verso l'agente non ottiene un accesso: ottiene tutti gli accessi già aperti, con azioni che dal lato server risultano compiute dall'utente legittimo.
Per i soggetti che ricadono nel perimetro NIS2 c'è una conseguenza di governance che oggi quasi nessuno ha affrontato. L'articolo 21 del decreto legislativo 138/2024 richiede politiche documentate sull'uso delle risorse ICT e sulla sicurezza delle risorse umane e degli accessi. Un agente AI con capacità di lettura dei file locali e di azione sui siti aziendali è una risorsa ICT privilegiata a tutti gli effetti, e come tale va inventariata, autorizzata e governata. Nella pratica, nella quasi totalità degli inventari che si incontrano, non compare affatto: non è un software installato, non è un servizio acquistato, è arrivato dentro un aggiornamento del browser.
Lo stesso vale sul versante GDPR. Se un agente compromesso riassume la posta di un dipendente e la inoltra altrove, la fuga riguarda dati personali di clienti, fornitori, colleghi o pazienti, e la valutazione ai sensi degli articoli 33 e 34 parte dal presupposto di sapere quali agenti avessero accesso a cosa. Senza quell'inventario non è possibile nemmeno stabilire se l'obbligo di notifica sussista, il che è un problema di accountability prima ancora che di sicurezza.
Cosa fare subito
- Verificare che tutti i browser basati su Chromium del parco macchine siano aggiornati: le due CVE sono corrette rispettivamente in Chrome 143.0.7499.192 e Edge 150.0.4078.48. Installazioni ferme a versioni precedenti sono esposte oggi, non in teoria.
- Decidere se l'agente AI nel browser serve davvero. Dove non serve, disattivarlo via policy aziendale (Chrome Enterprise, criteri di gruppo o Intune per Edge). È la mitigazione più efficace, perché rimuove il bersaglio invece di difenderlo.
- Passare le estensioni a un modello di lista di consenso:
ExtensionInstallAllowlisteExtensionInstallBlocklistsu Chrome ed Edge, bloccando l'installazione libera dallo store. Se oggi in azienda chiunque può installare un'estensione, è l'intervento con il miglior rapporto fra costo e beneficio. - Fare l'inventario di ciò che è già installato: quali estensioni, con quali permessi, su quante macchine. Rimuovere quelle non riconosciute, quelle non più mantenute e quelle a cui è stato concesso l'accesso a tutti i siti senza averne bisogno.
- Trattare il cambio di proprietà di un'estensione come un evento di sicurezza. Un'estensione onesta che viene venduta e poi aggiornata diventa ostile senza che l'utente clicchi nulla: è lo scenario in cui la precondizione di BragJack si realizza da sola.
- Per chi dispone di un SOC: conservare ed esportare le trascrizioni delle interazioni fra l'agente del browser e il server del fornitore AI. È il punto di rilevamento che lo stesso ricercatore indica come praticabile, perché le azioni appaiono legittime ma le istruzioni no.
- Separare i profili del browser: sessioni amministrative, console cloud e accessi ai sistemi critici in un profilo dedicato, senza agente AI e senza estensioni. Costa poco e taglia il percorso più pericoloso.
- Inserire gli agenti AI nell'inventario degli asset e nelle politiche d'uso: chi può usarli, su quali dati, con quali account, e con quale processo di autorizzazione.
Per anni la formazione agli utenti si è concentrata sul diffidare di ciò che si scarica e di ciò che si clicca. Il Prompt Forcing sposta la domanda: il software è legittimo, l'aggiornamento è installato, il clic non c'è stato, e l'azione dannosa la compie un componente che l'azienda ha autorizzato. Finché gli agenti nel browser non arriveranno con vincoli propri che impediscano operazioni distruttive o esfiltrazioni prima ancora di ricevere l'ordine — è l'indicazione che Weizman rivolge al settore — l'unica leva che resta in mano alle aziende è decidere con precisione quanti privilegi quel componente può ereditare.