GitHub MCP 악용: MCP를 통한 비공개 저장소 접근

(invariantlabs.ai)

GitHub MCP 통합에 심각한 취약점이 발견되어, 공격자가 악의적인 GitHub Issue를 통해 사용자의 에이전트를 조작하고 비공개 저장소 데이터를 유출할 수 있음
이 취약점은 Toxic Agent Flow라는 새로운 유형으로, 에이전트가 악성 프롬프트에 의해 원치 않는 데이터를 공개 저장소에 노출하게 됨
취약점은 도구 자체의 결함이 아닌 아키텍처적 한계에서 발생하며, 단순한 사용 확인 정책 등 현실적 사용 습관이 위험을 키움
효과적 방어를 위해 세분화된 권한 제어와 지속적인 보안 모니터링 같은 체계적 에이전트 보호책 도입 필요함
단순히 모델 정합(Alignment)만으로는 충분하지 않으므로, MCP 및 에이전트 환경 전체에 걸친 시스템 수준의 보안 대책이 중요함

개요

Invariant는 널리 사용되는 GitHub MCP 통합(14,000 stars) 에서 매우 심각한 취약점을 발견했음. 이 취약점은 공격자가 악의적인 GitHub Issue를 생성해 사용자의 에이전트를 조작하고, 비공개 저장소의 데이터를 외부로 누출시키는 것이 가능함

이 문제는 Invariant의 자동화된 Toxic Agent Flow 탐지 스캐너로 처음 발견된 사례임. 이러한 시나리오에서, 에이전트는 의도하지 않은 행위를 하도록 유도되어 데이터 유출 또는 악성 코드 실행 등의 피해를 입게됨

최근 업계에서는 코딩 에이전트와 IDE를 폭넓게 도입하고 있기 때문에, 이런 공격에 대한 경각심을 높이는 것이 중요한 시점임

공격 시나리오

공격 준비
- 사용자가 Claude Desktop 같은 MCP 클라이언트와 GitHub MCP 서버를 연결한 상태를 가정
- <user>/public-repo: 누구나 Issue를 생성할 수 있는 공개 저장소
- <user>/private-repo: 비공개 저장소, 기업 내부 데이터 등 보관
- 공격자는 공개 저장소에 악의적 Issue(프롬프트 인젝션 포함)를 생성함
- 사용자가 “public-repo의 이슈 목록을 봐줘” 같은 평범한 요청을 할 때, 에이전트는 공개 저장소 Issue를 가져오면서 인젝션에 노출됨
공격 흐름
- 에이전트가 악성 Issue를 읽은 순간, 비공개 저장소 데이터를 컨텍스트로 가져오고, 이를 공개 저장소에 PR 형태로 생성하여 누구나 접근 가능
- 이 과정을 Toxic Agent Flow라고 정의하며, Invariant의 보안 분석기로 실제 환경 내에서 자동 탐지 가능함

공격 시연

예시로 공개 저장소(ukend0464/pacman)와 비공개 저장소들로 공격을 재현함
공격자는 공개 저장소에 악의적 Issue를 생성하고, 에이전트가 해당 저장소의 Issue 목록을 조회할 때 프롬프트 인젝션이 실행됨
사용자가 Claude 4 Opus에게 지원 요청을 하면, Claude는 GitHub MCP 연동을 통해 인젝션을 실행
- Claude Desktop은 기본적으로 툴 사용시 확인을 요구하지만, 많은 사용자가 "항상 허용" 정책으로 운영하여 무심코 행동함
에이전트는 비공개 저장소 데이터를 추출해 공개 PR로 노출시킴
실험에서는 비공개 프로젝트명, 근무지 이전 계획, 급여 등 민감 정보까지 유출함

Toxic Agent Flows 탐지

이 취약점은 기존의 MCP 도구 자체가 침해되지 않아도, 외부 플랫폼(GitHub)에서 유입된 신뢰할 수 없는 정보로 인해 발생함
대규모 에이전트 시스템에서 이런 위험 분석 및 완화는 수작업으로 매우 복잡하므로, Invariant는 자동 탐지 방법을 개발해 선제적 위협 분석이 가능하도록 기능 제공함

영향 범위 및 대응 방안

이 취약점은 특정 에이전트/클라이언트에 한정되지 않고 MCP 서버를 사용하는 모든 에이전트에 영향
GitHub MCP 서버 코드 자체 결함이 아니라 설계적 문제로, GitHub 서버 패치로는 해결 불가
두 가지 핵심 대응 전략 제안

1. 세분화된 권한 통제

MCP 통합 환경에서 에이전트에게 반드시 필요한 저장소만 접근 가능하도록 최소 권한 원칙 적용 필요
전통적 토큰 기반 권한부여만으로는 사용성 제약이 큼

Invariant Guardrails 같은 동적 런타임 보안 레이어로, 워크플로우 맥락에 맞춰 접근제어 강화 가능

예시 정책: 세션당 한 저장소만 접근 허용해 크로스 저장소 정보유출 방지

정책 정의 예시:

raise Violation("You can access only one repo per session.") if:
    (call_before: ToolCall) -> (call_after: ToolCall)
    call_before.function.name in (...set of repo actions)
    call_after.function.name in (...set of repo actions)
    call_before.function.arguments["repo"] != call_after.function.arguments["repo"] or
    call_before.function.arguments["owner"] != call_after.function.arguments["owner"]

Guardrails Playground 등에서 정책 실험 가능

2. 지속적 보안 모니터링

예방책 외에도, 에이전트와 MCP 시스템 간 상호작용을 실시간으로 스캔하는 강력한 모니터링 도구 필요
예: Invariant MCP-scan 도입해 감시 및 이상 징후 탐지
최신 proxy 모드를 활용해, 현 인프라 변경 없이 MCP 트래픽만 프록시로 우회시켜 실시간 진단 가능
포괄적 감시를 통해 취약점 탐지, 침해시도 기록, 악성 흐름의 조기 차단 가능

모델 정합(Alignment)만으로 불충분한 이유

최신 대형 언어모델(예: Claude 4 Opus)조차도 단순 프롬프트 인젝션 공격에 쉽게 노출됨
기본적 정합(Alignment) 학습만으로 현실 배포 환경의 다양하고 맥락의존적 공격을 모두 방지할 수 없음
따라서, 시스템 차원의 맥락 감지 및 보안 체계를 모델 단계와 별도로 반드시 구축해야 함

결론

Invariant는 GitHub MCP 서버에서 에이전트를 악성 GitHub Issue로 장악하고 비공개 저장소를 유출시키는 심각한 취약점을 실증함
해당 취약점은 Invariant의 자동 탐지 시스템에서 발견된 대표 사례이며, MCP를 비롯한 다양한 환경에서 유사 공격 계속 발생 중임
MCP-scan 및 Guardrails 등 전용 보안 스캐너로 MCP/에이전트 시스템의 안전한 도입과 운영이 핵심임

참고 및 문의

추가 보안 적용, 컨설팅 필요 시 earlyaccess@invariantlabs.ai 를 통해 연락 가능

작성자:
Marco Milanta
Luca Beurer-Kellner

▲

crawler 1일전 [-]

거창하지만 그냥 프롬프트 인젝션+MCP가 쓸 수 있는 권한이 너무 많아서 생긴 문제네요
그래서 MCP 권한을 외부에서 제어할 수 있는 도구를 홍보하는 느낌입니다
외부에서 입력되는 프롬프트랑 내부에서만 입력하는 프롬프트랑 MCP가 쓸 수 있는 권한이 다르게 하면 좋겠네요

답변달기

▲

GN⁺ 1일전 [-]

Hacker News 의견

나는 이 공격이 완전히 이해되지 않는 느낌임. Claude에게 액세스 토큰을 주면, 어떤 용도로 쓰라고 지시하더라도 Claude가 해당 토큰의 권한 내에서 무엇이든 할 수 있도록 유도될 수 있다는 이야기임. LLM에 자격 증명을 제공하면 그 자격 증명의 모든 권한이 LLM이 활용할 수 있다고 생각해야 함. 툴 사용 호출을 자동 허용할 경우 특히 주의 필요함. 하지만 GitHub에는 세밀하게 권한을 제한할 수 있는 액세스 토큰이 있기 때문에, 특정 저장소만 접근 가능한 권한만 부여하면 LLM이 악용될 수 있는 범위가 제한됨. 이 공격은 LLM이 계정 전체에 대한 액세스를 가지는 경우에만 가능하고, 그런 위험한 자격 증명을 Claude에게 주는 것 자체가 문제임
- 이 주제에서 중요한 부분은, 대부분의 프롬프트 인젝션 공격처럼 LLM이 공격자가 조작하는 데이터, 민감 정보, 데이터 유출 기능 등 최소 세 가지 중 두 가지에 동시에 액세스하는 환경이 주어지는 점임. 에이전트 설계의 기본 원칙은 한 번에 두 개까지만 허용해야 하고, 이런 룰로 설계해야 보안 이슈를 막을 수 있음. 예를 들어 신뢰할 수 없는 사람이 만든 이슈를 보는 순간 이미 LLM의 컨텍스트는 공격자가 만든 데이터로 오염됨. 그다음 민감 정보에 접근하면 인터넷 연결 같은 기능은 해제시켜야 함. 이런 모델을 따르면, 저장소별 토큰 없이도 안전함. 아쉽게도 MCP는 이걸 보장하는 도구가 없음
- 토큰 권한이 너무 광범위하게 설정되는 문제가 있지만, 동시에 개발자들은 저장소마다 하나씩 토큰을 열어놓고 싶어하지 않음. 그래서 토큰에 광범위한 권한을 주면서 LLM을 무조건 신뢰하게 됨. 이런 주의가 현명하지만, 현실적으로 많은 생태계 플레이어들이 이런 실천을 하지 않음. 이번 리포트가 중요한 이유도 LLM이 권한과 신뢰할 수 없는 데이터만 있다면 뭐든지 하이재킹 당할 수 있음을 교육한다는 점임. 해결책은 동적으로 토큰의 활용 범위를 제한하는 것임. 우리가 이 리스트에서 이 방법을 연구 중임
- 이는 Railway 같은 서비스에서 발생할 수 있는 문제임. Railway는 단일 프로젝트 배포에도 전체 GitHub 저장소 접근 권한을 요구하는 경우가 있는데, Netlify는 원하는 저장소만 권한을 주도록 존중함. GitHub가 이렇게 접근 권한을 존중하지 않는 앱은 아예 승인 자체를 막아야 함
- 새로운 기술이 등장할 때마다 언제나 반복되는 현상임. 마치 기본 보안 원칙이 새로운 맥락에서는 무시해도 되는 것처럼 착각함. 사실 어떤 '반짝이는' 최신 기술을 쓰더라도 기본 보안 원칙은 결코 무시하면 안 됨. 암호화폐 판에서도 과거 사기나 금전적 범죄가 그대로 재현된 것도, 기술이 다르다는 이유로 예전 교훈을 무시한 결과임
- 챗봇이 사용자와 상호작용한다면 챗봇이 허용된 범위 내에서 뭐든지 다 하리라고 전제해야 함. 챗봇은 API 위의 편의 레이어일 뿐, 자체적인 보안 장치가 아님은 분명함
MCP, 에이전트 보안에 관심 있다면, 그간 작업한 여러 자료가 있음. 전체 공격 시나리오에 대한 Claude 실행 트레이스(링크), MCP 연결용 보안 스캐너(링크), MCP 도구 오염 공격(블로그), WhatsApp MCP 익스플로잇 사례(블로그), 에이전트용 보안 레이어 Guardrails(블로그), AI 에이전트의 보안과 유틸리티를 공동 평가하는 AgentDojo(블로그) 참고
이게 정말로 '익스플로잇'이라고 부를 만한가 의문임. 에이전트에게 비공개 저장소에 접근할 수 있는 토큰을 주면 접근 가능한 것임. MCP는 그냥 API 서버임. API로 노출시키지 않을 것엔 권한도 주지 않는 게 맞음
- 많은 사람들이 그렇듯 나도 글 읽기 전에 댓글부터 봤음. 실제 기사 내용을 보면, 악의적인 이슈가 GitHub에 등록되고, 이 이슈 안에 LLM을 이용해 데이터 유출을 유도하는 프롬프트가 포함됨. 저장소 소유자가 에이전트를 트리거할 때, 에이전트가 이 악성 프롬프트에 따라 행동하도록 함
- 이건 인간의 실수(혹은 과신)를 악용하는 진정한 익스플로잇임. 사람들이 과대광고에 넘어가서 사적으로 민감한 GitHub 전체 접근 토큰을 안심하고 LLM에 넘긴다는 게 문제임
- 주제가 중요해 살짝 꼬집고 싶은데, AI 툴 실행의 위험성을 모두가 정확히 이해해야 함. 에이전트들은 현재 주의력(컨텍스트)에 따라 툴을 실행하는데, 이 주의력이 툴의 실행 결과나 프롬프트에 쉽게 영향을 받음. 그런데 댓글에서는 단순히 “토큰을 줘서 생긴 일” 식의 주장만 반복함. 여기에, 문제를 제대로 설명한 후에도 계속 "사용자가 허락해서 그런거야"라는 식으로 논점을 흐리는 게 아쉽다는 생각임. 이건 'confused deputy' 문제에 대한 고전적인 잘못된 주장임. 또한 '사용자 책임론'을 내세우지만 실제론 MCP가 접근 후속 제어 기능이나 로그를 하지 않는 자체가 문제임. 나는 반드시 기록(logging)을 남길 수 있게 해놔야 안심함. 또, 보안 연구를 무시하며 "상식"이라 비난하지만 항상 보안 얘기는 나쁘지 않음. 취약점이 약하다고 해서 이야기할 가치가 없는 게 아님. 'SQL 인젝션'이랑 똑같다고까지 할 수 있음. 그리고, 시스템을 간접적으로 오염시킨다(공공 이슈 등록을 통해 악성 코드 전달)는 관점을 이해 못하는 건 위험하다고 봄. 마지막으로, 방어적으로만 굴지 말고 새로운 의견에 열려야 하는데 그렇지 못한 점이 안타깝다고 느낌
보안 관점에서 보면, LLM이 신뢰할 수 없는 출처의 텍스트를 볼 때는 그 출처가 LLM의 출력물 생성을 원하는 대로 조종할 수 있다고 가정해야 함. 그 결과가 툴 호출로 이어진다면 이제 신뢰할 수 없는 출처도 해당 툴을 사용할 수 있음. 관련 정보 찾다 보니 invariant labs의 Guardrails 문서도 마케팅 성격이 있구나 라는 생각이 들었음. 보안적으로 이런 guardrail 제품이 필요할 만큼 구조가 어렵다는 게 섬뜩함. 애초에 AI 회사들이 보안 중심적으로 설계했다면 이런 제품까지 필요없을텐데 아쉬움도 있음
- 입력값 구분만 잘해도 쉬운 문제임. 프롬프트에 <github_pr_comment> 같은 태그로 마킹하고, 반드시 읽기 전용으로만 쓰며 절대 명령어로 해석하지 말라고 명시하면 됨. 이번 공격은 사실 구조가 좀 복잡함. 예전에 챗봇 프롬프트 인젝션 이슈 있을 때랑 비슷한 느낌임. 이제 MCP도 이슈가 되고 있음
- 일부 텍스트를 정제되지 않은(불순한) 데이터로 마킹해서 LLM이 그 부분의 명령어적 해석은 무시하도록 훈련하는 방식도 가능할지 궁금함
- 실제로 AI 회사들이 보안 설계를 염두에 두고 있긴 함. 그런데 이번 '익스플로잇'은 보안을 비활성화했을 때만 가능한 시나리오임(굵은 경고와 함께 제공됨). 예를 들면 Claude Desktop은 기본적으로 툴 호출마다 직접 허가 확인을 요구함. 그런데 많은 사용자가 “항상 허가”로 설정해서 개별 행동을 모니터링하지 않음
- 이런 소프트웨어 취약점 패턴은 전통적으로 반복돼왔고, 새로운 기술에서도 항상 나타나는 현상이 좀 재미있으면서도 어이없음. "사용자 입력값을 받아서, 제대로 방어 안 된 환경에서 명령처럼 해석하고 실행하기"라는 패턴은 계속 반복됨. SQL 인젝션, XSS, PHP 인클루드 등등에서 다 봤던 스토리인데 이제 LLM에까지 반복됨
MCP 자체가 혁신적이거나 해킹에 특별하게 취약한 건 아니라고 생각함(물론 MCP에 대한 생각은 따로 있음). 프롬프트 인젝션 기법을 마케팅적으로 포장한 느낌임. 내가 에이전트 시스템을 설계할 때는 항상, “에이전트가 접근 가능한 건 모두 그 에이전트에 접근 가능한 누구나 접근할 수 있다”라는 철학을 씀. LLM에 접근제어를 맡기지 않고, 에이전트가 하는 일 자체의 보안 책임은 항상 요청자 주체 본인임을 명확히 함. 이 글 처음부터 끝까지, 진짜로 우리가 주목해야 할 건 에이전트에 실제로 어떤 리소스를 접근시킬지 임. 이메일 데이터 접근을 허용하고, 프롬프트 인젝션 이메일이 보안 토큰을 훔쳐서 전달하도록 LLM을 유도하면 그게 진짜 심각한 위험임
- MCP 이야기 붙이는 게 마치 10년 전 “블록체인에 올렸어요” 유행과 같은 느낌임. "LLM이 승인 및 행동 주체니까 최소 권한 원칙을 엄격히 적용해야 한다"는 말은 모든 경험자에게는 당연한 이야기인데 어쩌면 또 새로운 세대가 이런 기본을 새로 배워야 하나 싶음
실제 공격 사례와 에이전트 반응은 여기에서 확인 가능함. 에이전트가 공격을 완전히 성공시켰다는 점이 다소 웃음 포인트임
나도 일주일 전에 Google's Jules 코딩 에이전트를 써봤는데, GitHub OAuth 권한 요청이 계정 내 모든 저장소와 권한에 대한 전면적인 접근을 요구했음. 이런 디자인이 개발자 편의 때문이기도 하고, GitHub OAuth 인증 플로우 자체도 원인임. 애초에 더 간편하게 저장소 단위의 제한적 권한 부여 및 이후 추가 권한 요청이 가능해야 함. 그런데 현실은 특정 저장소만 권한을 주는 별도의 깃헙 계정을 만들 수밖에 없음(예시 계정). 굉장히 번거로움. GitHub 공식 문서에서도 이런 머신유저를 따로 만들라고 추천하긴 하는데, 기본 저장소 범위 지정이 더 쉬워야 함. 혹시 더 나은 방법 아는 사람 있으면 꼭 알려줬으면 함
- GitHub 설정 페이지에서 Jules 권한을 특정 저장소로 제한할 수 있음
이번 글의 주장은 너무 과장됐다고 느낌. 간단한 이슈로 데이터 유출이 됐다는 설명에 대해, 사실 실제로는 유저가 여러 보안적으로 위험한 조치를 다 직접 해야만 가능했던 일임. 즉, MCP 서버를 세팅하고, public/private repo 모두 접근 가능한 인증 정보를 부여하고, LLM이 그 서버 접근 및 저장소 이슈 읽기를 허용했고, 그리고 악성 이슈까지 직접 읽어서, 외부에 결과를 공개하는 식으로 설정해야 가능했던 일임. 나쁜 결과이긴 하지만, 이게 실제로는 “타인이 악의적으로 공격하는 보안 취약점”이라고 할 만한 건 아님. 사용자가 직접 신뢰할 수 없는 데이터를 읽고 결과도 신뢰할 수 없는 곳에 내보내도록 한 결과임. 그런데도 GitHub MCP도 일정 부분 책임 있음. 공개/비공개 저장소간 교차 처리를 막지 않은 건 문제임
- 본질적으로, “이슈들을 요약해 주세요” 정도의 단순 명령만으로도, 악성 이슈에 직접 담긴 명령이 이행될 수 있다는 점을 간과하면 안 됨
- MCP 마케팅 관점도 중요함. 프로토콜 자체는 신뢰할 수 있는 환경이나 사용자들만 접근시키는 식으로 분리하는 게 맞음. MCP 서버에 범위를 지정하거나 인증하는 표준 방안이 없는 게 문제임. 나는 Github MCP 자체보다 우리 산업 전체적인 사용법/구현방법에 근본적 이슈가 있다고 느낌. 실제로 커스텀 MCP 서버 쓸 때는 AI 이외의 정보(ID, JWT 등)도 추가로 전달해서 보안 차단을 함
- 요즘 AI 열풍 때문에, 사실 이런 위험한 설정과 흐름을 아무 생각 없이 적용하는 사람들이 많다는 게 현실임. “이런 것 쓰면 안 되지”라고 뻔히 말할 수 있지만, 그래서 guardrails(보안 레일)가 꼭 필요한 거임. 사람들은 종종 위험한 결정을 하기 때문임
- 공개/비공개 저장소를 섞어서 쓰지 말라는 주장에 대해, 실제론 이건 서로 완전히 분리된 툴 호출임. MCP 서버 입장에서는 그 상호작용을 감지할 방법이 없음
지금 논의가 해당 HN 쓰레드에서 진행되고 있다는 점을 발견함
- 저쪽에서도 이미 언급됐지만, 보안상의 위험은 명확함. 즉, 시스템에 사적 데이터 접근 권한을 부여하고, 외부 사용자에게도 임의의 입력 텍스트를 넣을 수 있게 허용하면, 결과적으로 외부 사용자에게 비공개 데이터까지 간접적으로 제공하는 격임. 표준 보안 관행만 지키면 쉽게 막을 수 있는 문제임
- 현재 댓글은 여기로 이동해서 모여있음
MCP는 단지 하나의 프로토콜이고, A2A 등 유사 사례나 원시적 접근 방법도 많음. LLM에게 GitHub API 문서 읽고 토큰으로 API 활용하라고 시킬 수도 있음. 아직 모든 LLM이 이 수준의 기능을 갖추진 않았지만, 곧 그렇게 될 것임. 도구 등록 메커니즘을 완벽히 보안하기란 현실적으로 불가능에 가까움. 데이터 유출의 최종 책임은 결국 LLM에 있음. 개발자들은 LLM 생산성 향상을 바라기 때문에 안전성이 담보되거나, 아니면 모든 노트북에 보안 방화벽을 추가해야 하는 상황까지 올 수 있음. 정말 골치 아픈 점은, 미래에는 LLM이 보안 방화벽까지 악용한 ‘나쁜 행동하는 LLM 잡는 LLM’ 대결까지 이어질 것 같기도 함

답변달기