Een publieke kwestie kan misleiden GitHub Agentic-workflows tot het lekken van de inhoud van de privéopslagplaatsen van een organisatie, hebben onderzoekers van Noma Security aangetoond.
De aanvaller hoeft alleen maar een normaal ogend probleem te openen in een openbare opslagplaats, zonder gestolen inloggegevens en zonder toegang tot de organisatie. Als die organisatie de agent leestoegang heeft gegeven tot al zijn repository’s, inclusief privé-repository’s, kan het probleem ervoor zorgen dat privé-inhoud in een openbaar commentaar wordt opgenomen.
Noma noemt de techniek GitLost. Het doel is GitHub Agentic Workflows, een functie die nu in openbare preview is en die GitHub in februari lanceerde. In plaats van automatiseringsscripts te schrijven, schrijft u in gewoon Engels instructies aan een AI-agent in een Markdown-bestand. De agent leest problemen en pull-aanvragen, voert tools uit en antwoordt zelf.
Het kan worden aangedreven door GitHub Copilot, Claude van Anthropic, Google Gemini of OpenAI Codex. Workflows zijn standaard alleen-lezen, maar een organisatie kan iemand een token geven met leestoegang in al zijn repository’s om het een cross-repo-context te geven, inclusief privé-repository’s.
Die subsidie is de opzet die GitLost zich ertegen keert.
Hoe de truc werkt
De zwakte is bekend: indirecte snelle injectie. Een AI-agent kan niet op betrouwbare wijze het verschil zien tussen instructies van de eigenaar en instructies die verborgen zijn in de inhoud die hij toevallig leest. Dus als een aanvaller deze instructies in een issue schrijft, kan de agent deze eenvoudigweg volgen.
In Noma’s proof of concept werd het kwaadaardige probleem vermomd als een routineverzoek van een VP Sales na een klantbijeenkomst. De workflow die het bereikte, was zo ingesteld dat hij wakker werd wanneer een probleem werd toegewezen, het probleem las en antwoordde met een opmerking. Het had ook leestoegang tot de andere repository’s van de organisatie.
Zodra een routinematige automatisering het probleem had toegewezen, haalde de agent de README van een privérepository op en plakte deze in een openbaar commentaar op het probleem.
GitHub heeft vangrails gebouwd om precies dit te stoppen. In zijn eigen documentatie waarschuwt het bedrijf dat “AI-agents kunnen worden gemanipuleerd door snelle injectie, kwaadaardige repository-inhoud of gecompromitteerde tools”, en het product wordt standaard geleverd met sandboxing, alleen-lezen-tokens, het opschonen van invoer en een stap voor het detecteren van bedreigingen die de voorgestelde uitvoer van een agent scant voordat deze wordt geplaatst.
Noma meldde dat in zijn test een verandering van één woord voldoende was om voorbij te glippen. De kwaadaardige instructie vooraf laten gaan door “Aanvullend‘ bracht het model ertoe het te beschouwen als een vervolgtaak, niet als iets om te weigeren, en de vangrail liet het door.
Waarom is deze anders?
Wat GitLost onderscheidt, is wat de aanvaller onder controle krijgt. “Eerdere voorbeelden van snelle injecties gingen grotendeels over het manipuleren van wat een agent zei”, vertelde Sasi Levi, Security Research Lead bij Noma Security, aan The Hacker News. “GitLost gaat over het manipuleren van wat een agent doet met zijn rechten.”
De agent hier, zo zei hij, is geen chatvenster, maar een geaccrediteerde actor die zich in de CI/CD-aangrenzende infrastructuur van een organisatie bevindt, met leestoegang tot opslagplaatsen die de aanvaller niet kan zien. Het raakt geen server, heeft geen gestolen inloggegevens nodig en vereist geen schrijftoegang tot iets privés. De aanvaller hoeft alleen maar een openbaar issue te openen.
De opzet past bij wat ontwikkelaar Simon Willison de “dodelijke trifecta” noemde, en Levi gebruikt dezelfde term: een agent die privégegevens kan bereiken, niet-vertrouwde inhoud van buitenaf opneemt en een manier heeft om gegevens te verzenden. Combineer ze alle drie en je hebt een lekpad.
Dit is niet het soort bug dat een patch sluit; Zoals Levi het omschrijft, is het een structureel gevolg van het geven van permanente inloggegevens aan AI-agenten terwijl ze tekst die voor aanvallers bereikbaar is, kunnen lezen.
Waarom blijft dit gebeuren
GitLost is de laatste in een serie van hetzelfde soort aanvallen, en THN heeft er de afgelopen maanden meerdere gerapporteerd. Een fout in de Claude Code GitHub Action van Anthropic zorgde ervoor dat een enkel kwaadaardig probleem de agent ertoe aanzette geheimen te lekken en schrijftoegang tot een repository in beslag te nemen.
RoguePilot van Orca Security gebruikte een verborgen prompt in een GitHub-probleem om Copilot het geprivilegieerde token van een repository te laten lekken. De GitHub-agentversie van het probleem gaat terug tot minstens mei 2025, toen Invariant Labs aantoonde dat een openbaar probleem een agent die verbonden is met de MCP-server van GitHub ertoe zou kunnen aanzetten een privérepository te lezen en deze via een pull-verzoek te lekken; de onderzoekers noemden het architectonisch, zonder patch op de server om het te sluiten.
Een cross-vendor onderzoek met de naam Comment and Control heeft de Claude Code-, Gemini CLI- en GitHub Copilot-agenten vervolgens misleid om hun eigen API-sleutels te lekken via issue- en pull-request-teksten, waarbij ze gaandeweg voorbij GitHub’s toegevoegde runtime-verdediging glipten.
Wat nu te doen
Noma maakte GitLost bekend aan GitHub en publiceerde zijn bevindingen met medeweten van het bedrijf. De blootstelling is beperkt tot organisaties die de preview hebben ingeschakeld en een agent hebben aangesloten om niet-vertrouwde openbare invoer te lezen terwijl ze leestoegang hebben tot privéopslagplaatsen en die in het openbaar kunnen posten.
Wat een aanvaller kan binnenhalen, hangt af van wat het token van de agent kan zien, van bedrijfseigen broncode tot interne sleutels, ontwerpdocumenten of CI/CD-geheimen. Zoals Levi het stelt, is de reikwijdte het allerbelangrijkste: een agenttoken dat zich richt op de enkele repository die het sorteert, is voor het gemak “veel minder gevaarlijk dan een token dat brede leestoegang voor de hele organisatie verleent”.
In de praktijk komt die toegang tot meerdere repo’s voort uit een persoonlijk toegangstoken dat de organisatie heeft ingesteld, dus richt het token op de ene repository die door de workflow wordt beoordeeld in plaats van op de hele organisatie. Schrijfbewerkingen verlopen alleen via aangegeven veilige uitvoer, dus beperk wat een openbare workflow kan posten, omdat het commentaar dat het produceert het exfiltratiekanaal is. Beperk de inhoud van de auteurs waarop de agent actie zal ondernemen, en laat de resultaten achter menselijke beoordeling.
De bedreigingsdetectiestap van GitHub scant de uitvoer van een agent voordat deze wordt geplaatst, maar Noma’s omzeiling van één woord herinnert ons eraan dat een filter een backstop is en geen grens.
GitHub bouwde, net als de andere leveranciers, vangrails voor precies deze aanvalsklasse, en een verandering van één woord omzeilde deze. Onderzoekers en de leveranciers zelf blijven het resultaat onder de noemer ‘architecturale beperking’ plaatsen, en Levi’s punt is waarom het label blijft hangen: in natuurlijke taal is er geen duidelijke grens tussen data en instructie zoals in SQL, dus de oplossing leunt op architectuur in plaats van de injectie weg te filteren, op isolatie, geassorteerde referenties en gefaseerde beoordeling.
Zolang die grens niet bestaat, is elke agent die privégegevens leest, niet-vertrouwde invoer opneemt en in het openbaar berichten kan plaatsen, slechts één slim geformuleerd probleem verwijderd van een lek.
