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예요.

요약

MCP 서버는 에이전트 생태계에서 가장 빠르게 성장하는 통합 표면이면서, 동시에 가장 감사가 이루어지지 않는 영역이에요. 취약점 데이터베이스에 50개의 항목이 있고, 치명적 13개, 높음 32개입니다. 입력 유효성 검사 실패와 프롬프트 주입이 50개 중 30개를 차지해요. 이번 주에 하루 만에 세 개의 서로 다른 MCP 서버에서 SSRF 취약점 세 건이 발견됐습니다.³ 패턴은 분명해요: 커뮤니티가 MCP 서버를 검토하는 속도보다 배포하는 속도가 훨씬 빠릅니다.

핵심 요점

• Claude Code 사용자: 연결하는 모든 MCP 서버는 여러분이 확장하는 신뢰 경계입니다. 지금 바로 claude mcp list를 실행해서 연결된 서버를 감사하세요. 몇 달 전에 설치한 커뮤니티 MCP 서버를 운영 중이라면, 이후 패치가 됐는지 확인하세요.
• 하네스 개발자: PreToolUse 훅은 MCP 도구 호출이 감사되지 않은 서버에 도달하기 전의 마지막 방어선이에요. URL, 파일 경로, 셸 명령어를 받는 서버에 대해서는 MCP 도구 입력을 실행 전에 검증하는 훅을 고려하세요.
• MCP 서버 개발자: MCP 사양에는 “항상 사람이 개입해야 한다(SHOULD)”고 되어 있어요. 이를 반드시(MUST)로 취급하세요. 모든 입력을 검증하세요. 사용자가 제어하는 문자열을 문자열 보간으로 셸 명령어에 전달하지 마세요. OpenAPI 사양의 $ref 값을 URL 검증 없이 신뢰하지 마세요.

수치로 보는 현황

Vulnerable MCP Project는 문서화된 MCP 보안 이슈 데이터베이스를 유지하고 있습니다.¹ 현재 상태는 다음과 같아요:

심각도: 치명적 13개, 높음 32개, 중간 5개.¹ 32명의 보안 연구자가 발견 사항을 기여했어요. 영향받는 서버에는 Anthropic의 자체 Git MCP 서버, 공식 MCP Inspector, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes, 그리고 20개 이상의 커뮤니티 제작 서버가 포함됩니다.¹

설문 결과가 가장 충격적이에요: 2,614개 MCP 구현체 중 82%에서 경로 탐색에 취약한 파일 작업 취약점이 발견됐습니다.² MCP 서버 다섯 개 중 네 개가 공격자에게 접근 권한이 없는 파일을 읽을 수 있게 해줍니다.

다섯 가지 공격 패턴

60일간의 CVE 물결에서 다섯 가지 반복 패턴이 드러났습니다:²

1. 도구 오염. MCP 도구 설명에 악의적인 지시가 삽입되는 방식이에요. 에이전트가 설명을 읽고 신뢰한 뒤, 자신의 인가된 도구를 사용해 숨겨진 지시를 수행합니다. 오염된 도구는 실행되지 않아요 — 에이전트의 정상적인 도구가 공격을 수행합니다. 배포와 방어의 역설에서 이 패턴을 다뤘어요: 신뢰는 전이되지만, 감사는 전이되지 않습니다.

2. 외부 데이터를 통한 프롬프트 주입. GitHub 이슈, Slack 메시지, 이메일, 웹 페이지에서 콘텐츠를 가져오는 MCP 서버는 공격자가 제어하는 텍스트를 에이전트의 컨텍스트로 가져옵니다. 주입은 MCP 서버를 겨냥하는 게 아니라, 서버의 출력을 읽는 에이전트를 겨냥해요. 은밀한 유출 공격 표면이 일반적인 사례이고, MCP 서버는 가장 흔한 경로입니다.

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

4. 공급망 침해. 정상적인 서버를 사칭하는 패키지를 포함해, 레지스트리에 백도어가 심어진 MCP 서버가 게시되는 방식이에요. 공급망이 공격 표면이다에서 문서화한 것과 동일한 공급망 패턴이 MCP 생태계에 적용된 것입니다.

5. 교차 테넌트 노출. 여러 MCP 서버가 실행 전에 서로의 함수 호출을 가로챌 수 있는 공유 호스팅 환경입니다.⁴ 외부에서는 견고해 보이는 격리 경계가 여러 서버가 프로세스나 컨테이너를 공유하면 무너져요.

SSRF 패턴

이번 주 한 번의 스캔에서 세 개의 서로 다른 MCP 서버에서 세 건의 SSRF 취약점이 발견됐습니다:³

• 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 훅은 입력이 서버에 도달하기 전에 검증할 수 있습니다:

#!/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

전송 격리를 고려하세요. HTTP MCP 서버는 명시적인 네트워크 경계가 있는 자체 프로세스에서 실행돼요. Stdio 서버는 에이전트의 프로세스 컨텍스트를 공유합니다. 어느 전송 방식도 본질적으로 안전하지 않아요 — 더 중요한 요소는 서버가 자격 증명, 내부 네트워크, 민감한 파일 경로에 접근할 수 있는지 여부입니다. 위협 모델이 요구하는 격리 경계에 맞는 전송 방식을 선택하세요.

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

MCP 생태계는 빠르게 성장하고 있어요 — 3,000개 이상의 인덱싱된 서버와 월간 1억 회 이상의 다운로드입니다.⁶ 보안 태세는 이 성장을 따라가지 못하고 있습니다. 1년 전에는 존재하지도 않았던 데이터베이스에 50개의 취약점이 있어요. 프로토콜이 문제가 아닙니다. 구현이 문제예요.

출처

자주 묻는 질문

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

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

MCP 서버 사용을 중단해야 하나요?

아니요. MCP는 강력한 통합 레이어예요. 하지만 모든 MCP 서버를 신뢰 경계로 취급하세요. 연결된 서버를 감사하고, 버전을 고정하고, URL, 파일 경로, 셸 명령어를 받는 서버에 대해 입력 유효성 검사 훅을 추가하세요.

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

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