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

2 weeks ago 6

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/에이전트 시스템의 안전한 도입과 운영이 핵심임