How a Single Public Issue Can Expose Your Private Repos
A newly uncovered vulnerability, dubbed GitLost, exposes a dangerous gap in GitHub‘s agentic workflow system. The flaw allows an unauthenticated attacker to craft a seemingly harmless GitHub Issue in a public repository — and then silently siphon data from that organization’s private repositories.
It’s a classic supply-chain twist: the attacker never needs credentials. They don’t need to compromise a developer’s machine. All they need is a public repo where issues are open, and a victim organization that uses GitHub Actions or other automated workflows that respond to issue events.
The vulnerability was disclosed by researchers at Protect AI, who gave it the name GitLost. The name is fitting — it describes data that should be private but gets “lost” to an outsider through a side channel.
Why Agentic Workflows Are the Weak Link
GitHub’s agentic workflows — automated pipelines that can read, write, and act on repository events — are powerful. They let teams build bots that triage issues, run tests, or deploy code. But that power comes with a blind spot.
Here’s the core problem: when a workflow triggers on an issue_comment or issues event, it often runs with permissions that extend beyond the public repo. A typical action might clone the repo, check environment variables, or even access other repositories in the same organization. If the workflow’s code doesn’t strictly sanitize input from the issue, an attacker can inject commands that exfiltrate that data.
The Attack Chain, Step by Step
- Identify a target — Find a GitHub organization with a public repository that has issues enabled and uses a workflow that responds to issue events.
- Craft a malicious issue — The attacker opens an issue containing specially crafted content, such as a payload in the issue title, body, or a comment.
- Trigger the workflow — The organization’s GitHub Action runs automatically (e.g., on
issue_comment), pulling the issue data into its execution context.
- Data exfiltration — The payload executes within the workflow, reading secrets, environment variables, or files from private repos, then sending them to an attacker-controlled server.
Protect AI’s researchers demonstrated the attack using a custom GitHub App that mimicked a real-world workflow. They were able to extract private repository contents, access tokens, and even organization-level secrets — all from a single public issue.
Who Is at Risk? Nearly Anyone Using GitHub Actions
The GitLost vulnerability doesn’t require exotic configurations. Any organization that runs GitHub Actions on issue events — including popular actions like stale, labeler, or custom bots — could be exposed. GitHub Actions security is often overlooked because teams assume the trigger event is low-risk.
But the risk is real. An attacker could:
- Steal proprietary source code from private repos
- Extract API keys, database credentials, or cloud service tokens
- Pivot to compromise other systems using leaked credentials
- Plant backdoors in CI/CD pipelines
The attack is especially dangerous for open-source projects that have both public and private repositories under the same organization. A popular library with a public issue tracker could become the entry point to the company’s internal infrastructure.
What GitHub Has Done — and What You Should Do
GitHub has acknowledged the vulnerability and released a security advisory. The company recommends that organizations review their workflow permissions and apply the principle of least privilege. Specifically:
- Use
pull_request events instead of issue_comment where possible, since PRs come from forked repos with limited trust
- Set
permissions: read-only on workflows that don’t need write access
- Avoid using
${{ github.event.issue.body }} or other user-supplied data directly in shell commands
- Pin action versions to specific commit SHAs, not version tags
- Use OpenID Connect (OIDC) for cloud authentication instead of long-lived secrets
Protect AI also released a free checker tool that scans your GitHub organization for workflows vulnerable to GitLost. The tool checks for common misconfigurations and flags risky patterns.
The Bigger Picture: Agentic Security Is Still Immature
The GitLost flaw is not an isolated incident. It’s part of a broader trend where AI-powered agentic workflows — systems that autonomously act on events — introduce new attack surfaces. Traditional security models assume a human in the loop, but agents act quickly, silently, and with broad permissions.
Security researchers have warned for years that GitHub Actions, like any CI/CD system, is only as secure as its least-trusted input. The GitLost vulnerability is a concrete demonstration of that principle. It shows that even a seemingly innocuous feature — opening an issue — can be weaponized.
For now, the best defense is skepticism. Treat every external input as untrusted, especially in automated workflows. Audit your actions. And remember: just because a repo is public doesn’t mean its workflows should trust anyone.
