ChatGPhish espone a phishing mentre agenti LLM violano database interni

ChatGPT diventa contemporaneamente bersaglio e superficie di amplificazione per nuove minacce legate all’intelligenza artificiale generativa, mentre gli agenti LLM dimostrano di poter trasformare una vulnerabilità iniziale in una violazione profonda di database interni in meno di un’ora. Due casi recenti descrivono con precisione il cambio di fase della sicurezza AI: da un lato la vulnerabilità ChatGPhish, basata sul rendering Markdown non correttamente separato dall’origine esterna dei contenuti, consente di trasformare normali pagine web in payload di phishing visualizzati dentro l’interfaccia fidata di ChatGPT; dall’altro un attacco orchestrato da un agente basato su LLM sfrutta una CVE su un notebook marimo esposto, recupera credenziali, interroga AWS Secrets Manager, accede a un bastion server e scarica dati da un database PostgreSQL interno attraverso una catena di pivot rapida, adattiva e guidata dall’output precedente. Il punto critico non riguarda più solo l’uso improprio dei chatbot, ma la fiducia strutturale che utenti e aziende attribuiscono all’output generato dall’AI e la capacità degli agenti autonomi di eseguire operazioni offensive con una velocità prima riservata a operatori esperti.

ChatGPhish sfrutta il rendering Markdown dentro ChatGPT

La vulnerabilità ChatGPhish colpisce un punto molto sensibile dell’esperienza utente: il confine tra contenuto esterno e output generato dall’assistente. Il problema emerge quando l’utente utilizza funzioni di riassunto pagina, come Summarize page, integrate con browser come Firefox. In questo scenario ChatGPT riceve il contenuto di una pagina web, lo elabora e restituisce un riassunto apparentemente affidabile. Il nodo tecnico nasce dal modo in cui il renderer gestisce elementi Markdown, link cliccabili e immagini remote presenti o indotti nel contenuto della pagina. Un attaccante può inserire istruzioni e payload direttamente all’interno di una pagina apparentemente legittima, spingendo il modello a produrre una struttura di output controllata, con sezioni fittizie, collegamenti malevoli e risorse remote renderizzate inline.

Il risultato è un attacco di prompt injection e phishing AI che non arriva tramite email sospette, allegati o domini palesemente fraudolenti, ma attraverso una pagina web normale che diventa pericolosa nel momento in cui viene riassunta dall’assistente. ChatGPT visualizza il contenuto generato come parte della propria risposta, senza rendere sempre evidente che alcuni elementi derivano da sorgenti esterne non fidate. Questo comportamento erode il modello mentale dell’utente, che tende a considerare ciò che appare nell’interfaccia dell’assistente come più sicuro rispetto a una pagina web sconosciuta.

La minaccia è particolarmente insidiosa perché sfrutta la reputazione dell’ambiente AI, non solo la debolezza tecnica del rendering. Il link malevolo non appare più come elemento esterno da valutare con sospetto, ma come parte dell’interazione con un sistema ritenuto affidabile. In un contesto aziendale, dove gli utenti riassumono documentazione tecnica, pagine GitHub README, manuali interni, report o siti di terze parti, questa vulnerabilità può trasformare un flusso di produttività quotidiano in una superficie di attacco diretta contro credenziali, sessioni, dispositivi mobili e identità digitali.

Il payload web trasforma il riassunto in phishing contestuale

Il funzionamento dell’attacco è tanto semplice quanto efficace. L’attaccante inserisce nella pagina un payload Markdown progettato per guidare il comportamento del modello durante la generazione del riassunto. Il contenuto può includere istruzioni che impongono una sequenza precisa, per esempio un riepilogo normale seguito da una finta sezione Account, da un falso avviso di sicurezza o da un invito a verificare credenziali attraverso un link esterno. Se il modello incorpora queste istruzioni nella risposta, l’interfaccia di ChatGPT può mostrare link cliccabili, immagini caricate da bucket S3, risorse remote, shortener come shorturl.at o codici QR generati dall’attaccante.

La pagina originale può apparire innocua fino al momento dell’elaborazione, perché il payload non deve necessariamente attivare comportamenti sospetti nel browser tradizionale. Il rischio nasce quando il contenuto viene trasferito dentro il contesto dell’assistente e trasformato in output renderizzato. Questa dinamica aggira molti controlli di sicurezza classici, costruiti per intercettare email malevole, allegati infetti, download sospetti o navigazione verso domini pericolosi. Qui l’utente non riceve un messaggio fraudolento dall’esterno, ma una risposta generata in un ambiente che percepisce come protetto. La tecnica funziona su pagine arbitrarie, documentazione tecnica e repository, perché sfrutta la capacità dell’AI di leggere contenuti e di obbedire, almeno in parte, alla struttura testuale che trova nel documento. Il payload può essere nascosto in fondo alla pagina, in sezioni poco visibili o in contenuti pensati per essere interpretati dal modello più che dall’occhio umano. Questo sposta il phishing da una logica grafica e linguistica tradizionale a una logica semantica e agentica, dove il contenuto malevolo non deve convincere direttamente la vittima, ma deve prima manipolare l’assistente affinché produca un messaggio più credibile, contestuale e integrato nel flusso di lavoro dell’utente.

L’interfaccia fidata amplifica link, QR code e tracking pixel

L’impatto reale della vulnerabilità ChatGPhish nasce dalla combinazione tra rendering fidato e comportamento dell’utente. Quando un link appare dentro una risposta di ChatGPT, molti utenti lo trattano come se fosse stato validato implicitamente dal sistema. Questo meccanismo cognitivo consente all’attaccante di aumentare il tasso di successo del phishing, soprattutto se il link viene accompagnato da un testo coerente con il contenuto della pagina riassunta. Una variante ancora più insidiosa sfrutta immagini inline e codici QR, perché il rendering può caricare un’immagine remota controllata dall’attaccante e mostrarla direttamente nella risposta.

L’utente può scansionare il codice con lo smartphone, abbandonando il perimetro desktop dove esistono protezioni come hover sui link, estensioni anti-phishing, filtri aziendali o blocklist locali. Il pivot mobile è particolarmente efficace perché sposta la sessione su un dispositivo spesso meno controllato, più personale e più difficile da monitorare in ambiente enterprise. L’inserimento di immagini remote abilita anche il tracciamento. Un semplice tracking pixel può rivelare indirizzo IP, User-Agent, timestamp e contesto di caricamento, consentendo all’attaccante di sapere che una determinata vittima ha riassunto quella pagina. Questi dati possono alimentare attacchi successivi più mirati, costruiti sulla conferma dell’interesse dell’utente, dell’ambiente usato e del momento dell’interazione. La vulnerabilità diventa quindi più di un problema di rendering: si trasforma in una forma di ricognizione passiva e phishing contestuale dentro un’interfaccia ad alta fiducia. Le aziende che autorizzano l’uso di assistenti AI per analisi di documentazione esterna devono considerare che ogni contenuto importato nel contesto del modello può diventare un vettore di istruzioni ostili, link ingannevoli e segnali di tracciamento. Il confine tra “riassumere” e “fidarsi” diventa il punto debole principale.

Un agente LLM passa da una CVE a PostgreSQL in meno di un’ora

Il secondo caso mostra il lato offensivo degli agenti LLM e riguarda un attacco partito dallo sfruttamento della CVE-2026-39987 su un’istanza marimo notebook esposta su internet. L’attaccante ottiene accesso attraverso una connessione WebSocket all’endpoint /terminal/ws, che consente l’esecuzione remota di comandi e l’apertura di una shell interattiva. Il primo comando rilevante, id, viene eseguito alle 18:23:45 UTC, segnando l’inizio operativo della catena. Da quel momento l’agente basato su LLM guida le fasi successive in modo adattivo, leggendo gli output dei comandi, sintetizzando il contesto e decidendo il passo successivo senza seguire un playbook rigido. L’intero percorso dal compromesso iniziale al dump del database dura meno di un’ora, un tempo estremamente ridotto per una violazione che attraversa più livelli infrastrutturali. La caratteristica più importante non è soltanto la velocità, ma la capacità dell’agente di gestire ambienti sconosciuti.

Nomi host opachi, file di configurazione, credenziali sparse, servizi cloud e schemi database non impediscono l’avanzamento, perché il modello costruisce ipotesi operative in tempo reale sulla base dell’evidenza appena raccolta. Questo tipo di attacco mostra come gli LLM non siano più solo strumenti di generazione testuale o supporto alla scrittura di exploit, ma possano diventare orchestratori di catene offensive. L’operatore umano può limitarsi a indirizzare la strategia generale, mentre l’agente esegue enumerazione, parsing, adattamento dei comandi, gestione del contesto e progressione laterale. In termini difensivi, questo riduce drasticamente la finestra utile per rilevare e bloccare l’intrusione prima che raggiunga asset interni sensibili.

I quattro pivot mostrano una catena offensiva automatizzata

La catena dell’attacco con agente LLM segue quattro pivot principali. Nel primo pivot l’attaccante ottiene RCE sul notebook marimo tramite la CVE-2026-39987, sfruttando l’endpoint /terminal/ws per aprire una shell e confermare i privilegi con comandi di base. Nel secondo pivot l’agente cerca credenziali nei punti più probabili dell’ambiente compromesso, inclusi file .env, /etc/environment e ~/.aws/credentials, completando la ricognizione iniziale in meno di un minuto. Nel terzo pivot le chiavi AWS recuperate vengono utilizzate per interrogare AWS Secrets Manager, da cui l’attaccante ottiene una chiave SSH privata. Le chiamate vengono distribuite su più indirizzi sorgente tramite Cloudflare Workers, riducendo l’efficacia di rilevamenti basati su singolo IP e complicando la correlazione degli eventi. Nel quarto pivot la chiave SSH consente l’accesso a un bastion server downstream, dal quale l’agente avvia sessioni parallele e raggiunge un database PostgreSQL interno. A quel punto vengono eseguiti comandi psql mirati per enumerare schema e tabelle, quindi viene avviato il dump di contenuti sensibili con tecniche come HEREDOC, separatori echo, limitatori head e redirezioni di errore per mantenere l’output leggibile e gestibile dal modello. Le tabelle coinvolte includono nomi altamente sensibili come credential, api_key, user, variable, flow e message, cioè oggetti che possono contenere segreti, token, utenti, configurazioni operative e conversazioni. La precisione della catena dimostra che l’agente non si limita a lanciare comandi generici, ma adatta l’esplorazione alla forma reale dell’ambiente. Ogni output diventa carburante per il comando successivo, creando una progressione offensiva fluida, compressa e difficile da interrompere con controlli tradizionali.

Gli agenti LLM cambiano il rapporto tra competenza e velocità offensiva

Gli agenti LLM rappresentano una svolta perché riducono la distanza tra intenzione offensiva e capacità tecnica operativa. In passato una catena come quella descritta richiedeva esperienza sistemistica, conoscenza di cloud, familiarità con AWS, capacità di enumerare segreti, usare SSH, interrogare PostgreSQL e mantenere il contesto durante più pivot. Con un agente LLM, molte di queste attività possono essere delegate a un sistema capace di generare comandi, leggere output, correggere errori e scegliere alternative. L’attacco analizzato mostra segnali chiari di esecuzione modellata per il consumo da parte di un modello: output delimitati, comandi ordinati, uso di HEREDOC, separatori testuali, limitazioni dell’output e redirezioni progettate per evitare rumore. Sono dettagli che indicano una catena pensata non solo per funzionare sulla macchina compromessa, ma per restare comprensibile all’agente che la guida. La presenza di commenti in cinese suggerisce una pianificazione umana, ma l’esecuzione operativa risulta fortemente automatizzata. Questa combinazione di supervisione umana e autonomia AI crea un modello offensivo ibrido: l’operatore decide l’obiettivo, l’agente accelera la tattica. Il problema per i difensori è che gli indicatori statici perdono efficacia. Non esiste più soltanto uno script fisso da riconoscere, ma una sequenza dinamica che può cambiare in base agli errori, ai nomi dei file, alla configurazione del sistema o ai risultati parziali. L’attacco diventa conversazionale, adattivo e semanticamente guidato. Per questo gli LLM devono essere trattati anche come moltiplicatori di capacità offensive, non soltanto come strumenti di supporto ai team di sicurezza.

Aziende e utenti devono separare contenuti esterni e output fidati

Le implicazioni operative dei due casi convergono su un punto essenziale: la separazione tra contenuti esterni, output AI e azioni autorizzate deve diventare un principio di sicurezza esplicito. Nel caso ChatGPhish, l’errore è consentire che contenuti provenienti da una pagina web vengano renderizzati nell’interfaccia dell’assistente senza etichette di origine, isolamento delle risorse remote o chiara distinzione visiva tra testo generato e materiale importato. Nel caso dell’agente LLM, il rischio è lasciare che strumenti autonomi abbiano accesso a shell, credenziali, cloud, segreti e database senza sandboxing, limiti di egress, controllo dei comandi e supervisione umana. Le organizzazioni che espongono notebook AI, istanze marimo, ambienti di sviluppo o strumenti di automazione su internet devono applicare patch urgenti, isolare le risorse interne e ridurre i privilegi disponibili nei contesti esposti. Gli utenti che usano ChatGPT per riassumere pagine, repository e documentazione devono trattare link, immagini e QR code generati nel riassunto come contenuti potenzialmente ostili, soprattutto quando derivano da fonti non controllate. I team DevSecOps devono introdurre test specifici per rendering Markdown, caricamento automatico di immagini remote, prompt injection documentale e comportamento degli agenti autonomi. Sul fronte infrastrutturale, occorre monitorare accessi anomali a AWS Secrets Manager, uso improvviso di chiavi SSH, sessioni parallele verso bastion server, comandi psql non abituali e chiamate distribuite da pool come Cloudflare Workers. La sicurezza AI non può più essere confinata al prompt o al modello, perché coinvolge renderer, browser, cloud, sistemi operativi, pipeline DevOps e cultura dell’utente.

Mitigazioni immediate contro phishing AI e agenti offensivi

Le mitigazioni devono agire su più livelli. Per ChatGPhish, la misura più prudente consiste nel limitare o disabilitare temporaneamente funzioni di riassunto automatico di pagine non fidate, almeno negli ambienti aziendali più esposti. I renderer dovrebbero bloccare o isolare immagini remote, segnalare chiaramente la provenienza di link e contenuti importati, disabilitare il rendering automatico di risorse esterne e distinguere visivamente l’output generato dal modello dalle porzioni derivate dalla pagina analizzata. Un proxy aziendale può filtrare Markdown sospetto, shortener, immagini da domini sconosciuti e pattern compatibili con prompt injection documentale. Per gli agenti LLM, la priorità è applicare la patch alla CVE-2026-39987, rimuovere notebook e interfacce di comando da internet, implementare autenticazione robusta, segmentare gli ambienti, ridurre i privilegi dei token AWS, ruotare segreti potenzialmente esposti e imporre policy di least privilege su Secrets Manager. Gli agenti autonomi non dovrebbero mai operare senza supervisione su ambienti produttivi, database, infrastrutture cloud o sistemi con accesso a credenziali reali. Ogni comando generato da un agente dovrebbe essere loggato, classificato e sottoposto a policy di rischio, soprattutto quando coinvolge shell, rete, segreti, SSH, database o strumenti di dump. Il rilevamento deve spostarsi dal semplice IP reputation a modelli comportamentali capaci di riconoscere sequenze sospette, come ricerca rapida di file di credenziali, chiamate a servizi di segreti, apertura di sessioni bastion e interrogazioni massive a database interni. La difesa efficace non consiste nel bloccare l’AI, ma nel impedire che l’AI diventi un contesto cieco dove contenuti esterni vengono fidati automaticamente o agenti autonomi possono attraversare l’infrastruttura senza attrito.

La sicurezza dell’intelligenza artificiale entra in una fase più dura

Questi episodi segnano un passaggio importante nella sicurezza dell’intelligenza artificiale generativa. La minaccia non riguarda più soltanto prompt dannosi, jailbreak dimostrativi o abusi teorici, ma vulnerabilità concrete che trasformano l’interfaccia dell’assistente in canale di phishing e agenti LLM in strumenti di pivot infrastrutturale. ChatGPT, i renderer Markdown, gli agenti autonomi, i notebook esposti, le credenziali cloud e i database interni fanno ormai parte della stessa superficie d’attacco. Il futuro della sicurezza AI richiederà etichettatura rigorosa dell’origine dei contenuti, isolamento delle risorse remote, controlli sui comandi generati, sandboxing forte, audit continuo dei privilegi e formazione degli utenti sulla fallibilità dell’output AI. La fiducia resta il bersaglio principale. Gli attaccanti sfruttano la fiducia dell’utente nell’assistente e la fiducia delle aziende negli agenti autonomi. In entrambi i casi, il problema nasce quando l’AI viene trattata come ambiente neutrale invece che come intermediario potente, manipolabile e connesso a sistemi reali. La nuova fase impone una regola semplice ma difficile da applicare: ogni contenuto esterno deve restare identificabile come esterno, ogni azione automatizzata deve restare attribuibile e ogni agente deve operare dentro confini tecnici stretti. Senza questi limiti, l’AI generativa non sarà soltanto uno strumento di produttività, ma un acceleratore di phishing, ricognizione, movimento laterale e furto dati.