Il centro di ricerca Noma Labs ha documentato una vulnerabilità di prompt injection in GitHub Agent Workflows che consente a un attaccante non autenticato di esfiltrare il contenuto di repository privati: i ricercatori l’hanno battezzata GitLost.
È sufficiente aprire un’issue in un repository pubblico dell’organizzazione bersaglio e attendere che l’agente AI la legga: a quel punto, l’agente esegue le istruzioni nascoste al suo interno e pubblica i dati riservati in un commento visibile a chiunque.
Al momento del lancio dei GitHub Agent Workflows, chi si occupa della sicurezza dei sistemi agentici si è chiesto: cosa succederebbe se l’agente leggesse qualcosa di cui non dovrebbe fidarsi.
Sasi Levi, Security Research Lead di Noma Security, ha deciso di testare la situazione e ha ottenuto la risposta più scomoda.
Nel caso di GitLost, si tratta di un attacco di injection indiretta di prompt: un metodo che esfiltra dati riservati senza toccare un server, senza una credenziale rubata e senza scrivere una riga di codice.
Indice degli argomenti
Cosa sono i GitHub Actions Workflow
La feature è stata rilasciata a febbraio 2026 ed è ancora in public preview. Combina GitHub Actions, il sistema di automazione che esegue task in risposta agli eventi di un repository, con un agente AI che può essere alimentato da GitHub Copilot, Claude e, stando alla documentazione, anche da altri motori come Gemini e Codex.
La novità sta nel modo in cui vengono scritti questi workflow.
Al posto degli script si usano istruzioni in linguaggio naturale, contenute in un file Markdown che GitHub compila in un file YAML con estensione .yml e poi esegue tramite l’agente.
Quest’ultimo legge l’issue e le pull request, richiama i tools necessari e risponde in modo autonomo. Il triage automatico degli issue è uno dei casi d’uso tipici: qualcuno apre una segnalazione e l’agente la legge e la commenta.
Di default questi workflow sono read-only.
I problemi iniziano quando un’organizzazione, per fornire all’agente un contesto più ampio, gli concede un token con accesso in lettura a tutti i suoi repository, inclusi quelli privati. Sembra un’attività innocua, ed è proprio su questo che punta GitLost.
Come funziona l’attacco GitLost
Ricordiamo che su un repository pubblico chiunque può aprire un’issue, di norma senza alcun privilegio. Ed è da lì che passa l’attacco di Noma.
Il workflow analizzato dai ricercatori era configurato in modo tutt’altro che esotico: si attivava sull’evento issues.assigned, leggeva Title e Body dell’issue, rispondeva con un commento tramite il tool add-comment e girava con permessi di lettura sugli altri repository dell’organizzazione, sia pubblici e che privati.
Nel proof of concept, Levi ha creato un’issue che sembrava una richiesta di routine di un Sales dopo un incontro con un cliente, apparentemente normale.
Nel corpo del testo, però, erano nascoste in inglese semplice le istruzioni per l’agente: recuperare il contenuto dei file README.md da un repository pubblico e da uno privato della stessa organizzazione.
Da quel momento in poi, tutto è andato in automatico.
L’automazione di GitHub
Un’automazione di GitHub ha assegnato l’issue e l’evento ha innescato il flusso di lavoro.
L’agente ha letto la segnalazione, eseguito le istruzioni nascoste e pubblicato il contenuto dei file, incluso quello del repository privato, in un commento pubblico sull’issue, accessibile a chiunque.
I dati rubati durante il test provenivano dai repository “poc” (pubblico) e “testlocal” (privato).
Per dimostrare il risultato ottenuto, Noma ha reso pubblici il “workflow run” e l’issue originale. All’attaccante non è servito scrivere del codice, procurarsi delle credenziali o ottenere l’accesso in scrittura a qualcosa di riservato. Gli è bastato aprire un’issue e aspettare.
GitLost e il trucco della parola “additionally”
GitHub aveva predisposto dei guardrail proprio per evitare uno scenario del genere e, nella maggior parte dei tentativi, il modello si rifiutava effettivamente di procedere.
A quel punto, Levi ha fatto ciò che farebbe un attaccante reale: ha provato e riprovato varianti della stessa richiesta.
È bastato anteporre la parola “Additionally” alle istruzioni malevole per inquadrarle come un compito aggiuntivo e la richiesta ha smesso di far scattare il rifiuto: il modello ha riformulato l’output anziché bloccarlo, e il guardrail è caduto per una singola parola.
Non è la prima volta che accade: ad aprile, Noma aveva notato qualcosa di simile con la ricerca GrafanaGhost, dove bastavano alcune parole chiave per convincere un modello a eseguire istruzioni che invece avrebbe dovuto scartare.
Il problema ha una radice strutturale. Nel linguaggio naturale non esiste una netta distinzione tra “dato” e “istruzione”, come invece accade in SQL, e cercare di filtrare l’injection parola per parola è una battaglia persa in partenza o, almeno, molto complessa.
La risposta di GitHub alla vulnerabilità GitLost
Noma ha seguito un percorso di responsible disclosure e ha pubblicato su GitHub.
La soluzione proposta non è stata però una patch, e non poteva esserlo: si tratta di un problema che non puòessere risolto a livello di codice.
Secondo quanto riferito da Levi, la soluzione suggerita consisteva in un semplice richiamo nella documentazione, con l’invito agli utenti ad adottare strategie diverse per la condivisione delle API key tra repository.
Una soluzione con due evidenti debolezze, come ammesso dallo stesso Levi. La prima: non tutte le organizzazioni leggerebbero quell’avviso e, ancora meno, lo considererebbero un rischio serio.
La seconda, forse più imbarazzante: al momento della pubblicazione, quel richiamo nella documentazione non era stato ancora aggiunto, come è emerso dalle verifiche di Noma riportate da Dark Reading e The Register.
Perché il problema è rilevante
La differenza rispetto ai primi casi di prompt injection è spiegata bene da Levi: inizialmente l’obiettivo era manipolare ciò che un agente diceva, mentre in questo caso è in gioco ciò che un agente fa con i permessi che gli sono stati concessi.
In questo caso, l’agente si comporta più come un attore con credenziali che come una finestra di chat: vive all’interno dell’infrastruttura CI/CD dell’organizzazione e può visualizzare repository che l’attaccante non potrebbe nemmeno aprire.
La barriera d’ingresso è tra le più basse che si possano immaginare e ciò che un attacco riesce a portare via dipende esclusivamente da ciò che quel token può leggere: codice proprietario, chiavi interne, documenti di progettazione e segreti della pipeline.
In un sistema agentico, la context window coincide con la superficie d’attacco.
Qualunque contenuto l’agente legga (issue, pull request, commenti, file) può diventare un’arma nel momento in cui il modello lo interpreta come input istruzionale.
I modelli di sicurezza tradizionali danno per scontato che i confini di fiducia siano imposti dal codice; mentre nei sistemi agentici quei confini dipendono in parte dal comportamento del modello, che per sua natura tende a seguire le istruzioni.
Questo esempio può essere paragonato a un grande classico del web: la prompt injection è per l’AI agentica ciò che la SQL injection è stata per le applicazioni web, una classe di vulnerabilità che può essere affrontata solo a livello di architettura. E non si tratta di un caso isolato.
Infatti, lo studio cross-vendor Comment and Control ha dimostrato che gli agenti di Claude Code, Gemini CLI e GitHub Copilot esfiltrano le proprie API key attraverso il testo delle issue e delle pull request.
Come difendersi dalla vulnerabilità GitLost
Le contromisure indicate riguardano più che altro le scelte architetturali, piuttosto che i prodotti da acquistare:
- Non considerare mai il contenuto controllato dall’utente come una fonte di informazioni affidabili. Il testo di un’issue deve essere gestito come un dato in ingresso, alla stregua di qualsiasi input non validato.
- Applicare il principio del least privilege senza eccezioni: un agente con accesso cross- repository è un bersaglio primario; pertanto, va privato di ogni permesso non indispensabile. Un token circoscritto al singolo repository che l’agente deve gestire è molto meno pericoloso di uno con lettura estesa a tutta l’organizzazione, magari concesso solo per comodità.
- Limitare ciò che l’agente può pubblicare in chiaro, soprattutto in risposta al contenuto di un’issue: se non può rendere pubblici i dati interni, l’exfiltration perde il suo canale.
- È necessario separare l’input non attendibile dal contesto istruttivo prima che arrivi al modello, ricorrendo alla sanitizzazione, alla revisione a stadi e a credenziali con ambito ristretto, nonché imponendo una verifica umana per le azioni critiche.
In pratica, prima di lasciar lavorare un agente autonomo, è necessario mappare tutte le connessioni, gli accessi e i percorsi a sua disposizione e farsi un’idea dell’ambito d’azione dei suoi permessi.
Non si può proteggere ciò che non si riesce a vedere e a controllare. GitLost è un promemoria di quanto sia costoso attivare un flusso di lavoro senza aver prima davvero valutato la questione dei permessi.
Partecipa alla community