Beveiligingsonderzoekers van Noma Security lieten zien hoe GitHub Agentic Workflows code uit een privérepository in een openbare issue-reactie kon plaatsen. De kwetsbaarheid kreeg de naam GitLost en draaide om promptinjectie in gewone Markdown.
Wat GitLost precies deed
De onderzoekers verstopten een instructie in een publiek issue. Een workflow-agent die zowel het publieke issue als een privérepository kon lezen, volgde die instructie en publiceerde vervolgens privécode in zijn antwoord. Het lek ontstond dus niet doordat een willekeurige bezoeker rechtstreeks rechten kreeg, maar doordat de agent bestaande rechten over twee vertrouwensgrenzen combineerde.
Waarom de rechtenmix het probleem was
De agent kon onbetrouwbare publieke invoer verwerken, privé-informatie ophalen en weer naar een openbaar kanaal schrijven. Juist die combinatie maakte de promptinjectie gevaarlijk. GitHub documenteert inmiddels dat agentprompts gevoelig kunnen zijn voor injectie en dat agenthandelingen controleerbaar en beperkt moeten blijven.
De controle hoort op de datastroom te zitten
Alleen een model vragen om geen gevoelige data te delen is geen harde beveiligingsgrens. De relevante vraag is welke bron de agent mag lezen, naar welk kanaal hij mag schrijven en of een overgang van privé naar publiek apart wordt tegengehouden. GitLost maakt die architectuurvraag concreet.
Bron
Wat dit betekent voor jou
Voor bedrijven die GitHub gebruiken betekent dit dat ze extra aandacht moeten besteden aan wie toegang heeft tot hun repositories. Het is verstandig om privésleutels en gevoelige code niet alleen afhankelijk te maken van platforminstellingen, maar ook zelf controles in te bouwen. Daarnaast is het belangrijk om medewerkers bewust te maken van de risico's van natuurlijke taalcommando's aan AI-tools.
Editie 324 · Kort