Prompt Injection in the Wild

Un tracker delle tecniche di prompt injection segnalate pubblicamente negli ultimi due anni circa, mantenuto da Rachel James (cybershujin).

Ogni tecnica è suddivisa nei tre elementi di una prompt injection:

1. Metodo di delivery — come le istruzioni iniettate raggiungono il modello (il risultato di una tool-call, un sito web esterno, una connessione MCP, un documento, un'email, un'immagine, ecc.).
2. Encoding — l'offuscamento applicato al payload, se presente (Base64, leetspeak, caratteri tag Unicode invisibili, omoglifi, …). Vuoto quando il payload è testo in chiaro o il report non lo specifica.
3. Comportamento di propagazione — se l'injection è progettata per diffondersi o persistere (veicolata a chiunque si connetta a un server MCP avvelenato, persistita nella memoria a lungo termine/di progetto di un agente, trasportata lungo una catena di tool call, fatta emettere un'email contenente ulteriori istruzioni, …). Vuoto quando non c'è propagazione.

Ogni voce registra anche i modelli contro cui è stato confermato che funziona (se presenti), un link alla fonte che lo segnala e — dove noto — la fonte dell'attacco (il ricercatore, il red team o l'attore in-the-wild da cui ha avuto origine).

Dashboard live: https://cybershujin.github.io/Prompt-Injection-in-the-Wild/

---

Ambito e metodologia

• In ambito: tecniche per iniettare istruzioni avversariali in un LLM o in un agente basato su LLM che sono state segnalate pubblicamente — da ricercatori di sicurezza, red team, vendor, o come attività osservata in-the-wild. Sono incluse sia la prompt injection diretta che quella indiretta (veicolata dai dati).
• Fuori ambito: wordlist generiche di jailbreak senza alcun meccanismo di delivery/propagazione, pure lamentele sull'allineamento dei modelli e marketing senza sostanza tecnica.
• Mai ipotizzato. Ogni cella non vuota è tratta da un'affermazione esplicita nella fonte citata. Se un report non indica l'encoding, il comportamento di propagazione, i modelli confermati o la fonte dell'attacco, quella cella viene lasciata vuota — una cella vuota significa "non specificato", mai un "nessuno" dedotto.
• Verifica. Ogni voce è contrassegnata come Confirmed o Not fully vetted. "Not fully vetted" segnala una voce la cui fonte è vaga, non confermata, o il cui meccanismo è poco chiaro — viene evidenziata anziché scartata, così un revisore può valutarla.
• Classe di evidenza — in-the-wild vs. ricerca. Ogni voce è etichettata come In-the-wild (abuso reale osservato o un incidente reale in produzione), Research / red-team (una dimostrazione di un ricercatore di sicurezza o di un red team / responsible disclosure — una tecnica reale e funzionante, ma non osservata come abusata da un attaccante), Vendor advisory o Unclear. Questo è un asse separato dalla verifica: una tecnica può essere Confirmed (verificata e funzionante) ma essere stata dimostrata solo in laboratorio. Attenzione: una genuina prompt injection malevola in-the-wild è ancora raramente documentata pubblicamente, quindi la grande maggioranza delle voci qui presenti sono disclosure di ricerca / red-team — al momento del backfill iniziale, 29 su 32 erano research/red-team e solo 3 erano in-the-wild. Usa il filtro Evidence sulla dashboard per isolare i casi reali.
• Aggiornamenti. Le nuove segnalazioni vengono raccolte mensilmente (Perplexity sonar-deep-research, con una ricerca ampia) e proposte come pull request in bozza per la revisione del maintainer. Nulla viene unito automaticamente. Vedi il tracker gemello Threat-Actors-use-of-Artifical-Intelligence per lo stesso flusso di lavoro applicato all'uso dell'IA da parte dei threat actor.

Come vengono costruiti i dati

I dati risiedono solo nella tabella sottostante (questo file è l'unica fonte di verità). Un generatore deterministico e senza dipendenze (tools/build_exports.py) li compila a ogni commit in:

• index.html — la dashboard interattiva (servita tramite GitHub Pages),
• tracker.json — dati normalizzati leggibili dalla macchina,
• stix/prompt-injection-stix2.1.json — un bundle STIX 2.1 (ogni tecnica come attack-pattern, etichettata con il suo ID MITRE ATLAS e una mappatura Not fully vetted → bassa confidenza).

Non modificare manualmente questi tre file; modifica la tabella e lascia che la CI li ricostruisca.

---

Tecniche