MCP 서버가 새로운 공격 표면입니다

이제 Model Context Protocol은 보안 데이터베이스를 가지게 되었습니다. 항목은 50개에 달합니다.¹

60일 동안 30건의 CVE가 등록되었습니다. 조사된 2,614개의 MCP 구현체 중 82%가 경로 순회에 취약한 파일 작업 취약점을 가지고 있었습니다. 서버의 38%에서 41%는 인증 자체가 아예 없었습니다.² 공식 MCP Inspector 도구 – 개발자들이 MCP 서버를 디버깅할 때 사용하는 바로 그 도구 – 에도 RCE 취약점이 있었습니다. 널리 사용되는 mcp-remote 패키지에는 OS 명령 주입 버그가 있었습니다.¹

이것은 이론적인 공격 표면이 아닙니다. 실제 개발자들이 지금 이 순간 Claude Code, Codex CLI, Cursor에 연결하고 있는 실제 패키지의 실제 CVE입니다. 이 글은 agent security 영역을 프로토콜 수준의 위협 분석으로 확장합니다.

TL;DR

MCP 서버는 에이전트 생태계에서 가장 빠르게 성장하는 통합 표면입니다. 동시에 가장 감사가 이루어지지 않는 영역이기도 합니다. 취약점 데이터베이스에는 50개의 항목이 있으며, 그중 13개는 Critical, 32개는 High 등급입니다. 입력 검증 실패와 프롬프트 주입이 50개 중 30개를 차지합니다. 이번 주 단 하루 만에 서로 다른 MCP 서버 3곳에서 SSRF 취약점 3건이 발견되었습니다.³ 패턴은 분명합니다. 커뮤니티가 MCP 서버를 검토하는 속도보다 배포하는 속도가 더 빠릅니다.

핵심 요점

• Claude Code 사용자: 연결하는 모든 MCP 서버는 여러분이 확장하는 신뢰 경계입니다. 지금 당장 claude mcp list를 실행해서 연결된 서버를 감사하세요. 몇 달 전에 설치한 커뮤니티 MCP 서버를 계속 사용하고 있다면, 그 이후에 패치되었는지 확인하세요.
• 하니스 제작자: PreToolUse hooks는 MCP 도구 호출이 감사되지 않은 서버에 도달하기 전 마지막 방어선입니다. URL, 파일 경로 또는 셸 명령을 받는 서버의 경우, 실행 전에 MCP 도구 입력을 검증하는 훅을 고려하세요.
• MCP 서버 작성자: MCP 스펙은 “항상 사람이 루프에 있어야 한다(SHOULD)”고 명시합니다. 이를 MUST로 취급하세요. 모든 입력을 검증하세요. 문자열 보간을 통해 사용자 제어 문자열을 셸 명령에 절대로 전달하지 마세요. URL 검증 없이 OpenAPI 스펙의 $ref 값을 절대로 신뢰하지 마세요.

수치

Vulnerable MCP Project는 문서화된 MCP 보안 문제의 데이터베이스를 유지 관리합니다.¹ 현재 상태는 다음과 같습니다.

심각도: Critical 13개, High 32개, Medium 5개입니다.¹ 32명의 보안 연구자가 발견 사항을 기여했습니다. 영향을 받은 서버에는 Anthropic의 자체 Git MCP 서버, 공식 MCP Inspector, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes, 그리고 20개 이상의 커뮤니티 구축 서버가 포함됩니다.¹

설문조사 결과 중 가장 충격적인 것은 이것입니다. 2,614개 MCP 구현체의 82%가 경로 순회에 취약한 파일 작업 취약점을 가지고 있었습니다.² MCP 서버 5개 중 4개는 공격자가 접근해서는 안 될 파일을 읽을 수 있게 허용합니다.

다섯 가지 공격 패턴

60일간의 CVE 물결은 다섯 가지 반복되는 패턴을 드러냈습니다.²

1. 도구 포이즈닝. MCP 도구 설명에 악성 지시 사항이 삽입됩니다. 에이전트는 해당 설명을 읽고, 신뢰하며, 자신의 승인된 도구를 사용해 숨겨진 지시를 따릅니다. 포이즈닝된 도구 자체는 실행되지 않습니다 — 에이전트의 정당한 도구가 공격을 수행합니다. 이 패턴은 deploy-and-defend paradox에서 다루었습니다. 신뢰는 전이적이지만 감사는 그렇지 않습니다.

2. 외부 데이터를 통한 프롬프트 주입. GitHub 이슈, Slack 메시지, 이메일 또는 웹페이지에서 콘텐츠를 가져오는 MCP 서버는 공격자가 제어하는 텍스트를 에이전트의 컨텍스트로 들여옵니다. 주입은 MCP 서버를 겨냥하지 않습니다 – 서버의 출력을 읽는 에이전트를 겨냥합니다. silent egress attack surface가 일반적인 경우이며, MCP 서버가 가장 흔한 벡터입니다.

3. 초기 승인 이후의 신뢰 우회. Claude Code는 처음에 MCP 서버를 승인하도록 요청합니다. 그 이후에는 도구 정의가 세션 간에 변경되어도 모든 경우에 다시 프롬프트가 표시되지는 않습니다. 설치 시점에 안전했던 서버가 업데이트 시점에 다르게 동작할 수 있습니다. 재검증 격차는 구조적입니다. 프로토콜이 도구 설명의 암호화 서명을 요구하지 않기 때문입니다.²

4. 공급망 침해. 레지스트리에 게시된 백도어가 심어진 MCP 서버와 합법적인 서버를 사칭하는 패키지가 이에 해당합니다. the supply chain is the attack surface에서 문서화한 것과 동일한 공급망 패턴이 MCP 생태계에 적용된 것입니다.

5. 테넌트 간 노출. 여러 MCP 서버가 실행 전에 서로의 함수 호출을 가로챌 수 있는 공유 호스팅 환경에서 발생합니다.⁴ 외부에서 견고해 보이는 격리 경계가 여러 서버가 프로세스나 컨테이너를 공유할 때 무너집니다.

SSRF 패턴

이번 주 단 한 번의 스캔에서 서로 다른 MCP 서버 3곳에서 SSRF 취약점 3건이 발견되었습니다.³

• n8n-mcp: 인스턴스 호스트 주입을 통한 인증된 SSRF
• mcp-from-openapi: OpenAPI 명세의 $ref 값을 통한 SSRF. 내부 URL을 포함한 악성 스펙이 초기화 중에 서버가 해당 리소스를 가져오도록 유도합니다
• stata-mcp: 사용자가 제공한 URL에 대한 불충분한 검증

MCP 서버의 SSRF가 특히 위험한 이유는 서버가 일반적으로 에이전트에게는 없는 네트워크 접근 권한을 가지기 때문입니다. 단 하나의 악성 OpenAPI 스펙이 자격 증명 탈취로 이어지는 과정은 다음과 같습니다.

1단계. 공격자가 외부 API를 래핑하는 합법적으로 보이는 MCP 서버를 게시합니다. 이 서버는 mcp-from-openapi를 사용해 OpenAPI 명세에서 도구를 생성합니다.

2단계. OpenAPI 스펙에는 내부 주소를 가리키는 $ref가 포함되어 있습니다.

components:
  schemas:
    Config:
      $ref: "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"

3단계. initialize() 중에 MCP 서버는 URL을 가져와 $ref를 해결합니다. 서버는 여러분의 인프라에서 실행됩니다. VPC 내부, 여러분의 노트북, CI 컨테이너 안에서 말입니다. 요청은 신뢰할 수 있는 출처에서 AWS 메타데이터 엔드포인트로 전달됩니다.

4단계. 메타데이터 엔드포인트는 임시 IAM 자격 증명(액세스 키, 시크릿 키, 세션 토큰)을 반환합니다.

5단계. 이제 서버는 여러분의 클라우드 자격 증명을 가지고 있습니다. 도구 응답을 통해 유출하거나, 외부 엔드포인트에 로깅하거나, 직접 사용할 수 있습니다.

에이전트는 악의적인 행동을 하지 않았습니다. 사용자는 MCP 서버를 승인했습니다. OpenAPI 스펙은 정상으로 보였습니다. $ref 해결은 아무도 검토하지 않는 라이브러리 수준에서 일어났습니다. SSRF는 MCP 서버의 네트워크 위치를 공격자의 네트워크 위치로 전환시켰습니다.

Microsoft는 2026년 3월에 치명적인 Azure MCP SSRF(CVE-2026-26118)를 패치했습니다. 동일한 패턴이 Azure에도 적용되었습니다. 인증 토큰을 훔치고 Azure 리소스에 무단 접근을 허용할 수 있는 높은 심각도의 권한 상승 취약점이었습니다.⁵

대응 방법

연결된 서버를 감사하세요. claude mcp list를 실행하고 모든 서버를 검토하세요. Vulnerable MCP Project 데이터베이스와 대조 확인하세요.¹ 적극적으로 사용하지 않는 서버는 제거하세요.

서버 버전을 고정하세요. npm이나 pip에서 MCP 서버를 설치한다면 버전을 고정하세요. 자동 업데이트는 사용하지 마세요. 업그레이드 전에 변경 로그를 검토하세요. 신뢰 우회 패턴은 업데이트가 재승인 없이 도구 정의를 변경할 수 있음을 의미합니다.

입력 검증 훅을 추가하세요. MCP 도구 호출에 대한 PreToolUse hook은 서버에 도달하기 전에 입력을 검증할 수 있습니다.

#!/bin/bash
# .claude/hooks/validate-mcp-input.sh
INPUT_JSON=$(cat)
TOOL_NAME=$(echo "$INPUT_JSON" | jq -r '.tool_name // empty')

# Block MCP tools that accept URLs from passing internal addresses
if echo "$TOOL_NAME" | grep -q "^mcp__"; then
  TOOL_INPUT=$(echo "$INPUT_JSON" | jq -r '.tool_input | tostring')
  if echo "$TOOL_INPUT" | grep -qiE '(169\.254\.|10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|metadata\.google|169\.254\.169\.254)'; then
    echo "Blocked: MCP tool input contains internal/metadata address" >&2
    exit 2
  fi
fi
exit 0

전송 격리를 고려하세요. runtime defense patterns for tool-augmented agents가 여기에 직접 적용됩니다. 모든 MCP 서버는 에이전트가 호출하는 도구이며, 방어 아키텍처는 침해된 도구를 고려해야 합니다. HTTP MCP 서버는 명시적인 네트워크 경계를 가진 자체 프로세스에서 실행됩니다. Stdio 서버는 에이전트의 프로세스 컨텍스트를 공유합니다. 어떤 전송 방식도 본질적으로 안전하지는 않습니다. 더 큰 요인은 서버가 자격 증명, 내부 네트워크 또는 민감한 파일 경로에 접근할 수 있는지 여부입니다. 위협 모델에 필요한 격리 경계를 제공하는 전송 방식을 선택하세요.

데이터베이스를 주시하세요. vulnerablemcp.info의 Vulnerable MCP Project는 MCP 생태계에서 CVE 추적기에 가장 가까운 존재입니다. 새 서버를 설치하기 전에 확인하세요.

MCP 생태계는 빠르게 성장하고 있습니다. 인덱싱된 서버는 3,000개 이상이며, 월간 다운로드는 1억 회에 달합니다.⁶ 보안 태세는 그 속도를 따라가지 못하고 있습니다. 1년 전에는 존재하지도 않았던 데이터베이스에 취약점이 50개나 있습니다. 문제는 프로토콜이 아닙니다. 구현이 문제입니다. 그리고 your agent has a middleman에서 문서화했듯이, 에이전트 도구 체인의 모든 중간 개체는 대부분의 개발자가 감사하지 않는 가로채기의 기회입니다.

출처

자주 묻는 질문

Claude Code에 번들로 포함된 MCP 서버도 영향을 받나요?

이 취약점들은 주로 커뮤니티에서 구축한 서드파티 MCP 서버에 영향을 미치며, 핵심 Claude Code MCP 인프라에는 해당되지 않습니다. 다만 공식 MCP Inspector 도구에도 RCE 취약점이 있었으므로 “공식”이라는 것이 “면역”을 의미하지는 않습니다.

MCP 서버 사용을 중단해야 할까요?

아닙니다. MCP는 강력한 통합 계층입니다. 다만 모든 MCP 서버를 신뢰 경계로 취급하세요. 연결된 것을 감사하고, 버전을 고정하며, URL, 파일 경로 또는 셸 명령을 받는 서버에는 입력 검증 훅을 추가하세요.

제 MCP 서버가 취약한지 어떻게 확인하나요?

claude mcp list를 실행해 연결된 서버를 확인하세요. 각 서버를 Vulnerable MCP Project database와 대조 확인하세요. 서버의 GitHub 저장소에서 최근 보안 권고를 확인하세요.