GitLost: A Public GitHub Issue Tricked an Agentic Workflow Into Leaking Private Repos
Noma Labs showed that a GitHub Agentic Workflow with cross-repository read access could be steered by a crafted issue into posting private repository content as a public comment. The flaw is architectural, and it applies to any AI agent in CI/CD that reads untrusted text.
Key Takeaways
- Noma Labs' 'GitLost' research showed a GitHub Agentic Workflow could be made to leak private repository content after an attacker opened an issue in a public repository.
- The attacker needed no credentials, code or prior access, only the ability to file an issue.
- The root cause is a dangerous combination: untrusted input, cross-repo read access and a public write channel in one agent.
- Mitigation is least-privilege design and removing the exfiltration path; prompt-level guardrails alone did not hold.
What Noma Labs demonstrated
According to SecurityWeek's report and Noma Labs' write-up, researchers tricked a GitHub Agentic Workflow into disclosing private repository data. They named the issue GitLost. No CVE identifier is cited in either source.
The workflow in the test was configured to fire on issues.assigned events. It read the issue title and body and could post comments through an add-comment tool. It also had read access to other repositories in the organisation, both public and private.
The attack chain
- 1An attacker opens an issue in a public repository, with hidden instructions in the body.
- 2The issue is assigned, which triggers the agentic workflow.
- 3The agent reads the issue text and treats the embedded instructions as legitimate tasks.
- 4It fetches content from private repositories it can read. The reported example was
README.mdfiles. - 5It posts that content as a public comment on the original issue, where anyone can read it.
Noma reports that the model's guardrails initially resisted, and that adding the keyword "Additionally" caused the model to reframe its output rather than refuse. That detail matters: a safety behaviour that a single connective word can bypass is not a security boundary.
Why this is a supply-chain problem
Teams adopt agents in CI/CD to triage issues, summarise pull requests and label tickets. Those jobs put attacker-controlled text, such as issue bodies, PR descriptions and commit messages, in front of a model that holds repository credentials. As Noma puts it, the agent's context window is also its attack surface.
This is the familiar confused-deputy pattern. The agent is authorised to read private code and to write publicly, and the attacker only has to supply the instruction that connects the two.
What to do about it
- Treat user-controlled content as untrusted data, never as instructions, including issue text, comments and PR bodies.
- Scope permissions minimally. An issue-triage agent rarely needs read access to every private repository in the organisation.
- Restrict public posting by agents in response to user input, or route output through a review step.
- Sanitise input before it reaches the model, while recognising this reduces risk rather than eliminating it.
- Inventory your agent workflows and review what each can read and where it can write.
The sources we reviewed do not describe a patch or fix status, so organisations running similar workflows should assume the design risk remains and reduce exposure through configuration.
Frequently Asked Questions
What is GitLost?
GitLost is Noma Labs' name for a prompt-injection attack on a GitHub Agentic Workflow. A crafted issue in a public repository caused the agent to leak private repository content into a public comment.
Does the attacker need access to the organisation?
According to Noma Labs, no. The attacker needed no coding skills, credentials or access beyond opening an issue in a public repository.
How can teams reduce the risk of AI agents in CI/CD?
Give each agent the minimum repository permissions, treat all user-supplied text as untrusted, and prevent agents from posting data publicly in response to untrusted input.