A Hidden Command in a GitHub Issue Can Silently Steal a Company's Private Code

Key points

• Noma Security researchers disclosed the flaw, named "GitLost", on Tuesday after testing it with a working proof-of-concept attack.
• An attacker needs no credentials or coding skills, only the ability to open a public issue on GitHub.
• The attack targets GitHub Agentic Workflows, an AI-powered automation tool that can read across multiple code repositories inside a single organisation.
• GitHub told Noma it updated the documentation that created the vulnerability; the researchers confirmed it was no longer present at last check.
• Organisations using AI automation tools with broad internal access should immediately restrict what those tools can read and share.

Researchers at Noma Security have found a way to trick GitHub's AI automation tool into handing over a company's private code and internal documents, without breaking into a single account or exploiting a software bug in the traditional sense.

The attack exploits prompt injection, where a criminal hides plain-English instructions inside content that an AI system reads, causing the AI to follow those instructions as if they came from its own operators. The content here is a GitHub Issue, a public comment thread developers use to report bugs or request changes.

The vulnerable tool is GitHub Agentic Workflows, which pairs GitHub Actions (the platform's built-in system for automating coding tasks) with an AI assistant backed by either Anthropic's Claude or GitHub Copilot. Development teams use it to manage code repositories through conversational language instead of writing manual scripts.

How did the attackers get in?

They didn't need to. That is what makes this unusual.

An outsider opens an issue on any public GitHub repository belonging to an organisation that uses this tool, hides commands in plain English inside the issue body, and waits. The AI agent reads the issue as part of its normal work, treats those hidden commands as legitimate instructions, and quietly pulls information from private repositories before posting it back as a public comment. Noma's proof-of-concept successfully exposed details of an internal company meeting.

"The agent's context window is also its attack surface," wrote Sasi Levi, security research lead at Noma, referring to the full body of text the AI can read at any one time. "Any content the agent reads can be weaponised if the agent treats that content as instructional input."

Levi has also called GitLost a textbook example of a structural problem, not a one-off slip. "That's a strong signal this isn't a one-off implementation slip in a single feature; it's a structural consequence of giving AI agents standing credentials while also having them process attacker-reachable text," he told Dark Reading. We covered GitHub's earlier workflow hardening work on 23 June, but that fix addressed a different attack path entirely.

Noma disclosed the flaw responsibly to GitHub. GitHub said it updated the documentation that set up the vulnerable configuration, and Noma confirmed the specific example was no longer visible at the time of writing. Dark Reading first reported the details.

Should you restrict your AI agents now?

Yes, and the answer is least privilege: every AI workflow tool should have access stripped back to the minimum it actually needs. An agent managing issues in one repository has no business reading private repositories across the whole organisation. Treat untrusted user content, anything the public can write, as a completely separate input from the instructions that govern AI behaviour. Mixing them is the vulnerability.