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

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.
2. Gemt i issue-brødteksten ligger instruktioner på almindeligt engelsk, der beder AI-agenten om at hente filer fra private repositories.
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.
4. Agenten poster de hentede data som en offentlig kommentar på issue'et, hvilket potentielt eksponerer dataene for enhver, der kan se issue'et.

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. 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."

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. 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.

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.

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. 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.

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. 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.

Anbefalede afbødningsforanstaltninger for organisationer

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

• Anvend zero-trust for agent-input – behandl aldrig brugerkontrolleret indhold som pålidelige instruktionsinput, og isoler upålidelige brugerdata fra kerne-systemprompter.
• 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.
• 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.
• 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.
• Isolér logisk upålideligt brugerinput fra systemniveaudirektiver, og behandl brugergenereret tekst som upålidelige data frem for autoritative instruktioner.

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

GitHub's svarstatus (pr. 7. juli)

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

• Noma afslørede ansvarligt fejlen til GitHub.
• 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.
• Pr. 7. juli havde GitHub ikke udstedt en formel offentlig erklæring eller CVE for GitLost.
• 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.

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. 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.