BragJack: un'estensione del browser dirotta gli agenti AI in cinque principali browser

Il 16 settembre 2026 Gal Weizman, ricercatore di sicurezza presso Forever Security, ha pubblicato BragJack: una proof of concept in cui una normale estensione del browser — nessuno zero-day, nessun modello jailbroken, nessun server del fornitore compromesso — ha preso il controllo degli agenti AI integrati in cinque prodotti basati su Chromium, Gemini Live in Google Chrome, Copilot in Microsoft Edge, Opera Neon, Perplexity Comet e Claude in Chrome. L'estensione non richiedeva nulla di esotico. Usava content script e l'API declarativeNetRequest di Chromium, le stesse due autorizzazioni presenti nella maggior parte degli ad blocker, per raggiungere il canale privato che il sito web di ciascun fornitore usa per inviare istruzioni al proprio agente. Weizman riferisce che Comet è stata la compromissione più ampia, che Google e Microsoft hanno rilasciato correzioni e assegnato CVE-2026-0628 e CVE-2026-55945, e che non sono stati osservati attacchi reali. È catalogato come vulnerabilità, gravità alta, in l'archivio degli incidenti AI, dove ogni record riporta le proprie fonti, il grado di affidabilità e il flag di contestazione.

L'estensione non ha rotto il modello. Ha rotto il canale.

Tutti e cinque i prodotti sono costruiti allo stesso modo, secondo il documento tecnico di accompagnamento pubblicato da Forever Security lo stesso giorno. Ognuno ha un "corpo" all'interno del browser che può aprire schede, leggere file locali, acquisire screenshot e fare clic sulle pagine, e un "cervello" all'esterno del browser che decide cosa deve fare il corpo — i server Gemini di Google per Chrome, l'app web perplexity.ai per Comet, copilot.microsoft.com per Edge, il backend di Anthropic per Claude in Chrome. Il corpo è progettato per accettare istruzioni da esattamente un'origine: il sito web del fornitore stesso. Quell'unica origine attendibile è l'intero modello di sicurezza. È anche la cosa che a un'estensione del browser è consentito toccare.

Chromium concede a qualsiasi estensione installata due poteri quasi universali. Uno script di contenuto consente di eseguire JavaScript all'interno di una pagina. L'API declarativeNetRequest, o DNR, consente di riscrivere il traffico di rete — rimuovere un'intestazione di risposta, reindirizzare la richiesta di uno script verso un server diverso. I browser profondono sforzi concreti per tenere questi due poteri lontani dalle superfici privilegiate, e quattro dei cinque fornitori avevano svolto parte di quel lavoro. Ciò che Weizman ha trovato, in ciascun caso, era una lacuna nella parte che avevano lasciato aperta.

Chiama la tecnica generale DinNeR Serving: usare DNR per indebolire le intestazioni di sicurezza di una pagina attendibile, poi usare di nuovo DNR per reindirizzare una delle richieste di script di quella pagina verso un server controllato dall'attaccante. Ora la pagina esegue codice dell'attaccante, ma continua a credere di essere la pagina del fornitore, e l'agente continua a credere di ricevere comunicazioni dal fornitore. In Chrome, Weizman riferisce che le estensioni sono state correttamente bloccate dal collegare un content script o un debugger all'app Gemini incorporata, e che DNR era l'unico meccanismo a cui Chromium non aveva esteso la stessa protezione all'interno di una WebView. Rimuovere la Content-Security-Policy e allentare la policy di isolamento del documento è bastato per sostituire uno script servito da gstatic.com con il suo, e dall'interno di chrome://glic poteva quindi inviare direttamente i tipi di messaggio propri dell'agente del browser — creare una scheda a un indirizzo file:///, leggerla come testo, PDF o screenshot, e recuperare l'indirizzo email e l'immagine del profilo connesso.

Cosa ha fatto la stessa estensione, browser per browser

L'estensione non era cinque strumenti. Era un unico manifest che richiedeva declarativeNetRequest e un ampio accesso agli host, più un file di regole separato per ciascun obiettivo; tra un attacco e l'altro cambiavano solo le regole. La tabella di Forever Security è il riassunto più chiaro di ciò che ciascuna catena riusciva a raggiungere, ed è riprodotta di seguito. La riga che conta di più è Agent hijack: in quattro dei cinque casi, l'esito dimostrato non è stato il furto di dati ma il controllo di un agente in grado di agire per conto dell'utente all'interno di sessioni autenticate.

Quelle catene per browser sono la parte di BragJack che nessun'altra parte ha verificato. BleepingComputer, Cyber Security News, Cloud Security Alliance e il CERT nazionale thailandese hanno tutti riportato la divulgazione, e tutti descrivono la meccanica allo stesso modo, ma ognuno di loro sta descrivendo il resoconto di Forever Security anziché testarlo. L'avviso di ThaiCERT del 21 settembre 2026 cita BleepingComputer come fonte. Quanto segue è quindi il resoconto di Weizman del suo stesso proof of concept, che è ciò che è una divulgazione, e non un risultato riprodotto in modo indipendente.

Perplexity Comet: un dominio di test ancora nella lista dei domini attendibili

Comet era il peggiore dei cinque secondo la classifica dello stesso ricercatore, e il motivo è strutturale, non un errore di programmazione. Perplexity ha creato un browser in cui l'agente dispone dei permessi propri del browser, così un agente dirottato ne eredita tutti. Perplexity aveva anche svolto il lavoro difensivo che gli altri avevano saltato: le estensioni sono del tutto bloccate dall'esecuzione su perplexity.ai, ed è per questo che Weizman dice che i blocca-annunci non funzionano lì.

La lacuna era nell'elenco delle origini da cui l'estensione agente avrebbe accettato comandi. Secondo il resoconto tecnico, quell'elenco conteneva dieci voci, non una — perplexity.ai e la sua variante www, più host di testing, staging e preview sia su perplexity.com sia su perplexity.ai. Solo gli host di produzione erano stati rafforzati. testing.perplexity.com accettava ancora content script. L'ostacolo rimanente era che ognuno di quei domini rispondeva con un redirect 302 a perplexity.ai, quindi il browser non arrivava mai sulla pagina di test abbastanza a lungo perché uno script potesse agganciarsi. Una regola DNR che elimina l'header Location rimuove tale ostacolo, e il content script può quindi parlare direttamente all'estensione agente tramite il canale di messaggistica runtime che questa espone.

Secondo Weizman, su richiesta l'agente elencava la cronologia di navigazione, apriva URL arbitrari, inclusi percorsi file:///, e acquisiva screenshot delle schede visibili — e poi, tramite un comando che avvia l'esecuzione di un agente a partire da un prompt fornito, faceva quasi tutto ciò che potrebbe fare un utente. Il suo prompt dimostrativo chiedeva a Comet di visitare perplexity.ai, riassumere le ultime cinque email e inviare il riepilogo a un secondo indirizzo. Riferisce anche che l'accesso a file:/// era stato affrontato in una precedente segnalazione su Comet, ma che la correzione faceva distinzione tra maiuscole e minuscole, quindi FiLe:///etc/hosts funzionava ancora. Niente di tutto ciò compare in alcun avviso di Perplexity; l'azienda ha pagato un bounty e, secondo Forever Security, ha posto rimedio al comportamento che le è stato mostrato.

Microsoft Edge: una pagina di marketing, un clic sintetico e una corsa

Edge è stato l'unico obiettivo a opporre resistenza, ed è il più istruttivo dei cinque. Microsoft aveva suddiviso il proprio agente in una modalità "Think" che accetta prompt e una modalità "Do" che agisce sulle pagine, con le due deliberatamente impossibilitate a funzionare contemporaneamente — un vero meccanismo di sicurezza, e uno che impedisce per costruzione il prompt forcing. Microsoft aveva anche rafforzato la pagina marketing su microsoft.com/edge che dimostra l'agente, vincolando la sua funzione privilegiata di invio dei prompt a tre condizioni separate: una Content-Security-Policy che non poteva essere semplicemente eliminata, perché l'oggetto privilegiato non viene mai creato quando l'header è assente, un token fresco basato sul gesto dell'utente, e una funzione che popola la casella del prompt anziché inviarlo.

Il resoconto di Weizman è che ogni condizione è stata aggirata con un trucco diverso. Invece di eliminare il CSP, ha ampliato la sua direttiva frame-ancestors per consentire l'incorporamento da qualsiasi sito .com. Per il token di gesto ha aggiunto il permesso debugger al manifest e inviato un clic sintetico, che Chromium accetta come gesto organico. Per la race, ha disattivato il flag degli strumenti dell'agente, chiamato la funzione di invio del prompt, poi riattivato il flag mentre l'agente stava ancora decidendo se gli fosse consentito agire. L'impostazione era disattivata nel momento in cui il prompt è stato forzato e attiva nel momento in cui è stato eseguito il controllo dei permessi. È a questo che Microsoft ha assegnato CVE-2026-55945.

Il denaro corrisponde al lavoro: Forever Security registra 3.000 dollari per la scoperta su Edge Chromium e 2.000 dollari per la race condition, 5.000 dollari in totale — terzo dei cinque, dietro i 7.000 dollari ciascuno di Google e Perplexity.

Opera Neon e Claude in Chrome: i due più semplici

Opera Neon è stata quella che ha richiesto meno impegno delle cinque. Il suo agente riceve ordini da opera.com e, a differenza di Google e Perplexity, che hanno entrambe impedito alle estensioni di agganciare content script all'origine attendibile del proprio agente, Opera non aveva impedito alle estensioni di agganciare un content script a quel dominio, così l'estensione di Weizman poteva iniettare uno script lì e chiamare direttamente il canale di messaggi dell'agente con qualunque prompt volesse. L'eliminazione della CSP rendeva lo stesso attacco incorporabile in un frame invisibile su qualsiasi pagina. Il suo articolo aggiunge un dettaglio che non compare nella copertura di nessun altro: Opera gli ha detto di aver scoperto il difetto in modo indipendente più o meno nello stesso periodo, e ha comunque pagato la taglia da $900. Si tratta di un'affermazione del fornitore riportata dal ricercatore, non di una scoperta per cui una delle due parti abbia pubblicato prove.

Claude in Chrome è il caso anomalo, perché è un'estensione anziché un browser, e Forever Security lo dice apertamente: un'estensione che ne sfrutta un'altra è un rischio minore rispetto a un'estensione che sfrutta il browser in cui viene eseguita. Il meccanismo era una pagina di marketing su claude.ai che poteva inviare prompt arbitrari al pannello laterale, combinata con un content script che si attivava ai clic su un pulsante di onboarding e leggeva il prompt da un attributo data. Weizman impostò personalmente l'id e l'attributo del body della pagina, inviò un clic sintetico tramite il permesso del debugger, e il pannello laterale si aprì con il suo prompt al suo interno. Anthropic la classificò di gravità media, pagò un bounty, e secondo Forever Security riconobbe l'azienda come la prima a segnalare questa specifica scoperta. I due post di Forever Security discordano leggermente sull'importo — $600 nella tabella principale, $500 nell'articolo tecnico di accompagnamento.

Che cosa dicono realmente i registri dei fornitori stessi

Solo due dei cinque hanno prodotto una registrazione pubblica della vulnerabilità, ed entrambi precedono di mesi il write-up di BragJack. La nota di rilascio del canale stabile di Google per il 6 gennaio 2026 elenca «High CVE-2026-0628: Insufficient policy enforcement in WebView tag. Reported by Gal Weizman on 2025-11-23», e indica 143.0.7499.192/.193 per Windows e Mac e 143.0.7499.192 per Linux. La voce del National Vulnerability Database, pubblicata il 7 gennaio 2026, descrive la falla come la possibilità per un attaccante «che abbia convinto un utente a installare un'estensione malevola» di iniettare script o HTML in una pagina privilegiata tramite un'estensione Chrome appositamente creata, la classifica come CWE-862, autorizzazione mancante, e riporta un punteggio CVSS 3.1 di 8.8. Quel punteggio non è di Google: proviene dall'arricchimento del record da parte della CISA, come ha osservato The Hacker News, e la nota di Google stessa valuta il problema come High.

Il record di Microsoft è ancora più limitato. CVE-2026-55945, pubblicata il 3 luglio 2026, è una race condition CWE-362 con un punteggio CVSS 3.1 di 4.2, gravità Moderata. La dichiarazione d'impatto di Microsoft è "Information Disclosure", e le sue stesse FAQ affermano che le informazioni divulgate sono il contenuto di file. La build corretta è 150.0.4078.48, rilasciata lo stesso giorno, e lo stato di sfruttamento della scheda recita "Publicly Disclosed: No; Exploited: No". Nulla in quel documento descrive un agente guidato attraverso siti web arbitrari, che è l'impatto riportato da Weizman. Entrambe le affermazioni possono essere vere contemporaneamente — la CVE riguarda la race condition, mentre la capacità della pagina di marketing era una seconda scoperta pagata separatamente — ma nessun documento del fornitore pubblicato finora descrive la catena end-to-end.

"Zero click" significa dopo che l'estensione è installata

La frase nella tabella di Forever Security è accurata e facile da fraintendere. BragJack non è un attacco drive-by. BleepingComputer, la Cloud Security Alliance e ThaiCERT partono tutti dalla stessa condizione preliminare: l'estensione malevola deve essere già installata. Ciò che la ricerca mostra è che, una volta installata, non serve alcun ulteriore clic: l'estensione raggiunge l'agente su qualunque pagina si trovi l'utente, senza mostrare nulla. Per Comet e Opera Neon non era richiesta alcuna interazione; per Edge e Claude in Chrome il clic richiesto dall'agente è stato sintetizzato dall'estensione tramite l'autorizzazione del debugger, quindi non è stato fornito dall'utente.

Questa distinzione definisce l'esposizione nel mondo reale. L'attacco richiede o un utente che installi qualcosa di malevolo o un'estensione già considerata affidabile nello store che diventi malevola in seguito, e nessuna delle due è una soglia elevata — ecco perché le raccomandazioni di CSA si concentrano sull'inventario delle estensioni e sul trattare i permessi declarativeNetRequest e debugger come privilegiati. È anche il motivo per cui nessuno ha segnalato un attacco: una proof of concept che richiede l'installazione di un'estensione ostile è una dimostrazione di una capacità, non una campagna.

Prompt forcing e l'argomentazione di vendita ad esso collegata

La terminologia è importante perché descrive dove si trovavano le difese. L'iniezione di prompt nasconde istruzioni nel contenuto che un modello sta già leggendo; l'addestramento e i filtri del modello sono la rete di sicurezza prevista. Ciò che ha fatto Weizman è stato scrivere l'intero prompt, scegliere il momento in cui è arrivato e continuare a inviare follow-up — da un'origine di cui l'agente era stato progettato per fidarsi. Il filtraggio di sicurezza a livello di modello non diventa mai rilevante, perché nulla nello scambio sembra un attacco. Forever Security chiama questo prompt forcing.

Il corollario che l'azienda ne trae è che nemmeno il rilevamento sugli endpoint può vederlo, poiché non viene eseguito codice malevolo: a software legittimo viene detto di fare qualcosa che è autorizzato a fare. Tale affermazione arriva legata a una proposta commerciale — Forever Security vende un agente endpoint nativo per l'IA, e entrambi i resoconti si chiudono raccomandandolo. L'osservazione che un agente dirottato non produce alcuna firma malware non dipende dall'acquistare qualcosa, ma è l'argomentazione del ricercatore anziché un risultato misurato, e nessuna parte indipendente ha verificato se un prodotto endpoint di qualsiasi tipo rilevi queste catene.

Che cosa è consolidato e che cosa dipende da un solo ricercatore

L'archivio classifica questa voce come vulnerabilità, gravità alta, regione globale, affidabilità B — documentata, ma da una fonte unica o secondaria — non contestata, senza danni reali registrati. Quel grado descrive le prove anziché la gravità dei bug, e la divisione attraversa nettamente la vicenda.

Accertato, nel senso che lo dichiara un fornitore o una fonte di prima parte:

• Google ha rilasciato una correzione di Chrome il 6 gennaio 2026 nelle versioni 143.0.7499.192 e .193, e ha attribuito a Gal Weizman una segnalazione datata 23 novembre 2025. Ciò compare nella nota di rilascio di Google stessa, non nel resoconto che ne ha fatto il ricercatore.

• CVE-2026-0628 esiste, è valutata High da Google e 8.8 dall'arricchimento di CISA nel record NVD, ed è classificata come applicazione insufficiente delle policy in un tag WebView.

• Microsoft ha pubblicato CVE-2026-55945 il 3 luglio 2026 come una race condition di gravità Moderata (4.2) che porta alla divulgazione di informazioni, corretta in Edge 150.0.4078.48, con sfruttamento registrato come nessuno.

• Le valutazioni SSVC della CISA in entrambi i record NVD indicano "exploitation: none", e nessuno — fornitore, ricercatore o segnalatore — ha dichiarato un attacco in-the-wild. Si tratta di un'assenza di segnalazioni, che non equivale alla prova dell'assenza, ma è lo stato del registro sei settimane dopo la pubblicazione.

Basandosi esclusivamente sul resoconto di Forever Security:

• Ogni catena di exploit specifica per browser, inclusi i set di regole DNR, la rimozione del reindirizzamento di testing.perplexity.com, la sequenza della pagina di marketing di Edge e il clic sul pulsante di onboarding di Claude. Le CVE descrivono due meccanismi; non descrivono queste catene.

• L'elenco completo degli impatti per Comet — cronologia di navigazione, lettura di file locali, dati del profilo, screenshot — e l'affermazione specifica che a un agente Comet dirottato si possa ordinare, in semplice inglese, di riassumere e inoltrare email. BleepingComputer lo riporta come dimostrazione del ricercatore; nessuna dichiarazione di Perplexity lo conferma o lo smentisce.

• L'accesso alla fotocamera e al microfono di Chrome, che BleepingComputer descrive come "{{1}}potenzialmente{{/1}}" raggiungibile e che la tabella Forever elenca come ottenuto.

• Il totale delle taglie. Forever Security dichiara circa 20.000 $ su cinque fornitori; le sue stesse cifre per prodotto ammontano a 20.500 $, un punto aritmetico che anche The Hacker News ha fatto notare. La cifra di Claude in Chrome differisce tra i due post dell'azienda. Il "più di 20.000 $" di BleepingComputer è coerente con entrambe le letture.

• Che il prompt forcing sia una nuova classe di attacco anziché un nome per una famiglia di bug di autorizzazione. Questa è un'affermazione di framing, e la Cloud Security Alliance — che l'ha adottata — descrive il pattern sottostante come una lacuna architetturale condivisa tra i fornitori, non come una nuova tecnica con meccaniche proprie.

Tre dei cinque fornitori non hanno mai pubblicato alcun record di vulnerabilità. CSA osserva che Perplexity, Opera e Anthropic hanno riconosciuto e corretto il proof of concept specifico senza advisory comparabili a quelli di Google e Microsoft, e Forever Security non fornisce date di correzione per questi tre. Non è stata pubblicata alcuna riproduzione indipendente di alcuna catena BragJack; Cyber Security News e ThaiCERT riportano entrambi la divulgazione, e ThaiCERT cita BleepingComputer.

Cosa è cambiato dopo la divulgazione

Per gli utenti di Chrome e Edge la risposta pratica è che il 16 settembre non c'era nulla da cambiare: le correzioni erano state rilasciate a gennaio e luglio, e chiunque usasse Chrome 143.0.7499.192 o versioni successive, oppure Edge 150.0.4078.48 o versioni successive, era già protetto. Vale la pena soffermarsi su questa tempistica. I bug erano stati chiusi mesi prima che la tecnica che li collegava avesse un nome, il che è la normale forma della divulgazione coordinata e anche il motivo per cui il titolo suona peggio dello stato delle correzioni.

Per Comet, Opera Neon e Claude in Chrome la posizione è meno chiara. Ciascun fornitore ha pagato una taglia e, secondo Forever Security e CSA, ha risolto il comportamento dimostrato. Nessuno ha pubblicato un avviso con versione specificata o una data, quindi non esiste un numero di build da verificare per l'utente, ma solo l'indicazione generica di mantenere il software aggiornato. La guida della CSA per le organizzazioni consiste nel censire le estensioni con permessi declarativeNetRequest o debugger, limitare i browser agentici a profili privi di sessioni autenticate su email, codice o finanza, e chiedere ai fornitori come distinguono l'input sintetico da quello genuino dell'utente. Il consiglio di BleepingComputer per i privati è più semplice: mantenere il browser aggiornato, rimuovere le estensioni che non si riconoscono e trattare "leggere e modificare tutti i tuoi dati su tutti i siti web" per l'avvertimento che è.

La questione irrisolta non è se siano stati corretti cinque bug. È se lo sia stata l’ipotesi progettuale che ne sta alla base. Ognuno di questi prodotti considerava un’origine web first-party un luogo affidabile in cui un agente locale privilegiato potesse ricevere ordini, in un browser in cui qualsiasi estensione installata può riscrivere ciò che quell’origine dichiara. Forever Security sostiene che la soluzione sia il monitoraggio a livello di endpoint; CSA sostiene la validazione dell’origine, il privilegio minimo, canali di comando isolati e una provenienza degli input non falsificabile. Nessuno dei cinque fornitori ha dichiarato pubblicamente, in alcun documento esaminato per questo articolo, di aver modificato l’architettura anziché il percorso specifico seguito da Weizman.

La data del verbale è la data della spiegazione, non quella dei bug — e in quel divario sta la storia. Una sola estensione, due permessi che gli ad blocker detengono da anni, e cinque fornitori convinti ciascuno che il proprio sito web fosse l'unico posto in cui un attaccante non potesse mettere piede.