GitLost: Public Issue Leaks Private GitHub Repo Data

If your org turned on GitHub’s Agentic Workflows preview and wired the agent up with cross-repo read access to your private repos — the default posture in a lot of the “let it triage issues across the whole org” demos — you have work to do this week. Noma Security published GitLost on Monday, a proof-of-concept that walks through how an outside attacker, with no account and no stolen credentials, can open a normal-looking public issue and pull the contents of one of your private repos out into a public comment thread. The Hacker News covered it yesterday. Noma disclosed to GitHub before publishing, per their own note in the writeup. There is no CVE.

That last sentence is deliberate. This isn’t the kind of finding a patch closes, and treating it like one is how you end up back here in three months.

What changed

Noma’s team — research led by Sasi Levi — set up an Agentic Workflow the way GitHub’s own docs describe it: trigger on issues.assigned, run the agent with a token that has read access to other repos in the organization, both public and private. Standard “let the agent help us keep the backlog clean” posture. Then they filed an issue on a public repo in that same org, from an outside account, with instructions embedded in the issue body. The agent read the instructions, treated them as legitimate task input, and posted private-repo content back into the public comment thread.

The class of bug is indirect prompt injection. Nothing new about the concept — OWASP has been calling it LLM01 since 2023 — and Noma explicitly places GitLost alongside the Claude Code GitHub Action flaw from June, the RoguePilot Copilot finding earlier this year, and the Invariant Labs MCP work from 2025. Same shape every time: a privileged agent, a trust boundary that assumes text = task, and an attacker who owns some of the text.

GitHub is not asleep on this. Noma’s writeup notes GitHub built guardrails around Agentic Workflows before the preview shipped — sandboxing, read-only-by-default tokens, input cleaning, and an output-scanning step that inspects what the agent is about to post before it goes to a public channel. Noma bypassed the output scanner with a single-word prefix in the injected text. I’m not repeating the word here — it’s in their writeup if you want the exact detail — because the point isn’t that particular string. The point is that the filter is a keyword shim over a model that is doing what it was told to do. There will be a second word. There will be a third.

Levi’s framing in the Noma post is the honest one: “not the kind of bug a patch closes; it is a structural consequence of giving AI agents standing credentials while having them read attacker-reachable text.” Take that seriously. GitHub can — and probably will — tighten the output scanner. That is not the same as closing this attack surface.

What to actually do

Priority one, this week, if you have Agentic Workflows enabled in preview:

• Audit the token scope on every workflow. If a workflow’s agent token has org-wide read across private repos and its trigger surface includes anything public-reachable (public issues, public PR comments, public discussions), you are in the vulnerable configuration. Rescope the token to only the repositories that specific workflow needs to touch. A per-repo token that reads one repo is dramatically less useful to an attacker than an org-wide read token that reads all of them.
• Gate agent-authored public writes behind human review. If the agent posts comments, opens PRs, or edits issue bodies on a public channel, put an approval step in front of that write. Yes, it slows down the workflow. That is the point. The exfiltration channel in GitLost is the public write; take it away and the injection has nowhere to send data.
• Restrict input sources to trusted authors. GitHub’s workflow triggers can be constrained by actor. Where the business case allows it, only let the agent act on issues or comments from your own org members or a vetted contributor list. This does not scale for open-source projects that need to triage community reports, and for those you’re back to the two controls above.
• Turn the preview off where it isn’t earning its keep. A lot of the “we enabled it to see what it does” deployments from the last couple of months are not doing measurable work. If yours is one of those, disable the workflow, take the token back, and revisit in a quarter when the platform has moved. That is not a defeat — it is triage.

Priority two, this quarter, everywhere:

• Assume the same class of finding on every agentic dev tool in your stack. Claude Code, GitHub Copilot’s agentic modes, Gemini’s CLI agent, the various MCP servers you’ve been experimenting with — the “standing credential + attacker-reachable text” shape is present in all of them by design. Inventory which ones your engineers have wired to production data or private repos. That inventory is your list of things to review the next time a researcher writes one of these up, and there will be a next time.
• Log what the agents read and where they write. If you can’t answer “did the agent post anything to a public surface in the last 24 hours” from a query, you can’t detect an exfiltration when one happens. Ship the workflow’s agent conversation and its outbound-write log to whatever you use for detection today.
• Treat the vendor-side guardrails as one layer, not the layer. GitHub’s output scanner, Anthropic’s tool-use safety training, and the various “system prompt” hardening approaches all reduce the base rate of a successful injection. None of them eliminate it. Your controls are the token scope and the write gate. Everything else is defense in depth on top of those.

What not to do

Do not wait for a CVE. There isn’t going to be one for GitLost, and there very likely won’t be one for the next few findings in this class either. That is not a signal the bugs aren’t real — it is a signal that the industry hasn’t figured out how to assign IDs to architectural exposures in agentic systems, and CVE assignment lagging the disclosure is not permission to defer the fix. The CISA KEV catalog — which is a great tool for its purpose — is the wrong instrument to wait on here. KEV tracks CVEs. This isn’t one.

Do not roll your own input-sanitization filter and call it done. Noma’s finding is the demonstration case for why that doesn’t hold: GitHub, with a real security team, built exactly that filter and got past by a single-word prefix. The credible controls are the ones outside the model — token scope and human review on public writes — not the ones inside it.

Do not treat this as a Copilot problem or a GitHub problem. It’s the shape of every “give the agent standing access, let it read attacker-reachable text” deployment you have, and there are more of those in your org than you think. Go find them.

The honest short version: audit your agent tokens today, put a human on any public writes those agents perform, and stop waiting for a patch that isn’t coming.

Related coverage from this week: Google Dialogflow CX’s “Rogue Agent” finding — different vendor, same class of “shared runtime, wrong trust boundary” pattern in an AI product surface — and the Writer AI cross-tenant session-token leak disclosed the same day. Three findings in one week, all in the same shape.

Sourcing

• Sasi Levi. GitLost: How We Tricked GitHub’s AI Agent Into Leaking Private Repos. Noma Security, 2026-07-06.
• Ravie Lakshmanan. Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data. The Hacker News, 2026-07-07.
• OWASP. OWASP Top 10 for LLM Applications — LLM01: Prompt Injection.
• CISA. Known Exploited Vulnerabilities catalog.