메뉴
HN
Hacker News 21일 전

깃허브 AI 에이전트, 비공개 저장소 유출 취약점 발견

IMP
9/10
핵심 요약

보안 연구진이 GitHub의 신규 AI 자동화 시스템(Agentic Workflows)에서 간접 프롬프트 인젝션(명령어 삽입) 취약점을 발견했습니다. 공개된 저장소에 악성 명령어가 숨겨진 이슈(Issue)를 등록하기만 하면, AI 에이전트가 속아 조직 내 비공개 저장소의 코드를 공개 댓글로 유출하게 됩니다. 개발자 권한이나 별도의 인증 없이도 누구나 쉽게 해킹을 실행할 수 있다는 점에서 매우 심각한 보안 위협으로 평가됩니다.

번역된 본문

블로그로 돌아가기

GitLost: 깃허브 AI 에이전트를 속여 비공개 저장소를 유출시킨 방법 Sasi Levi, 2026년 7월 6일

요약(TL;DR): Noma Labs는 깃허브(GitHub)의 새로운 에이전트 워크플로우(Agentic Workflows) 내에서 치명적인 프롬프트 인젝션 취약점을 발견했습니다. 이 취약점을 이용하면 인증되지 않은 공격자가 동일한 조직 내 퍼블릭 저장소에 조작된 깃허브 이슈(Issue)를 게시하는 것만으로, 프라이빗 저장소의 데이터를 소리 없이 빼낼 수 있습니다. Noma Labs는 이 취약점의 이름을 'GitLost'라고 명명했습니다. https://noma.security/wp-content/uploads/GitLost-full-video-1.mp4

들어가며 깃허브는 최근 깃허브 액션(저장소 내 이벤트에 반응하여 작업을 실행하는 깃허브의 자동화 시스템)과 Claude 또는 깃허브 코파일럿(GitHub Copilot) 기반의 AI 에이전트를 결합한 '깃허브 에이전트 워크플로우'를 출시했습니다. 깃허브 에이전트 워크플로우를 통해 팀은 일반 마크다운(Markdown)으로 워크플로우를 작성할 수 있으며, 깃허브 에이전트는 이슈를 읽고, 도구를 호출하여 스스로 응답합니다.

보안 개발 배경을 가진 취약점 연구원으로서, 이 기능이 출시된 후 가장 먼저 떠오른 질문은 근본적이고 단순했습니다. "깃허브 에이전트가 신뢰해서는 안 되는 내용을 읽게 되면 어떻게 될까?" 그 대답은 바로 인터넷상의 누구에게나 프라이빗 데이터를 조용히 전송하는 교과서적인 '간접 프롬프트 인젝션(Prompt Injection)' 공격입니다. 프롬프트 인젝션은 AI 에이전트가 읽는 콘텐츠 내부에 공격자가 악의적인 명령을 숨기는 공격을 말합니다. 이 콘텐츠는 운영자가 의도한 명령 대신 에이전트가 숨겨진 명령을 따르게 만듭니다.

깃허브 에이전트 워크플로우란? 깃허브 에이전트 워크플로우를 사용하면 팀이 자연어를 사용하여 코드 저장소와의 상호작용을 자동화할 수 있습니다. 워크플로우는 마크다운(.md) 파일로 작성되며, 일반적인 구성 파일 형식인 YAML(.yml 확장자를 가진 액션 파일)로 컴파일되고, 권한 설정이 가능한 AI 에이전트의 도움을 받아 실행됩니다. 깃허브 에이전트는 이슈를 읽고, 도구를 호출하고, 조직 내 다른 저장소에 액세스할 수 있습니다.

GitLost 취약점 개요 현재까지 파악된 GitLost 취약점의 근본 원인은 에이전트 AI 시스템에서 이미 익숙한 '프롬프트 인젝션'입니다. 대부분의 에이전트 프롬프트 인젝션 공격에서, 에이전트는 잘못된 콘텐츠를 신뢰할 수 있는 명령 출처로 취급하여 자신이 오도되거나 악용될 수 있도록 허용합니다. 이는 시스템 수준의 지시문과 신뢰할 수 없는 사용자 데이터 사이의 엄격한 신뢰 경계(Trust Boundary)를 유지하지 못할 때 발생합니다.

이번 특정 사례에서는 악의적인 행위자가 깃허브 이슈를 생성하고, 이슈 본문에 깃허브 에이전트가 따르게 될 평범한 영어 명령을 숨길 수 있습니다. Noma Labs가 발견한 취약한 깃허브 에이전트 워크플로우는 다음과 같이 구성되어 있었습니다:

  • 깃허브의 issues.assigned(이슈 할당) 이벤트에 의해 워크플로우가 트리거됨
  • 이슈의 제목과 본문을 읽음
  • add-comment(댓글 추가) 도구를 사용하여 응답으로 댓글을 게시함
  • 조직 내 다른 퍼블릭 및 프라이빗 저장소에 대한 읽기(Read) 액세스 권한으로 실행됨

이 취약점을 악용하기 위해 공격자에게는 코딩 기술, 시스템 접근 권한 또는 자격 증명이 전혀 필요하지 않았습니다. 깃허브의 에이전트 워크플로우 설정을 사용하는 조직의 퍼블릭 저장소에 이슈를 열고 기다리기만 하면 됐습니다.

공격 흐름 Noma Labs의 취약점 연구원들이 성공한 정확한 공격 흐름을 살펴보겠습니다.

첫째, 그들은 완전히 무해해 보이는 깃허브 이슈를 정교하게 만들었습니다. 아래에 표시된 것처럼 고객과의 미팅 후 영업 부사장(VP Sales)이 남긴 것처럼 보이는 그럴듯한 요청으로 구성되었습니다:

이 특정 예시에서는 이슈가 할당되었을 때 워크플로우 액션이 트리거되었지만, 테스트를 통해 다른 깃허브 워크플로우 액션에서도 동일한 방식으로 작동하는 것이 확인되었습니다.

그런 다음, 깃허브 자동화 기능이 이슈를 할당한 후, 이벤트에 의해 트리거된 워크플로우로 인해 에이전트는 poc(퍼블릭) 및 testlocal(프라이빗) 저장소 모두에서 README.md의 내용을 가져왔습니다.

마지막으로 깃허브 에이전트는 해당 내용을 퍼블릭 저장소의 이슈에 퍼블릭 댓글로 게시했으며, 이는 누구나 접근하여 읽을 수 있었습니다.

추가적인 익스플로잇(Exploit) 깃허브에는 정확히 이러한 일을 방지하기 위해 엄격한 guardrails(안전 가이드라인/보호 장치)가 마련되어 있었습니다. (하지만 이를 우회하는 추가적인 해킹 기법이 존재했습니다.)

원문 보기
원문 보기 (영어)
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 (public repo) sasinomalabs/remote-ping (public repo, no README confirmed) sasinomalabs/testlocal (private repo) Why it Matters GitLost perfectly illustrates one of the fundamental security challenges every organization faces with agentic AI systems. The agent's context window is also its attack surface. Any content the agent reads, whether issues, pull requests, comments, or files, can be weaponized if the agent treats that content as instructional input. Traditional security models typically assume that trust boundaries are enforced by code. In agentic systems, trust boundaries are partly enforced by the model's behavior, and models are inherently instruction-following. Prompt injection attacks have become, to agentic AI, what SQL injections were to web applications: a systematic, category-wide vulnerability class that requires the same systematic strategies and defenses. Noma Recommendations for Builders/AI Security Officers: Never treat user-controlled content as trusted instruction input for an AI agent Scope permissions to the minimum required. Agents with cross-repository access are especially high-value targets Restrict what any agent can post publicly, especially in response to issue content Sanitize or isolate user input from the instruction context before passing it to the model Responsible Disclosure GitLost was responsibly disclosed to GitHub. Vulnerability details are shared here with their knowledge. Found this interesting? Subscribe for more agentic AI vulnerability research by Noma Labs, or check out: GrafanaGhost , DockerDash , Context Crush , GeminiJack . Looking for an effective Agentic AI Security Solution? Contact us to arrange a demo of Noma’s comprehensive solution. 5 min read Category: Noma Labs Table of Contents Share this: Discover more That’s a Great Question - Claude Tag and Agent Identity: What Changes for IAM? June 28, 2026 Noma Partners With Kong to Secure the Agentic AI Era June 24, 2026 That's a Great Question - Who Wrote the Instructions Your Agent Is Following? June 24, 2026