GitLost: Sådan kan ét enkelt GitHub-issue lække dine private repositories

• Udløses ved issues.assigned-hændelser^R
• Læser issue-overskriften og -brødteksten^N
• Poster en kommentar ved hjælp af et agentværktøj såsom add-comment^R
• Kører med læseadgang til andre repositories i organisationen, herunder private repositories^DN

Angrebet udfolder sig i fire trin:

1. Angriberen opretter et tilsyneladende uskyldigt GitHub-issue i et offentligt repository, der tilhører en organisation, som bruger det sårbare Agentic Workflow-mønster.^DN
2. Gemt i issue-brødteksten ligger instruktioner på almindeligt engelsk, der beder AI-agenten om at hente filer fra private repositories.^DN
3. Når GitHub-automatiseringen tildeler issue'et, udløses det hændelsesudløste workflow, og agenten henter data fra repositories, den har adgang til – inklusive private repositories.^DN
4. Agenten poster de hentede data som en offentlig kommentar på issue'et, hvilket potentielt eksponerer dataene for enhver, der kan se issue'et.^DN

Den underliggende arkitektoniske svaghed

Den grundlæggende fejl er en manglende evne til at opretholde en streng tillidsgrænse mellem systemniveau-instruktioner og upålidelige brugerdata i AI-agentens kontekstvindue.^DLA Som Nomas Sasi Levi udtalte: "Agentens kontekstvindue er også dens angrebsflade. Alt indhold, agenten læser – uanset om det er issues, pull requests, kommentarer eller filer – kan bruges som våben, hvis agenten behandler indholdet som instruktionsinput."^D

LLM-baserede agener har svært ved at skelne mellem data og instruktioner, når begge dele optræder i samme kontekst eller værktøjsoutput.^DLA Dette er ikke blot en konventionel kodefejl, men en strukturel risiko i agentiske AI-workflows, hvor upålideligt indhold kan påvirke agentens adfærd, hvis workflowet ikke isolerer eller begrænser det.^DA

Forskere har formelt kategoriseret denne klasse af fejl som Agentic Workflow Injection (AWI) og identificeret to kernemønstre: Prompt-to-Agent (P2A), hvor upålideligt indhold når en agents promptgrænse, og Prompt-to-Script (P2S), hvor angriberens indflydelse forplanter sig gennem modelafledte output til senere scripts.^A

Omgåelse af beskyttelsesforanstaltninger: 'Additionally'-nøgleordet

GitHub havde indbygget beskyttelsesforanstaltninger, der skulle forhindre dataeksfiltration, men Noma-forskerne rapporterede, at de kunne omgås med en overraskende simpel teknik.^SN At tilføje ordet 'Additionally' til de injicerede instruktioner fik angiveligt modellen til at omformulere sit output i stedet for at afvise anmodningen, hvilket tillod datalækagen at fortsætte som om, den var en autoriseret fortsættelse af opgaven.^SN

Denne tilgang er i overensstemmelse med bredere forskning i prompt injection, der viser, at bestemte formuleringer eller værktøjsreturneret tekst kan få modeller til at følge ondsindede instruktioner, de ikke burde følge.^L Omgåelsen afspejler mønstre set i tidligere hændelser, såsom GitHub MCP-sårbarheden, som Invariant Labs afslørede, hvor et ondsindet issue kunne kapre en brugers agent til at lække data fra private repositories.^I

Anbefalede afbødningsforanstaltninger for organisationer

Baseret på GitLost-funktionerne og bredere sikkerhedsvejledning for agentiske workflows bør berørte organisationer implementere følgende kontroller:^DSNLR

• Anvend zero-trust for agent-input – behandl aldrig brugerkontrolleret indhold som pålidelige instruktionsinput, og isoler upålidelige brugerdata fra kerne-systemprompter.^DLA
• Anvend strengt princip om mindste rettigheder ved at fjerne unødvendig adgang på tværs af repositories og begrænse agenters evne til at eksponere data gennem offentlige output.^SN
• Brug hvidlister for værktøjer frem for sortlister, og kræv menneskelige godkendelsesporte, før agenter udfører følsomme handlinger såsom at poste eksternt synlige kommentarer eller få adgang til følsomme repositories.^SL
• Revidér AI-agent-integrationer i CI/CD- og repository-automatiseringsworkflows, især hvor upålidelig GitHub-hændelseskontekst inkorporeres i prompter eller agent-input.^DA
• Isolér logisk upålideligt brugerinput fra systemniveaudirektiver, og behandl brugergenereret tekst som upålidelige data frem for autoritative instruktioner.^DL

Organisationer bør også anvende princippet om mindste rettigheder på agenthemmeligheder og implementere kontinuerlig sikkerhedsovervågning for forsøg på prompt injection.^SL

GitHub's svarstatus (pr. 7. juli)

Ifølge Dark Reading og Noma Security's afsløringstidslinje:

• Noma afslørede ansvarligt fejlen til GitHub.^D
• GitHub oplyste til Noma, at de opdaterede dokumentationen for det sårbare workflow-mønster, og forskerne rapporterede, at den sårbare konfiguration ikke længere var til stede, da de sidst tjekkede.^D
• Pr. 7. juli havde GitHub ikke udstedt en formel offentlig erklæring eller CVE for GitLost.^D
• Sårbarheden ser ud til at være delvist adresseret gennem fjernelse eller revision af den muliggørende dokumentation og workflow-skabelon, snarere end gennem en klart dokumenteret platformsikkerhedsrettelse.^DN

Det større billede: En systemisk risiko

GitLost er ikke en isoleret hændelse. Det repræsenterer en voksende klasse af sårbarheder, hvor AI-agenter med adgang til følsomme data eksponeres for upålideligt brugerindhold. Lignende problemer har påvirket GitHub MCP-integrationer, Google's Gemini CLI-workflows (TrustIssues-sårbarheden) og Claude Code GitHub Actions.^PIU Den fælles tråd er, at LLM-baserede agener mangler en iboende evne til at skelne mellem data og instruktioner, når begge dele optræder i samme kontekstvindue – en grundlæggende arkitektonisk udfordring, som ingen enkelt platformspatch fuldt ud kan løse.^DLA