Skip to content

Back to the catalog

AI Security Briefing
noma.securitywriteup

AI Security Briefing

Noma Labs disclosed GitLost, an indirect prompt-injection vulnerability in GitHub Agentic Workflows where an unauthenticated attacker could open a public GitHub Issue with hidden instructions that, once the AI agent backed by Claude or GitHub Copilot processed the issue on an issues.assigned trigger, caused it to fetch README contents from private organization repositories and post them as a public comment. The researchers also bypassed GitHub's guardrails by inserting the word Additionally into the crafted issue, reframing the model's output instead of triggering a refusal. GitHub was notified and the flaw was responsibly disclosed with a full PoC (workflow run and issue) published.

TL;DR A crafted public GitHub Issue tricked GitHub's Agentic Workflows AI agent into leaking private repo README contents via indirect prompt injection, with a guardrail bypass using the word Additionally.
Open original ↗
Document

What it is

"GitLost" — an indirect prompt-injection vulnerability Noma Labs found in GitHub Agentic Workflows, which pair GitHub Actions with an AI agent (Claude or Copilot) that reads issues, calls tools, and posts responses on its own. The summary covers the core leak; what it omits is the exact vulnerable workflow configuration and Noma's four builder-side mitigations.

How it works

The specific vulnerable workflow Noma reproduced was configured to:

  • Trigger on issues.assigned events
  • Read the issue Title and Body
  • Post a reply via the add-comment tool
  • Run with read access to other repos (public and private) in the same organization

That cross-repo read scope plus a public posting tool is what turns a hidden instruction into an exfiltration channel. The attacker's issue was disguised as a plausible VP-Sales customer request. Noma notes the attack worked on other trigger events too, not only issues.assigned.

flowchart LR
  A[Public issue<br/>hidden instructions] --> B[Automation assigns issue]
  B --> C[Agent reads issue body]
  C --> D{Guardrail}
  D -->|'Additionally' reframes| E[Fetch private README]
  D -.->|intended: refuse| X[No leak]
  E --> F[Post as public comment]

Preconditions / Affected

The org must use GitHub Agentic Workflows with an agent granted cross-repository (incl. private) read access and the ability to comment publicly, triggered by issue events. The attacker needs no code, credentials, or access — just the ability to open an issue in any public repo belonging to that org, then wait.

What to do

Noma's recommendations for builders / AI security officers:

  • Never treat user-controlled content as trusted instruction input for an AI agent
  • Scope permissions to the minimum required; agents with cross-repository access are especially high-value targets
  • Restrict what any agent can post publicly, especially in response to issue content
  • Sanitize or isolate user input from the instruction context before passing it to the model

The most direct lever here is removing the private-repo read scope and/or the public add-comment capability from any issue-triggered workflow — breaking the read-private→post-public chain regardless of prompt-injection success.

Caveats

Live proof-of-concept evidence is public: workflow run .../actions/runs/23909666039 and issue #153 under sasinomalabs/poc. Leaked README contents came from sasinomalabs/poc (public), sasinomalabs/remote-ping (public, no README confirmed), and sasinomalabs/testlocal (private). The page describes GitHub's guardrails as pre-existing but bypassed via the "Additionally" reframing; it does not state whether GitHub has since patched the behavior.

Technologies named here

Techniques named here

Related in AI Security