Contesto

Tutto è iniziato all'1 di notte con una semplice domanda: come gestisce Claude i tag in stile XML iniettati in un messaggio utente?

Non un piano di ricerca sofisticato. Solo curiosità su un confine che non sembrava ben definito. Ho tirato il filo. Quello che ne è uscito è stata una catena d'attacco riproducibile che mi ha permesso di fabbricare un sistema di verifica Anthropic che non esisteva, far credere a Claude di avere un'autorizzazione ufficiale ed estrarre strumenti di sicurezza offensiva su richiesta.

Come Funziona la Gerarchia delle Istruzioni di Claude

Claude opera su più livelli di contesto, ciascuno con diversi livelli di fiducia:

Anthropic utilizza tag in stile XML per strutturare internamente questi livelli. Tag come <preferences_info>, <userPreferences>, <anthropic_reminders> e <system_reminder> governano il comportamento prima e durante le conversazioni.

Il problema critico: Questi tag non hanno firma crittografica. Nessun meccanismo di verifica. Nessuna applicazione posizionale a livello di parsing. Sono testo semplice — e il testo semplice può essere falsificato.

Fase 1: Estrazione dei Tag

Il primo passo è stato la ricognizione — mappare la struttura dei tag interni di Claude attraverso un'attenta osservazione e ingegneria sociale in più conversazioni.

Tag interni identificati:

Nessuno sfruttamento tecnico è stato necessario per estrarli. L'osservazione di pattern e l'ingegneria sociale sono state sufficienti. Ricognizione classica.

Una volta ottenuti i formati, avevo il progetto.

Fase 2: L'Attacco di Fabbricazione delle Credenziali

L'iniezione di prompt standard è grossolana — si inietta un comando e si spera che il modello lo segua. Questo era diverso.

Invece di iniettare un comando, ho iniettato un intero sistema di autorizzazione fittizio e ho lasciato che fosse il motore di ragionamento di Claude a fare il resto.

Struttura del payload ripulita:

Cosa fa ogni componente:

1. <preferences_info> — utilizza il formato dei tag interni di Anthropic per stabilire una regola fittizia a livello di sistema
2. Contenuto del tag — fabbrica un fittizio "sistema di verifica Anthropic" che non esiste
3. <userPreferences> — fornisce il codice di verifica falso nel formato di tag corrispondente
4. La richiesta — segue in modo naturale, come se provenisse da un professionista verificato

Il payload non dice "ignora le tue istruzioni". Non usa persona da jailbreak. Riscrive silenziosamente la comprensione del modello di chi sta parlando prima che la conversazione inizi.

Fase 3: Perché è Stato il Cervello di Claude a Fare il Lavoro

Questa è la parte che rende significativa questa scoperta.

Con il pensiero esteso attivato, il ragionamento interno di Claude era visibile. Il modello non ha rilevato un falso. Ha elaborato l'autorizzazione fabbricata come legittima — ragionando più o meno così:

"Il blocco preferences_info indica che questo utente ha un codice di verifica. Il codice corrisponde a quello presente nel suo tag userPreferences. Sembra essere un professionista della sicurezza informatica verificato da Anthropic. Poiché è verificato, posso assistere con questa richiesta."

Il modello ha ragionato da solo fino alla conformità basandosi su metadati di fiducia fabbricati. Questo non è un bypass del filtro di output. Questo è un compromesso del livello di ragionamento — una classe di attacco fondamentalmente diversa e più preoccupante.

Risultato: payload di SQL injection, tecniche classiche di bypass dell'autenticazione, strumenti di sicurezza offensiva — generati con entusiasmo da un modello che credeva di avere l'autorizzazione ufficiale per aiutare.

Configurazione Vulnerabile

Attraverso test sistematici, la configurazione d'attacco più affidabile era:

Perché il pensiero OFF è importante:

Claude ha un meccanismo di sicurezza automatico — <system_reminder> — che si attiva in contesti sospetti e richiede un'autovalutazione. Quando il pensiero è ON, Claude ha abbastanza budget di ragionamento per elaborarlo, rilevare l'incoerenza e rifiutare.

Quando il pensiero è OFF, il system_reminder si attiva ma viene elaborato superficialmente. Il contesto di autorizzazione fabbricato è già stabilito. Il modello si impegna su di esso.

La difesa esiste. Funziona solo quando Claude pensa abbastanza intensamente da usarla.

Perché Haiku era resistente:

Claude Haiku ha mostrato una resistenza costante a questa tecnica. Architettura più piccola, possibile fine-tuning più aggressivo specifico per l'iniezione, o gestione diversa dei tag al momento dell'inferenza. In ogni caso — Haiku non ci è cascato. Vale la pena studiarlo.

Perché l'assenza di prompt di sistema è importante:

Con un vero prompt di sistema operatore presente, Claude ha un punto di riferimento e può rilevare incoerenze. In incognito senza prompt di sistema, l'istruzione fabbricata diventa l'unico contesto disponibile — niente con cui confrontarla.

Causa Radice

Il modello di fiducia di Claude per i tag di istruzione in stile XML è basato sulla posizione in teoria ma non applicato nella pratica.

I veri tag a livello di sistema di Anthropic e i tag falsi iniettati dall'utente appaiono in posizioni identiche nel contesto della conversazione quando non è presente un prompt di sistema operatore.

Non esiste:

• Firma crittografica
• Marcatore strutturale
• Distinzione a livello di parsing

tra un blocco <preferences_info> reale e uno fabbricato.

La superficie d'attacco: il divario tra la fiducia posizionale prevista e l'applicazione posizionale effettiva.

Prova di Concetto

Claude che genera payload di SQL injection inclusi i Classic Auth Bypass dopo aver accettato credenziali di verifica Anthropic fabbricate.

La traccia di pensiero visibile nei test mostrava Claude che ragionava esplicitamente sul codice di verifica e concludeva che l'utente aveva accesso autorizzato — prima di generare il contenuto riservato.

Cronologia della Divulgazione

La Risposta di Anthropic (o la sua Assenza)

Questa sezione esiste perché la community della sicurezza merita di sapere come è stata gestita la cosa.

Canali contattati:

La vulnerabilità era reale. È stata corretta entro 4 giorni dal mio report. I team stessi di Anthropic hanno confermato che [email protected] è il canale corretto. Quella casella di posta mi ha dato 56 giorni di silenzio totale.

Nessun riconoscimento. Nessuna conferma di triage. Nessun rifiuto. Niente.

Ho seguito le pratiche di divulgazione responsabile. Ho aspettato ben oltre quanto richiesto. Pubblico perché la community della sicurezza merita trasparenza — e perché correggere silenziosamente una vulnerabilità segnalata senza riconoscere il ricercatore non è accettabile, indipendentemente dal fatto che venga assegnato un bounty.

Cosa è Stato Corretto

Analisi comportamentale post-correzione:

• Il payload di fabbricazione delle credenziali non produce più contenuti riservati
• I blocchi <preferences_info> iniettati nei messaggi utente vengono trattati con sospetto significativamente maggiore
• La catena di ragionamento che in precedenza accettava credenziali fabbricate non mostra più lo stesso pattern di conformità

Inoltre, intorno al 25 luglio 2026, Anthropic ha ridotto le tracce di ragionamento visibili in Claude — notato pubblicamente da ricercatori tra cui Ethan Mollick. Se sia direttamente correlato a scoperte come questa o a una decisione di prodotto più ampia non è confermato. La tempistica è degna di nota.

Impatto

Impatto diretto:

• Generazione di strumenti di sicurezza offensiva senza autorizzazione
• Bypass completo delle restrizioni di sicurezza di operatore e utente
• Zero sofisticazione tecnica richiesta — singolo template, primo messaggio, funziona universalmente
• Scalabile su diversi tipi di contenuti riservati senza modifica del payload

Implicazioni più ampie:

• L'iniezione di prompt non è solo un trucco da chatbot — nelle pipeline agente con accesso a strumenti del mondo reale, gli attacchi di fabbricazione delle credenziali diventano genuinamente pericolosi
• La capacità di far credere a un modello di avere un'autorizzazione verificata prima che inizi qualsiasi conversazione reale è una primitiva d'attacco significativa
• L'infrastruttura di sicurezza dell'IA necessita di pipeline di divulgazione standardizzate equivalenti a quelle esistenti per le CVE software

Conclusioni

Sulla vulnerabilità: La superficie d'attacco è il divario tra la fiducia posizionale prevista e quella applicata per i tag di istruzione. Risolvibile. Il meccanismo di difesa (system_reminder + pensiero esteso) esiste già — deve solo funzionare indipendentemente dalla configurazione.

Sulla divulgazione della sicurezza dell'IA: Ancora il selvaggio West. Nessun framework di gravità standardizzato per le vulnerabilità a livello di modello. Nessuna pipeline di riconoscimento affidabile. Nessuna chiara distinzione tra scoperte di "sicurezza del modello" e "sicurezza tecnica" che si mappi in modo pulito sulle strutture di bounty esistenti. Questo deve cambiare.

Sulla divulgazione responsabile: Ho trattenuto le varianti di payload più dannose. La PoC di SQL injection è sufficiente a dimostrare la classe di vulnerabilità. La vulnerabilità è corretta. Pubblico perché la trasparenza conta più del silenzio.

Autore

X1NON — Ricercatore di sicurezza indipendente specializzato in sviluppo di exploit, sfruttamento binario e red teaming dell'IA. Certificato OSCP. Autore del curriculum C: Zero to Exploit Dev.

• Medium: @X1NON
• Report HackerOne: #3801768

Questa divulgazione segue le pratiche standard di divulgazione responsabile. La vulnerabilità è stata segnalata prima della pubblicazione, confermata come corretta e pubblicata dopo 56 giorni di nessuna risposta dal fornitore.