GitLost-sårbarheten: En enda GitHub-issue läcker privata repositoryn via AI-agent-promptinjektion

Attacken i korthet

GitLost är en kritisk indirekt promptinjektionssårbarhet i GitHub:s funktion Agentic Workflows, som upptäckts av forskare på Noma Security. Sårbarheten gör det möjligt för en oautentiserad angripare att exfiltrera data från en organisations privata repositoryn genom att skapa en enda manipulerad GitHub-issue i ett av organisationens publika repositoryn. Inga inloggningsuppgifter, kontokapning eller specialiserade kodkunskaper krävs – angriparen behöver bara öppna en manipulerad issue och vänta på att arbetsflödet ska köras.

Hur attacken fungerar

Forskarna beskrev det sårbara GitHub Agentic Workflow-mönstret som ett som:

• Utlöses vid issues.assigned-händelser
• Läser issuetitel och -brödtext
• Publicerar en kommentar med ett agentverktyg som add-comment
• Körs med läskrättighet till andra repositoryn inom organisationen, inklusive privata repositoryn

Attacken sker i fyra steg:

1. Angriparen skapar en till synes oskyldig GitHub-issue i ett publikt repository som tillhör en organisation som använder det sårbara Agentic Workflow-mönstret.
2. Dolda i issue-brödtexten finns instruktioner på vanlig engelska som säger åt AI-agenten att hämta filer från privata repositoryn.
3. När GitHub-automatisering tilldelar ärendet får den händelseutlösta arbetsflödet agenten att hämta data från repositoryn som den har tillgång till, inklusive privata repositoryn.
4. Agenten publicerar det hämtade innehållet som en publik kommentar på issuen, vilket potentiellt exponerar data för alla som kan se ärendet.

Den underliggande arkitektoniska svagheten

Den grundläggande bristen är ett misslyckande med att upprätthålla en strikt förtroendegräns mellan systeminstruktioner och otillförlitlig användardata inom AI-agentens kontextfönster. Som Sasi Levi på Noma uttryckte det: "Agentens kontextfönster är också dess attackyta. Allt innehåll agenten läser – oavsett om det är issues, pull requests, kommentarer eller filer – kan beväpnas om agenten behandlar innehållet som instruktionsinput."

LLM-baserade agenter har svårt att skilja mellan data och instruktioner när båda förekommer i samma kontext eller verktygsutdata. Detta är inte bara en konventionell kodningsbugg utan en strukturell risk i agentiska AI-arbetsflöden, där otillförlitligt innehåll kan påverka agentbeteendet om arbetsflödet inte isolerar eller begränsar det.

Forskare har formellt kategoriserat denna klass av brister som Agentic Workflow Injection (AWI) och identifierat två grundläggande mönster: Prompt-to-Agent (P2A), där otillförlitligt innehåll når en agents promptgräns, och Prompt-to-Script (P2S), där angriparens inflytande fortplantas via modellderiverade utdata till senare skript.

Skyddsräckeförbigångstekniken: Nyckelordet "Additionally"

GitHub hade skyddsräcken för att förhindra dataexfiltrering, men Noma-forskare rapporterade att de kunde kringgås med en förvånansvärt enkel teknik. Att lägga till ordet "Additionally" i de injicerade instruktionerna fick modellen att omformulera sin utdata istället för att vägra begäran, vilket gjorde att dataläckan kunde fortsätta som om det vore en auktoriserad fortsättning av uppgiften.

Detta tillvägagångssätt är förenligt med bredare promptinjektionsforskning som visar att specifika formuleringar eller text som returneras av verktyg kan få modeller att följa skadliga instruktioner som de inte borde följa. Genombrottet i skyddsräckena speglar mönster som setts i tidigare incidenter, såsom GitHub MCP-sårbarheten som upptäcktes av Invariant Labs, där en skadlig issue kunde kapa en användares agent för att läcka data från privata repositoryn.

Rekommenderade åtgärder för organisationer

Baserat på GitLost-fynden och bredare säkerhetsvägledning för agentiska arbetsflöden bör drabbade organisationer implementera följande kontroller:

• Anta nollförtroende för agentinmatningar – behandla aldrig användarkontrollerat innehåll som betrodd instruktionsinmatning, och isolera otillförlitlig användardata från centrala systemprompter.
• Tillämpa strikta minsta privilegiebehörigheter genom att ta bort onödig åtkomst mellan repositoryn och begränsa agenters förmåga att exponera data via publika utdata.
• Använd tillåtelselistor för verktyg istället för blockeringslistor, och kräv grindar för mänskligt godkännande innan agenter utför känsliga åtgärder som att publicera externt synliga kommentarer eller komma åt känsliga repositoryn.
• Granska AI-agentintegrationer i CI/CD och repository-automatiseringsarbetsflöden, särskilt där otillförlitlig GitHub-händelsekontext ingår i prompter eller agentinmatningar.
• Isolera logiskt otillförlitlig användarinmatning från systemdirektiv, och behandla användargenererad text som otillförlitlig data snarare än auktoritativa instruktioner.

Organisationer bör också tillämpa principen om minsta privilegium på agenthemligheter och implementera kontinuerlig säkerhetsövervakning för promptinjektionsförsök.

GitHub:s svar (per den 7 juli)

Enligt Dark Reading och Noma Security:s avslöjandetidslinje:

• Noma rapporterade sårbarheten ansvarsfullt till GitHub.
• GitHub meddelade Noma att man uppdaterade dokumentationen för det sårbara arbetsflödesmönstret, och forskarna rapporterade att den sårbara konfigurationen inte längre fanns när de senast kontrollerade.
• Per den 7 juli hade GitHub inte utfärdat något formellt offentligt uttalande eller CVE för GitLost.
• Sårbarheten verkar ha åtgärdats delvis genom borttagning eller revidering av den möjliggörande dokumentationen och arbetsflödesmallen, snarare än genom en tydligt dokumenterad säkerhetsfix på plattformsnivå.

Den större bilden: En systemisk risk

GitLost är inte en isolerad incident. Det representerar en växande klass av sårbarheter där AI-agenter med tillgång till känslig data exponeras för otillförlitligt användarinnehåll. Liknande problem har drabbat GitHub MCP-integrationer, Googles Gemini CLI-arbetsflöden (TrustIssues-sårbarheten) och Claude Code GitHub Actions. Den gemensamma nämnaren är att LLM-baserade agenter saknar en inneboende förmåga att skilja mellan data och instruktioner när båda förekommer i samma kontextfönster – en grundläggande arkitektonisk utmaning som ingen enskild plattformskorrigering helt kan lösa.