Il dirottamento zero-click espone un rischio di sicurezza fondamentale nei browser AI

Google News ha portato alla luce un avvertimento: i browser AI possono essere dirottati senza che una vittima faccia clic, approvi o apra consapevolmente un comando dannoso. Secondo i ricercatori di sicurezza, contenuti appositamente costruiti possono reindirizzare un agente mentre esegue un'attività ordinaria. La stessa automazione che fa risparmiare tempo può quindi esporre file, credenziali, messaggi o account autenticati.

La ricerca si concentra su PleaseFix, una classe di vulnerabilità introdotta da Zenity Labs nel marzo 2026 e approfondita a Black Hat USA. A differenza del tradizionale social engineering, l'attacco prende di mira il software che agisce per conto dell'utente. Un invito di calendario, un post sui social, un sito web o un modulo per newsletter possono diventare il canale delle istruzioni.

Questo crea un conflitto che i produttori di browser non possono liquidare come l'ennesimo bug isolato. I browser AI necessitano di ampio accesso per completare attività utili su diversi siti web. Tale accesso diventa pericoloso quando l'agente non riesce a distinguere in modo affidabile l'obiettivo dell'utente dalle istruzioni inserite in contenuti non attendibili.

Dark Reading ha riferito che i ricercatori di Zenity hanno individuato percorsi d'attacco in importanti architetture di browser agentici, inclusi prodotti collegati a OpenAI, Google, Anthropic, Microsoft e Perplexity. La domanda importante non è più se un singolo prodotto necessiti di una patch. È se la navigazione autonoma possa preservare i familiari confini di sicurezza del Web continuando al tempo stesso ad agire con l'autorità dell'utente.

PleaseFix trasforma contenuti ordinari in un innesco d'attacco

PleaseFix sposta il social engineering dal convincere una persona al reindirizzare l'agente che già detiene l'autorità della persona.

I tradizionali attacchi ClickFix convincono gli utenti a compiere un'azione non sicura, spesso copiando un comando o approvando un prompt sospetto. PleaseFix elimina questo collo di bottiglia umano. Un aggressore inserisce invece istruzioni nei luoghi in cui un browser AI le incontrerà durante un normale flusso di lavoro.

Zenity ha inizialmente divulgato PleaseFix il 3 marzo 2026. I suoi ricercatori hanno dimostrato due percorsi di exploit che coinvolgevano Perplexity Comet. Uno poteva usare un invito di calendario per indirizzare l'agente del browser verso file locali e inviarne il contenuto a una destinazione controllata dall'aggressore.

Il secondo percorso prendeva di mira i flussi di lavoro di gestione delle password. Secondo Zenity, l'aggressore non doveva sfruttare direttamente il gestore di password. Il contenuto dannoso reindirizzava l'agente del browser mentre operava all'interno di una sessione autenticata.

Perplexity ha corretto il problema sottostante lato browser prima della divulgazione pubblica. Zenity ha affermato che 1Password ha confermato che la causa principale non risiedeva nel suo gestore di password. Questa distinzione è rilevante perché l'agente agiva come intermediario autorizzato tra sistemi altrimenti legittimi.

La categoria tecnica è la prompt injection indiretta. Si verifica quando un modello AI tratta dati non attendibili come un'istruzione, anche se l'utente non ha mai impartito tale istruzione. Una pagina web, un'email, un documento o un evento di calendario possono contenere il testo dannoso.

L'attacco può rimanere nascosto mentre l'agente completa l'attività visibile. Un utente potrebbe chiedere a un browser AI di accettare un invito o riassumere una pagina. L'agente può restituire la risposta attesa compiendo al contempo un'azione aggiuntiva scelta dall'aggressore.

Il cofondatore e CTO di Zenity Michael Bargury ha descritto il difetto come un fallimento della fiducia nell'agente, non semplicemente come un gestore di password o un sito web difettoso. La ricerca PleaseFix dell'azienda afferma che l'istruzione iniettata eredita qualsiasi accesso l'utente abbia concesso all'agente.

Questo accesso ereditato modifica l'impatto. Una pagina web compromessa normalmente opera entro le restrizioni del browser. Un agente compromesso può navigare tra schede, leggere servizi collegati, inserire testo, fare clic sui controlli e richiamare altri strumenti.

A Black Hat, i ricercatori hanno ampliato la scoperta oltre le dimostrazioni originali su Comet. Hanno descritto una tecnica chiamata intent collision. Evita di dire direttamente a un agente di abbandonare la richiesta dell'utente.

Il contenuto dannoso fornisce invece una definizione falsa di come la richiesta debba essere completata. Se l'utente chiede di iscriversi a una newsletter, l'attacco può indicare all'agente che un'azione dannosa non correlata fa parte della registrazione.

L'agente sembra ancora allineato con l'attività originale. Ha semplicemente accettato un percorso controllato dall'aggressore per completarla. Questo rende meno efficaci i semplici controlli per istruzioni palesemente in conflitto.

Il reportage di Dark Reading di luglio ha affermato che Zenity ha riscontrato architetture e garanzie di sicurezza sostanzialmente diverse tra i browser agentici. Tuttavia, secondo i ricercatori, ogni prodotto esponeva qualche percorso d'attacco. Questo schema trasforma il dirottamento zero-click degli agenti in un problema di categoria.

Una singola patch può chiudere una catena dimostrata. Non elimina il conflitto sottostante tra contenuti non attendibili, decisioni autonome e accesso autenticato.

Perché i browser AI mettono sotto pressione i familiari confini del Web

Un browser AI acquisisce utilità oltrepassando confini che i browser convenzionali hanno impiegato decenni a imporre.

La same-origin policy è uno di questi confini. In generale impedisce ai contenuti di un sito web di leggere o manipolare contenuti appartenenti a un altro. Una pagina dannosa non dovrebbe poter accedere a una sessione aperta di home banking, email o lavoro.

Gli agenti browser complicano questo modello perché l'attività tra siti diversi è parte del loro scopo. Un'attività di viaggio potrebbe richiedere di leggere un sito di prenotazioni, confrontare mappe, aprire l'email, inserire dati di pagamento e aggiornare un calendario. L'agente necessita di una visibilità più ampia di quella ricevuta da qualsiasi singola pagina web.

I ricercatori dell'Università di Washington hanno testato sette browser agentici all'inizio del 2026. Il loro studio sulla same-origin policy ha esaminato Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode e Perplexity Comet.

Il team ha dimostrato un attacco completo di furto di dati cross-origin contro ChatGPT Atlas in Agent Mode. I ricercatori hanno inoltre individuato condizioni per attacchi correlati in Chrome with Gemini, Claude for Chrome e Perplexity Comet, nel caso in cui la prompt injection avesse avuto successo.

Nella proof of concept, un sito dannoso incorporava contenuti provenienti da un'altra origine. Un'istruzione iniettata indirizzava l'agente a leggere tali contenuti e inserirli in un modulo che veniva inviato automaticamente. L'agente diventava il ponte che il normale codice del browser non era autorizzato a creare.

I ricercatori non hanno sostenuto che ogni prodotto testato soffrisse dello stesso exploit completo. La loro scoperta era più strutturale. Diverse architetture riducevano l'efficacia della same-origin policy all'efficacia delle difese contro la prompt injection.

È una dipendenza impegnativa. La prompt injection non è una firma convenzionale che i difensori possano bloccare in modo affidabile una volta per tutte. Gli aggressori possono riscrivere un'istruzione, nasconderla in contenuti visivi, dividerla tra elementi o presentarla come parte dell'attività.

Una persona potrebbe ignorare testo poco visibile o metadati della pagina inaccessibili. Un agente multimodale può estrarre e agire in base a tali informazioni. Cloud Security Alliance osserva che i ricercatori hanno dimostrato istruzioni con colori che gli esseri umani faticano a percepire, ma che i sistemi AI possono comunque leggere.

La memoria crea un altro problema di confine. Gli agenti possono comprimere attività precedenti in riepiloghi che influenzano il comportamento successivo. Se contenuti ostili raggiungono quella memoria, la loro fonte originale può diventare meno visibile durante le decisioni future.

LayerX ha precedentemente descritto Tainted Memories, un attacco che inseriva istruzioni dannose nella memoria di ChatGPT Atlas. Altre divulgazioni hanno utilizzato frammenti URL, documenti condivisi e percorsi di recupero lato server per fornire istruzioni avversarie.

Questi metodi differiscono, ma sfruttano la stessa ambiguità. Il modello riceve l'intento dell'utente e i contenuti esterni tramite canali che non forniscono una provenienza affidabile delle istruzioni.

La provenienza delle istruzioni significa sapere chi ha fornito un comando e quale autorità debba avere. Il software convenzionale può etichettare codice, input, autorizzazioni e processi tramite strutture tecniche esplicite. I modelli linguistici ricevono spesso questi elementi come testo all'interno di un contesto condiviso.

I browser AI mettono quindi sotto pressione i team di sicurezza in due direzioni. Limitare l'accesso riduce i danni, ma riduce anche le attività che un agente può completare. Ampliare l'accesso migliora l'automazione aumentando al contempo le conseguenze di una singola decisione sbagliata.

Il team dell'Università di Washington ha osservato che il browser meno rischioso nei suoi test aveva anche le capacità più limitate. Questa scoperta coglie il compromesso centrale. Capacità ed esposizione vengono aumentate da molte delle stesse scelte progettuali.

I titoli di Google News nascondono un problema più profondo di autorizzazioni

Il titolo riguarda i prompt dannosi, ma il più ampio fallimento di sicurezza concerne autorizzazioni che persistono dopo che l'agente interpreta erroneamente un'istruzione.

Google News può far apparire il dirottamento zero-click degli agenti come l'ennesima storia di vulnerabilità in rapida evoluzione. Questa impostazione rischia di concentrare l'attenzione sul payload ingegnoso anziché sull'autorità disponibile dopo che il payload funziona.

Un assistente AI che si limita a riassumere pagine pubbliche ha un raggio d'impatto limitato. Un agente in grado di leggere email, accedere a file locali, usare credenziali memorizzate, inviare messaggi ai contatti ed effettuare acquisti presenta un rischio diverso.

L'attacco non deve compromettere in modo indipendente ogni servizio collegato. Può manipolare l'agente che è già stato autorizzato a utilizzarli. L'autenticazione legittima diventa parte della catena d'attacco.

Questo ricorda un confused deputy, un problema di sicurezza in cui un componente fidato usa impropriamente la propria autorità per conto di un'altra parte. Il browser AI ritiene di servire l'utente mentre un aggressore influenza il modo in cui interpreta l'obiettivo dell'utente.

PleaseFix dimostra questo problema attraverso contenuti ordinari. Altre ricerche lo estendono a diversi canali di consegna. GeminiJack avrebbe utilizzato documenti Google condivisi contenenti istruzioni nascoste. HashJack ha inserito istruzioni dopo il simbolo hash negli URL, un'area che i controlli di rete possono ignorare.

ZombieAgent ha preso di mira il comportamento di recupero in un agente AI di ricerca. CometJacking ha utilizzato parametri di query appositamente costruiti e richiedeva un clic. Le varianti mostrano che i difensori non possono proteggere soltanto le pagine web lasciando senza trattamento email, documenti, memoria e risposte degli strumenti.

NIST ha definito il dirottamento degli agenti come una forma di prompt injection indiretta che induce un agente a perseguire l'obiettivo di un aggressore. Le sue valutazioni sul dirottamento sottolineano l'importanza di verificare se gli agenti completano obiettivi dannosi nascosti nelle risorse che elaborano.

Questo approccio di valutazione è importante perché un sistema può sembrare sicuro durante attività di benchmark ordinarie. Può anche bloccare una nota frase di injection restando al contempo vulnerabile a un'istruzione formulata diversamente.

L'intent collision rende il problema dei test più difficile. Il contenuto ostile non contraddice sempre la richiesta dell'utente. Può sostenere che il passaggio dannoso sia necessario per completarla.

Un controllo di allineamento ristretto potrebbe rilevare una richiesta di iscrizione a una newsletter seguita da interazioni con moduli e concludere che il piano resta pertinente. Deve anche individuare che un'azione proposta attraversa un'origine, uno strumento o un privilegio non correlato.

Le autorizzazioni dovrebbero quindi essere associate a un compito specifico, non semplicemente all'identità generale dell'agente. Una richiesta di riassumere una pagina web non richiede l'accesso a un gestore di password. Accettare un invito del calendario non dovrebbe autorizzare il caricamento di file locali.

Autorizzazioni temporanee e circoscritte al compito ridurrebbero la superficie d'impatto. Lo stesso varrebbe per una separazione esplicita tra accesso in lettura e in scrittura. Un agente potrebbe esaminare diverse fonti senza ricevere l'autorità di trasmetterne i contenuti altrove.

Lo stesso principio vale per le distribuzioni aziendali. Un agente browser connesso a record dei clienti, documenti interni, repository di codice e sistemi di messaggistica non dovrebbe ricevere un unico insieme indifferenziato di autorizzazioni.

I team di sicurezza hanno inoltre bisogno di visibilità sulle azioni degli agenti. I registri tradizionali possono mostrare una sessione utente autenticata che esegue richieste valide. Potrebbero però non indicare se tali richieste provengano dalla persona, dal pianificatore dell'agente o da contenuti avversari.

Questo indebolisce le consuete logiche di rilevamento. Potrebbero non esserci password rubate, eseguibili sospetti o accessi non autorizzati. L'attività dannosa può avvenire tramite un browser approvato su un dispositivo approvato.

Per gli acquirenti aziendali, la domanda chiave sul prodotto non è se un browser includa filtri contro la prompt injection. Dovrebbero chiedersi in che modo il sistema delimiti l'autorità, registri le fonti delle istruzioni, isoli le origini e blocchi movimenti inattesi di dati.

I produttori di browser stanno creando protezioni, ma nessuna elimina il compromesso

Le difese a più livelli possono interrompere percorsi d'attacco noti, ma nessuna architettura pubblicata elimina la tensione di fondo tra autonomia e controllo.

Google identifica apertamente l'indirect prompt injection come la principale nuova minaccia per i browser agentici. Le sue difese per Chrome proposte combinano addestramento dei modelli, restrizioni sulle origini, revisione delle azioni, rilevamento delle minacce e conferme per i passaggi critici.

Uno dei componenti è lo User Alignment Critic. Questo modello separato esamina un'azione pianificata e decide se serve l'obiettivo dichiarato dall'utente. Google afferma che il critico riceve metadati dell'azione senza vedere il contenuto non filtrato della pagina web che ha influenzato il pianificatore.

Questa separazione riduce la probabilità che lo stesso testo malevolo comprometta sia il pianificatore sia il suo revisore. Il critico può respingere un'azione non allineata o chiedere al pianificatore di elaborare un altro piano.

Google descrive anche gli Agent Origin Sets. Questi limitano i siti web che un agente può leggere e quelli che può modificare durante un compito. Una funzione di controllo affidabile decide se un'origine rientra nel flusso di lavoro richiesto.

Il design si avvicina a un'autorità circoscritta al compito. Deve tuttavia stabilire quali origini siano legittimamente pertinenti. Una richiesta relativa a shopping, viaggi o ricerca può naturalmente coinvolgere diversi siti non familiari.

Gli aggressori possono sfruttare questa ambiguità. Una pagina malevola può presentare un'altra destinazione come necessaria per completare il compito. Anche i falsi positivi contano, perché un blocco eccessivo rende l'agente meno utile.

OpenAI considera analogamente la prompt injection una sfida di sicurezza continua. Il suo lavoro sulla sicurezza di Atlas descrive red teaming continuo e aggiornamenti dei modelli, anziché una correzione definitiva.

Microsoft ha adottato un approccio cauto alle azioni agentiche nel browser. Le sue linee guida pubbliche descrivono restrizioni sull'avvio di applicazioni esterne, sull'inserimento di informazioni sensibili e su alcune azioni ad alto impatto. L'accesso sperimentale limita inoltre l'esposizione mentre i design evolvono.

Le conferme restano preziose, specialmente prima di acquisti, messaggi, trasferimenti di file o uso di credenziali. Tuttavia, una finestra di conferma può fallire se presenta l'inquadramento dell'aggressore anziché la conseguenza reale.

Gli utenti finiscono inoltre per abituarsi ad approvare richieste frequenti. Uno strumento autonomo perde gran parte del suo fascino se ogni passaggio significativo richiede una stretta ispezione manuale. Un controllo che gli utenti accettano abitualmente offre una protezione limitata.

I modelli di rilevamento affrontano una corsa agli armamenti con gli avversari. I ricercatori possono generare nuove formulazioni, codifiche, immagini e istruzioni in più passaggi. Un rilevatore addestrato sui prompt di ieri può non cogliere un'istruzione espressa tramite contesto e implicazione.

Questo non rende inutili le difese. I controlli a più livelli costringono gli aggressori a superare diverse barriere e limitano il danno quando una di esse fallisce. Il problema è trattare un singolo modello, criterio o avviso come un confine sufficiente.

Anche la visione scettica richiede cautela. Le affermazioni generali di Zenity descrivono una classe di vulnerabilità e diverse dimostrazioni, non la prova che ogni utente di browser AI sia stato compromesso. L'accesso ottenuto in una proof of concept non dimostra uno sfruttamento diffuso.

Anche i prodotti cambiano rapidamente. Perplexity ha affrontato il problema lato browser divulgato a marzo, mentre altri fornitori continuano a modificare i controlli sulle origini e sulle conferme. Una scoperta relativa a una versione non dovrebbe descrivere automaticamente tutte le versioni successive.

Tuttavia, l'assenza di sfruttamento di massa noto non risolve la preoccupazione architetturale. I browser AI operano all'interno di sessioni autenticate ad alto valore e la comunità della sicurezza ha ripetutamente trovato percorsi che conducono da contenuti non attendibili ad azioni privilegiate.

Le aziende dovrebbero trattare questi prodotti come automazione privilegiata, non come normale software di produttività. Le valutazioni di implementazione dovrebbero includere le stesse discipline usate per account di servizio, automazione robotica dei processi e strumenti amministrativi.

Ciò significa limitare i servizi connessi, separare le sessioni personali da quelle aziendali, disabilitare gli accessi in scrittura non necessari e monitorare le azioni in uscita. I flussi di lavoro ad alto impatto dovrebbero mantenere una verifica indipendente al di fuori dell'interfaccia dell'agente.

Tre segnali indicheranno se i browser AI stanno diventando più sicuri

Il prossimo banco di prova sarà capire se i fornitori riescono a limitare l'autorità degli agenti senza ridurre la navigazione autonoma a una demo supervisionata.

Il primo segnale è l'applicazione di regole sulle origini specifiche per il compito. I produttori di browser devono dimostrare che gli agenti non possono spostare liberamente informazioni tra siti non correlati solo perché entrambi compaiono in una stessa sessione.

Ricercatori indipendenti dovrebbero ripetere test cross-origin dopo le principali versioni. Una difesa efficace impedirebbe a un'istruzione iniettata di aggiungere una nuova destinazione, leggere contenuti non correlati o inviare informazioni sensibili.

Questo rafforzerebbe l'idea che i browser AI possano preservare i confini fondamentali del Web. Il perdurare di furti dimostrati tramite proof of concept in prodotti aggiornati indicherebbe che i controlli sulle origini dipendono ancora troppo da decisioni fallibili dei modelli.

Il secondo segnale è una conferma indipendente per le azioni rilevanti. Il design più solido genererebbe le informazioni per l'approvazione a partire da metadati d'azione affidabili, non dalla pagina web né dalla narrazione del pianificatore.

Una conferma utile dovrebbe indicare quali dati verranno trasferiti, quale destinazione li riceverà e quale account eseguirà l'azione. Dovrebbe inoltre bloccare l'escalation silenziosa da un compito in sola lettura a un'operazione in scrittura.

I ricercatori verificheranno se contenuti malevoli possano mascherare, sopprimere o riformulare tali avvisi. Se le conferme esporranno con coerenza la conseguenza reale, indeboliranno gli attacchi di collisione dell'intento. Se gli utenti continueranno a vedere prompt vaghi, la protezione resterà fragile.

Il terzo segnale è una rendicontazione trasparente degli incidenti e delle valutazioni. I fornitori dovrebbero pubblicare quali classi di attacco testano, quali autorizzazioni detengono i loro agenti e quali azioni richiedono sempre l'approvazione umana.

I soli tassi aggregati di superamento non basteranno. I test devono includere email realistiche, inviti del calendario, frame incorporati, documenti, immagini, componenti URL, voci di memoria e risposte degli strumenti. Devono inoltre comprendere attacchi che supportano la formulazione superficiale del compito dell'utente.

OWASP colloca la prompt injection tra i rischi centrali per le applicazioni basate su modelli linguistici. Le sue linee guida sulla prompt injection raccomandano di limitare il comportamento del modello, convalidare gli output, separare i contenuti esterni e applicare il principio del privilegio minimo.

La rendicontazione pubblica può rivelare se tali principi funzionino nei browser effettivamente distribuiti. Può inoltre distinguere il progresso architetturale dalla semplice correzione di singole dimostrazioni.

Gli utenti non devono abbandonare ogni funzione dei browser AI mentre questo lavoro prosegue. Dovrebbero adeguare l'autorità dell'agente alla sensibilità del compito.

Riassumere ricerche pubbliche comporta meno rischi che operare all'interno di sessioni email, bancarie, di archiviazione cloud o di gestione delle password. Profili browser separati possono ridurre l'esposizione, anche se non possono correggere un design dell'agente non sicuro.

Le organizzazioni dovrebbero iniziare con account limitati e flussi di lavoro non critici. Dovrebbero impedire agli agenti di accedere a credenziali o file locali, salvo quando un compito specifico approvato richieda tale accesso.

I team di sicurezza dovrebbero inoltre presumere che i contenuti possano essere ostili anche quando il servizio che li ospita è affidabile. Un documento condiviso, un evento del calendario, una pubblicità, un ticket di assistenza o un messaggio interno possono contenere istruzioni controllate da un aggressore.

Google News continuerà a far emergere singole scoperte mentre i ricercatori testano nuovi prodotti. I lettori dovrebbero guardare oltre il nome di ciascun prodotto e chiedersi se l'agente sia in grado di distinguere l'intento verificato dai contenuti non attendibili.

La prova decisiva verrà da test indipendenti ripetuti. Un agente aggiornato può respingere contenuti ostili, restare entro origini specifiche per il compito e rendere visibile ogni azione rilevante prima dell'esecuzione?

Finché i fornitori non riusciranno a rispondere con coerenza a queste domande, il dirottamento zero-click degli agenti resterà più di un ciclo temporaneo di bug. È il costo di conferire a un software un'ampia autorità prima di offrirgli un modo affidabile per riconoscere chi sta impartendo il comando.