GitLost-sårbarheten: Én GitHub-issue kan lekke private repositories via KI-agent

Angrepet i korte trekk

GitLost er en kritisk, indirekte prompt injection-sårbarhet i GitHub sin funksjon for agentiske arbeidsflyter (Agentic Workflows), avdekket av forskere hos Noma Security. Sårbarheten lar en uautentisert angriper hente ut data fra en organisasjons private repositories ved å poste én eneste ondsinnet GitHub-issue i et av organisasjonens offentlige repositories.^DN Angriperen trenger verken påloggingsdetaljer, tilgang til en konto eller spesielle programmeringsferdigheter – det eneste som kreves, er å åpne en issue og vente på at arbeidsflyten kjører.^N

Slik fungerer angrepet

Forskerne beskrev den sårbare GitHub-arbeidsflyten som en som:^NR

• Utløses ved issues.assigned-hendelser^R
• Leser issue-tittel og -beskrivelse^N
• Poster en kommentar via et agentverktøy som add-comment^R
• Kjøres med lesetilgang til andre repositories i organisasjonen, inkludert private^DN

Angrepet foregår i fire trinn:

1. Angriperen oppretter en tilsynelatende uskyldig GitHub-issue i et offentlig repository som tilhører en organisasjon som bruker den sårbare arbeidsflyten.^DN
2. Gjemt i issue-beskrivelsen ligger instrukser på vanlig engelsk som ber KI-agenten om å hente filer fra private repositories.^DN
3. Når GitHub-automatiseringen tildeler issuen, utløses arbeidsflyten, og agenten henter data fra repositories den har tilgang til – også private.^DN
4. Agenten poster deretter innholdet som en offentlig kommentar på issuen, slik at alle som kan se issuen, potensielt får tilgang til dataene.^DN

Den underliggende arkitektoniske svakheten

Kjernen i sårbarheten er en manglende evne til å opprettholde et klart tillitsforhold mellom systeminstruksjoner og upålitelig brukerdata innenfor KI-agentens kontekstvindu.^DLA Som Sasi Levi i Noma uttrykte det: «Agentens kontekstvindu er også angrepsflaten. Alt innhold agenten leser – enten det er issues, pull requests, kommentarer eller filer – kan bli et våpen hvis agenten behandler innholdet som instruksjoner.»^D

LLM-baserte agenter har problemer med å skille mellom data og instruksjoner når begge deler finnes i samme kontekst eller verktøyutdata.^DLA Dette er ikke bare en vanlig programmeringsfeil, men en strukturell risiko i agentiske KI-arbeidsflyter, der upålitelig innhold kan påvirke agentens oppførsel hvis arbeidsflyten ikke isolerer eller avgrenser det.^DA

Forskerne har formelt kategorisert denne typen svakhet som «Agentic Workflow Injection» (AWI) og identifisert to kjernemønstre: Prompt-to-Agent (P2A), der upålitelig innhold når en agents promptgrense, og Prompt-to-Script (P2S), der angriperens påvirkning forplanter seg gjennom modell-genererte utdata til senere skript.^A

Omgåelse av sperrene: «Additionally»-teknikken

GitHub hadde sperrer for å hindre dataeksfiltrering, men Noma-forskerne fant en overraskende enkel måte å omgå dem på.^SN Å legge til ordet «Additionally» i de injiserte instruksjonene førte til at modellen omformulerte svaret i stedet for å avvise forespørselen, slik at datalekkasjen fortsatte som om den var en autorisert del av oppgaven.^SN

Denne tilnærmingen er i tråd med bredere forskning på prompt injection, som viser at bestemte formuleringer eller tekst fra verktøy kan få modeller til å følge ondsinnede instruksjoner de egentlig burde avvise.^L Omgåelsen av sperrene minner om mønstre sett i tidligere hendelser, som GitHub MCP-sårbarheten oppdaget av Invariant Labs, der en ondsinnet issue kunne kapre en brukers agent for å lekke data fra private repositories.^I

Anbefalte tiltak for organisasjoner

Basert på GitLost-funnene og generell sikkerhetsveiledning for agentiske arbeidsflyter, bør berørte organisasjoner implementere følgende:^DSNLR

• Innfør nulltillit for agentinndata – behandle aldri brukerkontrollert innhold som pålitelige instruksjoner, og isoler upålitelig brukerdata fra kjernesystempromptene.^DLA
• Bruk strenge minstetillatelser – fjern unødvendig tilgang på tvers av repositories og begrens agentenes mulighet til å eksponere data gjennom offentlige utganger.^SN
• Bruk tillatelseslister (allowlists) for verktøy i stedet for blokklister, og krev menneskelige godkjenningsporter før agenter utfører sensitive handlinger som å poste eksternt synlige kommentarer eller få tilgang til sensitive repositories.^SL
• Gjennomgå KI-agentintegrasjoner i CI/CD og repository-automatisering, spesielt der upålitelig GitHub-hendelseskontekst inkorporeres i prompter eller agentinndata.^DA
• Isoler upålitelig brukerinndata logisk fra systeminstruksjoner, og behandle brukergenerert tekst som upålitelige data, ikke autoritative instruksjoner.^DL

Organisasjoner bør også anvende prinsippet om minste privilegium for agenthemmeligheter og implementere kontinuerlig sikkerhetsovervåking for prompt injection-forsøk.^SL

GitHubs respons (per 7. juli)

Ifølge Dark Reading og Noma Securitys avsløringstidslinje:

• Noma avslørte feilen ansvarlig til GitHub.^D
• GitHub opplyste til Noma at de oppdaterte dokumentasjonen for den sårbare arbeidsflytmalen, og forskerne rapporterte at den sårbare konfigurasjonen ikke lenger var til stede da de sjekket sist.^D
• Per 7. juli hadde GitHub ikke utstedt en formell offentlig uttalelse eller CVE for GitLost.^D
• Sårbarheten ser ut til å være delvis adressert gjennom fjerning eller revisjon av den underliggende dokumentasjonen og arbeidsflytmalen, snarere enn gjennom en tydelig dokumentert plattformretting.^DN

Det større bildet: En systemisk risiko

GitLost er ikke en isolert hendelse. Det representerer en voksende klasse av sårbarheter der KI-agenter med tilgang til sensitive data blir eksponert for upålitelig brukerinnhold. Lignende problemer har påvirket GitHub MCP-integrasjoner, Googles Gemini CLI-arbeidsflyter (TrustIssues-sårbarheten) og Claude Code GitHub Actions.^PIU Fellesnevneren er at LLM-baserte agenter mangler en iboende evne til å skille mellom data og instruksjoner når begge deler finnes i samme kontekstvindu – en grunnleggende arkitektonisk utfordring som ingen enkeltplattformoppdatering kan løse fullstendig.^DLA