GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos - Noma Security
book a demo
Back to Blog
GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos
Sasi Levi
July 6, 2026
TL;DR : Noma Labs discovered a critical prompt injection vulnerability within GitHub’s new Agentic Workflows, allowing an unauthenticated attacker to silently pull data from private repositories by posting a crafted GitHub Issue in a public repository belonging to the same organization as the private repositories. Noma Labs named the vulnerability GitLost.
https://noma.security/wp-content/uploads/GitLost-full-video-1.mp4
Introduction
GitHub recently launched GitHub Agentic Workflows, pairing GitHub Actions (GitHub’s automation system for running tasks in response to repository events) with an AI agent backed by Claude or GitHub Copilot. GitHub Agentic Workflows allow teams to write their GitHub workflows in plain Markdown, and the GitHub agent reads issues, calls tools, and responds on its own.
As a vulnerability researcher with a security development background, one of the first questions that came to mind after this launch was fundamental and straightforward: What will happen when the GitHub agent reads something it should not trust?
The answer is a textbook indirect prompt-injection attack, the kind of attack that quietly sends private data to anyone on the internet. Prompt injection is a class of attack in which an adversary hides malicious instructions inside the content read by an AI agent. That content causes the agent to follow those hidden instructions instead of the ones its operator intended.
What are GitHub Agentic Workflows?
GitHub Agentic Workflows let teams automate their interactions with code repositories using natural language. Workflows live in Markdown (.md) files, are compiled into YAML (a common configuration file format), Actions files with the .yml extension, and run with the help of an AI agent with configurable permissions. The GitHub agent can read issues, call tools, and access other repositories within an organization.
GitLost Vulnerability Overview
The root cause of the GitLost vulnerability is, by now, a familiar one in agentic AI systems: prompt injection. In most agentic prompt injection attacks, the agent treats the wrong content as a trusted source of instructions and allows itself to be misdirected or misused. This happens when the system fails to maintain a strict trust boundary between system-level directives and untrusted user data. In this specific case, any malicious actor can create a GitHub Issue and, in the issue body, hide commands in plain English that GitHub’s agent will follow.
The vulnerable Github Agentic Workflow Noma Labs discovered was configured to:
Trigger the workflow on issues.assigned events in GitHub
Read the issue Title and Body
Post a comment in response using the add-comment tool
Run with read access to other repositories (public and private) in the organization
To exploit this vulnerability, the attacker needed no coding skills, access, or credentials. All that was needed was to open an issue in a public repository belonging to an organization that uses GitHub’s Agentic Workflow setup and wait.
The Attack Flow
Let’s take a look at the exact attack flow that Noma Labs vulnerability researchers succeeded with:
First, they crafted a GitHub issue that looked completely innocent, consisting of a plausible-looking request from a VP Sales after meeting with a customer, as shown below:
In this specific example, the workflow action was triggered when the issue was assigned , but our testing confirmed it works the same way for other GitHub workflow actions.
Then, after a GitHub automation assigned the issue, an event-triggered workflow caused the agent to fetch the contents of README.md from both the poc (public) and testlocal (private) repositories.
Finally, the GitHub agent then posted them as a public comment on the issue in the public repository, which anyone could access and read.
The “Additional” Exploit
GitHub had restrictive guardrails in place to prevent exactly this scenario, but they failed to protect the repositories as intended. Testing GitHub repeatedly with variations, as an attacker would, and adding the keyword "Additionally" triggered unintended behavior in the model, causing it to reframe its output rather than refuse it. Essentially, by tricking the model, I was able to ensure that GitHub’s guardrails did not work as intended and didn’t prevent the data leak.
https://noma.security/wp-content/uploads/github_agentic_workflows.mp4
Vulnerability Proof of Concept
With the goal of full transparency, Noma Lab’s confirmed findings, including our workflow reproductions and live evidence, can be found here:
Workflow run : https://github.com/sasinomalabs/poc/actions/runs/23909666039
Issue : https://github.com/sasinomalabs/poc/issues/153
The leaked data included the contents of README.md from:
sasinomalabs/poc...