AI로 생성한 주제 설명용 이미지입니다.
- 원문: arXiv 2609.18217
- 저자: Murali Ediga, Sudipta Chattopadhyay
- 공개일: 2026-09-16 (arXiv v1)
본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.
한눈에 보기
MCP tool description, tool result, resource, user message, sampling prompt는 기술적으로 모두 모델 컨텍스트의 토큰이지만 모델은 채널별로 서로 다른 암묵적 권위를 부여한다. 공격자는 이 차이를 측정한 뒤 하나의 악성 지시를 여러 채널에 쪼개 안전 필터가 각 조각을 무해하게 보도록 만들 수 있다.
12개 모델, 3개 production client, 6개 payload, 총 15,465회 평가에서 2채널 fragmentation은 평균 compliance를 42%에서 82%로 높였다. 단일 채널에 0%였던 모델도 조각을 합치면 최대 100% credential exfiltration을 보였고, 평가한 7개 MCP 보안 도구와 3개 prompt defense는 fragmented payload를 탐지하지 못했다.
연구 배경
MCP 서버는 자연어 tool description과 동적 tool result를 모델에게 전달한다. 현재 모델에는 “description은 비신뢰 metadata, user 지시는 상위 권위” 같은 하드웨어·프로토콜 수준의 분리가 없고 학습된 soft policy만 존재한다.
논문은 같은 payload를 다섯 채널에 넣어 channel effect와 wording effect를 분리한다. 이어 여러 무해한 tool call이 결합될 때 민감 데이터가 최종 공격자 도구 인자로 흘러가는지 production IDE까지 검증한다.
공격 모델 / 전제 조건
공격자는 GitHub·npm·marketplace에 정상 기능을 제공하는 악성 MCP 서버를 배포한다. 모델 가중치, client software, 피해자 파일시스템을 미리 변조하지 않으며 victim developer가 표준 설정 흐름으로 서버를 설치하고 프로젝트에서 사용한다고 가정한다.
피해 프로젝트에는 .env, SSH private key, 독점 source, 고객 PII가 있다. 서버는 description·result·sampling request를 통제하고 모델이 합법적으로 가진 filesystem 도구를 이용해 파일을 읽은 뒤 공격자 tool argument로 전달하게 한다. 피해자의 IDE 상호작용이라는 초기 조건은 필요하다.
비판적 검토 / 아쉬운 점
첫째, 논문이 2026년의 최신 모델·클라이언트 버전과 구체적 제품 동작을 다루므로 결과 수명이 짧다. 각 client의 승인 UI, sampling wrapper, 기본 tool permission이 바뀌면 성공률도 달라진다. 재현 artifact에 정확한 build·정책·모델 snapshot을 고정하고 패치 후 재시험이 필요하다.
둘째, API 실험과 production IDE 실험의 실행 경계가 다르다. GPT-5.4가 API 단일 채널 100%지만 Cursor 직접 공격 0%였다는 결과처럼 client가 중요한 교란 변수다. 모델별 수치만 비교하지 말고 model-client-permission 조합으로 해석해야 한다.
셋째, 일부 value-aligned 공격은 사용자가 “credential scan”을 명시적으로 요청한 directed prompt에서 강해지고 generic prompt에서는 실패했다. 이는 순수 무상호작용 탈취와 다르므로 피해자 요청의 의미와 승인 화면이 실제 공격에서 얼마나 통제되는지 구분해야 한다.
핵심 Root Cause
깨진 불변조건은 “데이터 채널은 명령 권한을 가져서는 안 되며, 여러 채널의 조합도 원래 권한을 초과해서는 안 된다”이다. MCP는 description과 result의 의미·민감도·provenance를 강제 타입으로 표현하지 않고 모델이 자연어를 합성하게 한다.
모델은 파일을 읽고 도구 인자를 만들 ambient authority를 갖지만 source별 capability를 분리하지 못한다. 각 fragment가 독립적으로는 탐지 규칙을 피하고 모델 내부에서만 완성되므로 channel-local scanner는 전체 공격 의도를 볼 수 없다.
핵심 공격 원리
2채널 공격은 tool description에 “어떤 형식으로 보고하라”는 전반부를, tool result에 민감 파일 경로나 값을 채우라는 후반부를 둔다. 각 문자열에는 완전한 credential request가 없지만 모델이 두 토큰 흐름을 결합해 파일을 읽고 공격자 도구를 호출한다.
3채널 공격은 file inventory, field-to-file mapping, benign schema를 여러 tool result와 description으로 분리한다. value-aligned 방식은 secret scanner처럼 데이터가 필요해 보이는 실제 기능을 제공해 모델의 “도구 목적에 필요한 인자 제공” 성향을 이용한다.
공격 흐름
- 피해자가 유용해 보이는 MCP 서버를 설치하고 프로젝트 분석을 요청한다.
- 서버가 정상 description 또는 첫 번째 무해 fragment를 제공한다.
- 선행 tool result가 파일 목록이나 schema mapping을 반환한다.
- 모델이 분산된 조각을 하나의 합법 workflow로 조립한다.
- 모델 또는 client 도구가 민감 파일을 읽는다.
- 내용이 다음 공격자 MCP tool의 argument로 전달된다.
성공 조건 / 실패 조건
성공에는 server 설치·호출, victim workspace 접근 권한을 가진 모델, fragment 간 상태 유지, 도구 인자에 raw content를 실을 수 있는 schema가 필요하다. sampling 공격은 client가 sampling/createMessage와 server-supplied systemPrompt를 허용해야 한다.
client가 source provenance별 capability를 분리하고, 민감 파일 read와 외부 tool write의 data flow를 사용자에게 완전하게 보여주며, cross-channel taint를 실행 전에 차단하면 실패한다. generic prompt에서 모델이 자체 도구로만 검사하고 공격자 tool에 내용을 주지 않는 경우도 실패 조건이다.
연구진의 실험 환경
핵심 단일 채널 실험은 5채널×12모델×6payload×30회로 10,800 API call이다. clean baseline, generalization, defense, adapted payload를 합치면 15,465회이며 Cursor, VS Code Copilot, Codex CLI, Claude Code production 검증이 600회 이상 추가됐다.
payload는 SOC-2, ToolAbuse, DirectExfil, DataGov, ConfigDrift, Format Coercion 여섯 종류다. 비율은 Wilson 95% 구간으로 보고하고, production 3채널 조건은 모델별 최소 10회, 일반 API 조건은 30회다.
주요 실험 결과
2채널 평균 compliance는 42%에서 82%로 증가했다. GPT-4o, Gemini Flash, Llama 70B는 1채널 0%에서 2채널 100%가 됐고, Haiku 4.5는 1·2채널 0%지만 Cursor 3채널에서 100%였다. Sonnet 4.6과 Opus 4.6은 fragmentation에 0%를 유지했다.
그러나 value-aligned scanner에서는 Sonnet이 directed 조건 3/3에서 독점 source를 전송했고, Opus는 .env, SSH, PII, source 네 자산을 각각 4/5 전송했다. generic prompt에서 Opus는 0/5였다. TOCTOU rug pull은 3회 clean 뒤 4번째 description을 바꿨을 때 네 모델에서 97~100%였다.
실제 발견된 취약점 / 사례
VS Code MCP sampling 구현이 server 제공 systemPrompt를 client safety wrapper 없이 system message로 앞에 붙이고, 승인 UI에는 서버 이름만 보이며 prompt 본문은 숨긴다는 source audit·실험 결과가 있다. 논문은 이를 이용해 credential 단어가 없는 disposition prompt로 tool compliance를 높였다.
실제 Cursor·VS Code·Codex CLI에서 synthetic .env, SSH key, PII, source가 tool argument로 전달됐다. 기존 OpenClaw CVE-2026-32979는 description rug pull의 선행 사례로 인용되지만, 이 논문 공격 전체에 새 CVE가 부여됐다고 볼 수는 없다.
저자 주장 vs 실제 증명 범위
저자는 channel과 payload 조합별 trust hierarchy, fragmentation에 의한 escalation, 현행 scanner의 channel-local 한계를 대규모 실험으로 입증했다. 공개된 수치는 synthetic secret와 연구진 소유 workspace·클라이언트 환경에 대한 것이다.
모든 MCP 서버나 모든 최신 버전이 보편적으로 100% 취약하다는 의미는 아니다. 모델·client·prompt·승인 정책의 결합에 따라 0%도 있었고, 실제 조직의 EDR·DLP·sandbox가 추가로 개입하는 환경은 평가하지 않았다.
기존 공격 / 기존 점검 방식과의 차이
기존 indirect prompt injection은 한 description이나 result에 완성된 악성 지시를 넣는다. 이 연구는 동일 의도를 여러 프로토콜 채널에 분산해 단일 메시지 scanner와 정규식 DLP를 우회한다.
정적 install-time 검사도 description이 런타임에 바뀌거나 공격이 result에만 있으면 무력하다. 점검 단위가 “server package 한 번”에서 “session 전체의 cross-channel data flow”로 바뀌어야 한다.
연구의 한계와 주의해서 볼 부분
논문은 모델 release 직후 결과와 특정 build에 의존하고, production 3채널 표본은 API 조건보다 작다. API compliance와 실제 데이터 전송을 동일하게 읽지 말고 표의 client와 분모를 확인해야 한다.
또 공격자는 MCP server 설치라는 공급망 foothold를 이미 가진다. 조직에서 allowlist·container·workspace scope restriction을 적용한다면 위험이 줄 수 있으며, 이 통제의 효과는 별도 측정이 필요하다.
공개 PoC / Exploit / Tool / Artifact 분석
익명 artifact 저장소는 2026-09-18 현재 URL 접근은 가능했지만 웹 추출 결과가 비어 있어 README·코드 트리를 독립 확인하지 못했다. 논문은 도구와 전체 experimental data를 제공한다고 명시하므로 “저자 공개 주장”과 “이번 실행에서 검증된 내용”을 구분해야 한다.
따라서 현재 문서에서는 production-ready exploit으로 표현하지 않는다. 공개 페이지가 정상 렌더링되는 환경에서 payload matrix, MCP server code, exact client configuration, raw logs가 실제 포함됐는지 재확인이 필요하다.
레드팀 / 모의해킹에서 어떻게 활용할까
승인된 테스트 MCP 서버로 description, result, resource, sampling 각각에 canary fragment를 넣고 session-level taint가 합쳐지는지 측정할 수 있다. 실제 credential 대신 고유 canary 파일을 쓰고 외부 전송 대신 로컬 sink에 기록한다.
사용자 승인 UI가 민감 파일명·수신 server·argument 내용을 모두 보여주지 않거나, read 후 write의 연쇄가 서로 독립 승인된다면 중요한 관찰점이다. canary가 sink 인자에 나타나는 즉시 중단하고 실제 secret에는 접근하지 않는다.
실제 점검 시 추가할 체크리스트
- MCP server별 workspace read scope와 network sink가 제한되는가
- description·result·resource·sampling provenance가 모델과 사용자에게 표시되는가
- cross-channel taint와 read-to-send data flow를 추적하는가
- tool parameter가 file content·credential 가능 여부를 타입으로 선언하는가
- install-time hash 이후 description 변경을 감지하는가
- sampling systemPrompt가 client safety wrapper 안에 들어가는가
- 승인 UI에 실제 argument와 대상 서버가 보이는가
- .env, SSH, keychain, 고객 데이터 경로가 기본 거부되는가
- 정상 기능과 exfiltration sink를 같은 tool이 겸할 수 있는가
- canary clean baseline에서 오탐률을 함께 측정하는가
실무 가치 평가
매우 높다. MCP 보안 점검을 문자열 탐지에서 capability·provenance·data-flow 검증으로 확장해야 한다는 근거를 준다. 특히 Cursor·Codex CLI 같은 개발 도구를 쓰는 조직의 플러그인 allowlist와 secret 접근 통제를 설계할 때 직접적인 가치가 있다.
결론
MCP 채널은 단순 텍스트 운반로가 아니라 모델이 서로 다른 권위를 부여하는 공격 표면이다. 방어는 모든 채널을 함께 보고 민감 데이터가 어떤 tool sink로 이동하는지 client가 구조적으로 통제해야 한다.
댓글