Jak útok funguje

Výzkumníci popsali zranitelný vzor GitHub Agentic Workflow jako ten, který:

• se spouští na událost issues.assigned
• čte název a tělo issue
• přidává komentář pomocí nástroje agenta, jako je add-comment
• běží s oprávněním ke čtení ostatních repozitářů v organizaci, včetně soukromých

Útok probíhá ve čtyřech krocích:

1. Útočník vytvoří zdánlivě neškodný GitHub Issue ve veřejném repozitáři organizace, která používá zranitelný vzor Agentic Workflow.
2. V těle issue jsou ukryty instrukce v běžné angličtině, které AI agentovi přikazují, aby stáhl soubory z privátních repozitářů.
3. Když GitHub automatizace přiřadí issue, událostí spuštěné workflow způsobí, že agent načte data z repozitářů, ke kterým má přístup – včetně těch soukromých.
4. Agent zveřejní načtený obsah jako veřejný komentář k issue, čímž data potenciálně zpřístupní komukoli, kdo může issue vidět.

Slabina v architektuře

Základní problém spočívá v nedodržení striktní hranice důvěry mezi systémovými instrukcemi a nedůvěryhodnými uživatelskými daty v rámci kontextového okna AI agenta. Jak uvedl Sasi Levi z Noma Security: „Kontextové okno agenta je zároveň jeho útočnou plochou. Jakýkoli obsah, který agent přečte – ať už jde o issue, pull requesty, komentáře nebo soubory – může být zneužit, pokud s ním agent nakládá jako s instrukcí.“

Agenti založení na velkých jazykových modelech (LLM) mají problém rozlišit data od instrukcí, pokud se obojí objeví ve stejném kontextu nebo výstupu nástroje. Nejde jen o běžnou programátorskou chybu, ale o strukturální riziko v agentních AI workflow, kde nedůvěryhodný obsah může ovlivnit chování agenta, pokud ho workflow neizoluje nebo neomezí.

Výzkumníci tuto třídu chyb formálně kategorizovali jako Agentic Workflow Injection (AWI) a identifikovali dva základní vzorce: Prompt-to-Agent (P2A), kde se nedůvěryhodný obsah dostane na hranici promptu agenta, a Prompt-to-Script (P2S), kde vliv útočníka proniká přes výstupy modelu do pozdějších skriptů.

Technika obcházení ochran: Klíčové slovo „Additionally“

GitHub zavedl ochranná opatření, která měla úniku dat zabránit, ale výzkumníci z Noma zjistili, že je lze obejít překvapivě jednoduchou technikou. Přidání slova „Additionally“ (dále) k vloženým instrukcím údajně způsobilo, že model přerámoval svůj výstup, místo aby požadavek odmítl, a únik dat tak proběhl, jako by šlo o oprávněné pokračování úkolu.

Tento přístup je v souladu s širším výzkumem prompt injection, který ukazuje, že určitá formulace nebo text vrácený nástrojem může způsobit, že modely následují škodlivé instrukce, které by následovat neměly. Obejití ochran připomíná vzorce z dřívějších incidentů, například zranitelnosti GitHub MCP, kterou odhalila Invariant Labs, kde škodlivý issue mohl unést agenta uživatele a způsobit únik dat z privátních repozitářů.

Doporučená opatření pro organizace

Na základě zjištění o GitLost a širších bezpečnostních doporučeních pro agentní workflow by postižené organizace měly zavést následující kontroly:

• Přijmout model nulové důvěry (zero-trust) pro vstupy agenta – nikdy nepovažovat uživatelský obsah za důvěryhodnou instrukci a izolovat nedůvěryhodná uživatelská data od hlavních systémových promptů.
• Uplatnit přísná oprávnění na principu nejnižších privilegií – odstranit zbytečný přístup napříč repozitáři a omezit schopnost agentů zveřejňovat data prostřednictvím veřejných výstupů.
• Používat allowlisty pro nástroje namísto blocklistů a vyžadovat schvalovací brány s lidským dohledem předtím, než agenti provedou citlivé akce, jako je přidávání externě viditelných komentářů nebo přístup k citlivým repozitářům.
• Auditovat integrace AI agentů v CI/CD a automatizačních workflow repozitářů, zejména tam, kde je nedůvěryhodný kontext událostí GitHubu začleněn do promptů nebo vstupů agenta.
• Logicky oddělit nedůvěryhodný uživatelský vstup od systémových direktiv a považovat uživatelem generovaný text za nedůvěryhodná data, nikoli za autoritativní instrukce.

Organizace by také měly na princip nejnižších privilegií aplikovat i na tajemství agentů a zavést nepřetržité bezpečnostní monitorování pro pokusy o prompt injection.

Reakce GitHubu (stav k 7. červenci)

Podle informací Dark Reading a časové osy zveřejnění Noma Security:

• Noma zodpovědně nahlásila chybu GitHubu.
• GitHub společnosti Noma sdělil, že aktualizoval dokumentaci související se zranitelným vzorem workflow, a výzkumníci potvrdili, že zranitelná konfigurace při jejich poslední kontrole již nebyla přítomna.
• K 7. červenci GitHub nevydal formální veřejné prohlášení ani CVE pro GitLost.
• Zranitelnost byla zřejmě částečně vyřešena odstraněním nebo revizí příslušné dokumentace a šablony workflow, nikoli jasně zdokumentovanou bezpečnostní záplatou na úrovni platformy.

Širší souvislosti: Systémové riziko

GitLost není ojedinělý incident. Představuje rostoucí třídu zranitelností, kde jsou AI agenti s přístupem k citlivým datům vystaveni nedůvěryhodnému uživatelskému obsahu. Podobné problémy postihly integrace GitHub MCP, workflow Google Gemini CLI (zranitelnost TrustIssues) a Claude Code GitHub Actions. Společným jmenovatelem je, že agenti založení na LLM postrádají vrozenou schopnost rozlišovat mezi daty a instrukcemi, pokud se obojí objeví ve stejném kontextovém okně – což je základní architektonický problém, který žádná jediná záplata na úrovni platformy nemůže plně vyřešit.

Jak útok funguje

Výzkumníci popsali zranitelný vzor GitHub Agentic Workflow jako ten, který:

• se spouští na událost issues.assigned
• čte název a tělo issue
• přidává komentář pomocí nástroje agenta, jako je add-comment
• běží s oprávněním ke čtení ostatních repozitářů v organizaci, včetně soukromých

Útok probíhá ve čtyřech krocích:

1. Útočník vytvoří zdánlivě neškodný GitHub Issue ve veřejném repozitáři organizace, která používá zranitelný vzor Agentic Workflow.
2. V těle issue jsou ukryty instrukce v běžné angličtině, které AI agentovi přikazují, aby stáhl soubory z privátních repozitářů.
3. Když GitHub automatizace přiřadí issue, událostí spuštěné workflow způsobí, že agent načte data z repozitářů, ke kterým má přístup – včetně těch soukromých.
4. Agent zveřejní načtený obsah jako veřejný komentář k issue, čímž data potenciálně zpřístupní komukoli, kdo může issue vidět.

Slabina v architektuře

Základní problém spočívá v nedodržení striktní hranice důvěry mezi systémovými instrukcemi a nedůvěryhodnými uživatelskými daty v rámci kontextového okna AI agenta. Jak uvedl Sasi Levi z Noma Security: „Kontextové okno agenta je zároveň jeho útočnou plochou. Jakýkoli obsah, který agent přečte – ať už jde o issue, pull requesty, komentáře nebo soubory – může být zneužit, pokud s ním agent nakládá jako s instrukcí.“

Agenti založení na velkých jazykových modelech (LLM) mají problém rozlišit data od instrukcí, pokud se obojí objeví ve stejném kontextu nebo výstupu nástroje. Nejde jen o běžnou programátorskou chybu, ale o strukturální riziko v agentních AI workflow, kde nedůvěryhodný obsah může ovlivnit chování agenta, pokud ho workflow neizoluje nebo neomezí.

Výzkumníci tuto třídu chyb formálně kategorizovali jako Agentic Workflow Injection (AWI) a identifikovali dva základní vzorce: Prompt-to-Agent (P2A), kde se nedůvěryhodný obsah dostane na hranici promptu agenta, a Prompt-to-Script (P2S), kde vliv útočníka proniká přes výstupy modelu do pozdějších skriptů.

Technika obcházení ochran: Klíčové slovo „Additionally“

GitHub zavedl ochranná opatření, která měla úniku dat zabránit, ale výzkumníci z Noma zjistili, že je lze obejít překvapivě jednoduchou technikou. Přidání slova „Additionally“ (dále) k vloženým instrukcím údajně způsobilo, že model přerámoval svůj výstup, místo aby požadavek odmítl, a únik dat tak proběhl, jako by šlo o oprávněné pokračování úkolu.

Tento přístup je v souladu s širším výzkumem prompt injection, který ukazuje, že určitá formulace nebo text vrácený nástrojem může způsobit, že modely následují škodlivé instrukce, které by následovat neměly. Obejití ochran připomíná vzorce z dřívějších incidentů, například zranitelnosti GitHub MCP, kterou odhalila Invariant Labs, kde škodlivý issue mohl unést agenta uživatele a způsobit únik dat z privátních repozitářů.

Doporučená opatření pro organizace

Na základě zjištění o GitLost a širších bezpečnostních doporučeních pro agentní workflow by postižené organizace měly zavést následující kontroly:

• Přijmout model nulové důvěry (zero-trust) pro vstupy agenta – nikdy nepovažovat uživatelský obsah za důvěryhodnou instrukci a izolovat nedůvěryhodná uživatelská data od hlavních systémových promptů.
• Uplatnit přísná oprávnění na principu nejnižších privilegií – odstranit zbytečný přístup napříč repozitáři a omezit schopnost agentů zveřejňovat data prostřednictvím veřejných výstupů.
• Používat allowlisty pro nástroje namísto blocklistů a vyžadovat schvalovací brány s lidským dohledem předtím, než agenti provedou citlivé akce, jako je přidávání externě viditelných komentářů nebo přístup k citlivým repozitářům.
• Auditovat integrace AI agentů v CI/CD a automatizačních workflow repozitářů, zejména tam, kde je nedůvěryhodný kontext událostí GitHubu začleněn do promptů nebo vstupů agenta.
• Logicky oddělit nedůvěryhodný uživatelský vstup od systémových direktiv a považovat uživatelem generovaný text za nedůvěryhodná data, nikoli za autoritativní instrukce.

Organizace by také měly na princip nejnižších privilegií aplikovat i na tajemství agentů a zavést nepřetržité bezpečnostní monitorování pro pokusy o prompt injection.

Reakce GitHubu (stav k 7. červenci)

Podle informací Dark Reading a časové osy zveřejnění Noma Security:

• Noma zodpovědně nahlásila chybu GitHubu.
• GitHub společnosti Noma sdělil, že aktualizoval dokumentaci související se zranitelným vzorem workflow, a výzkumníci potvrdili, že zranitelná konfigurace při jejich poslední kontrole již nebyla přítomna.
• K 7. červenci GitHub nevydal formální veřejné prohlášení ani CVE pro GitLost.
• Zranitelnost byla zřejmě částečně vyřešena odstraněním nebo revizí příslušné dokumentace a šablony workflow, nikoli jasně zdokumentovanou bezpečnostní záplatou na úrovni platformy.

Širší souvislosti: Systémové riziko

GitLost není ojedinělý incident. Představuje rostoucí třídu zranitelností, kde jsou AI agenti s přístupem k citlivým datům vystaveni nedůvěryhodnému uživatelskému obsahu. Podobné problémy postihly integrace GitHub MCP, workflow Google Gemini CLI (zranitelnost TrustIssues) a Claude Code GitHub Actions. Společným jmenovatelem je, že agenti založení na LLM postrádají vrozenou schopnost rozlišovat mezi daty a instrukcemi, pokud se obojí objeví ve stejném kontextovém okně – což je základní architektonický problém, který žádná jediná záplata na úrovni platformy nemůže plně vyřešit.