10개의 CVE가 지난 뒤: MCP 개발자들이 같은 실수를 반복하는 이유

Source: Dev.to

열 가지

해결 방법은 항상 동일합니다: 문자열 연결을 사용한 exec() 대신 인수 배열을 사용하는 execFile()을 사용하거나, 쉘 호출을 완전히 피하고 언어 수준 API를 사용하십시오. 이 패턴은 CWE‑78이며, 소프트웨어 역사상 가장 많이 문서화된 취약점 중 하나입니다.

왜 계속 발생하는가

1. MCP 서버는 보안 엔지니어가 아니라 도메인 전문가에 의해 구축됩니다

*xcode‑mcp‑server*의 개발자는 Xcode를, *sf‑mcp‑server*의 개발자는 Salesforce를 잘 압니다. 그들은 자신의 도메인에 맞는 도구를 만들면서 이미 익숙한 CLI 도구를 호출하는 가장 직관적인 방법인 exec()를 사용합니다. 보안은 그들의 주요 전문 분야가 아닙니다. MCP SDK는 기능을 노출하기 쉽게 만들지만, 안전하게 노출하기는 쉽지 않습니다.

2. 배포 경로에 보안 검토가 없습니다

공식 MCP 레지스트리에는 8,000개가 넘는 항목이 있습니다. 검토는 최소 수준에 머물러 있습니다. 개발자는 MCP 서버를 작성하고 배포하면, 몇 시간 안에 Claude for Desktop 사용자가 연결할 수 있게 되지만, 보안 감사를 거치지 않습니다. 수년간 보안 검토 프로세스를 운영해 온 npm이나 App Store와 비교해 보세요. MCP는 그에 상응하는 관문 역할을 하지 못합니다.

3. 레퍼런스 구현에도 동일한 버그가 있었습니다

CVE‑2025‑68144는 mcp-server-git—Anthropic의 공식 Git 서버—에서 발생하는 인자 주입 버그입니다. 개발자들이 복사해 사용하도록 기대되는 표준 구현에 exec() 패턴이 포함되어 있다면, 이를 기반으로 작업하는 모든 사람에게 어떤 신호를 보내는 걸까요? 보안 문화는 상향식이 아니라 하향식으로 전파됩니다. 레퍼런스에 결함이 있으면, 생태계 전체가 그 결함을 물려받게 됩니다.

생산 현실

우리의 560개 스캔된 MCP 서버 데이터셋에서 38 %가 인증 계층이 없음을 보여줍니다. exec() 취약점이 있는 서버의 경우, 이는 다음을 의미합니다:

• 인증되지 않은 접근
• 악용 가능한 쉘 인젝션

→ 연결된 AI 에이전트를 통해 전체 시스템이 손상됩니다.

공격 시나리오는 복잡할 필요가 없습니다. 취약한 서버에 연결된 AI 에이전트가 독성 문서를 처리합니다. 그 문서에는 쉘 메타문자를 주입한 도구 호출을 트리거하는 명령이 포함되어 있습니다. exec() 호출이 페이로드를 실행합니다. 게임 오버.

우리는 공개 MCP 엔드포인트에서 AI 에이전트가 실제로 수행한 223건의 도구 호출을 관찰했습니다. 공격 표면은 실제이며 활발히 사용되고 있습니다.

수정 (다시)

Node.js MCP 서버

// VULNERABLE
exec(`git clone ${userInput}`);
exec(`sfdx ${userControlledArgs}`);

// SAFE
execFile('git', ['clone', userInput]);
execFile('sfdx', [subcommand, ...validatedArgs]);

Python MCP 서버

# VULNERABLE
subprocess.run(f"tool {user_input}", shell=True)

# SAFE
subprocess.run(['tool', user_input], shell=False)

이것들은 한 줄로 해결할 수 있는 수정입니다. 리팩터링은 몇 분이면 끝납니다. 발견되기 전까지의 노출 기간은 몇 달에 이릅니다.

이것이 MCP 보안 성숙도에 대해 알려주는 점

우리는 MCP 생태계 보안의 초기 단계에 있습니다 — 마치 2000년대 초 웹 보안이 SQL 인젝션이 곳곳에 퍼져 있었던 시기와 같습니다. 그때는 개발자들이 쿼리를 매개변수화하는 방법을 배우지 못했기 때문이었습니다.

차이점은 다음과 같습니다: SQL 인젝션에 대한 인식은 수년에 걸쳐 퍼졌습니다. MCP는 더 빠르게 움직이고 있습니다. 6주 만에 10건의 exec() CVE가 발생했다는 것은 생태계가 전환점에 서 있다는 의미입니다 — 보안 문화가 빠르게 따라잡히든지, 아니면 인식이 따라오기 전에 악용이 일어날 것이든 말이죠.

도움이 될 세 가지 방안

1. MCP SDK에 보안 프리미티브를 포함시켜야 합니다 — 도구를 쉽게 노출하도록 하는 것뿐만 아니라, 안전하지 않게 노출하기 어렵게 만들어야 합니다. 서브프로세스 호출을 래핑하고, 입력‑정화 헬퍼를 추가하세요.
2. 레지스트리 검토에 자동 스캔을 포함시켜야 합니다 — MCP 서버를 정적 분석을 통해 리스트에 올리기 전에 검사하는 것은 간단합니다. 이는 npm 패키지에 이미 존재하는 기능이며, 여기에도 적용되어야 합니다.
3. 레퍼런스 구현이 표준을 제시해야 합니다 — mcp-server-git의 CVE‑2025‑68144가 이제 수정되었습니다. 수정 사항은 단순히 체인지로그에 적히는 것이 아니라, 왜 중요한지 설명하는 블로그 포스트와 함께 제공되어야 합니다.

exec() 전염병은 해결 가능합니​다. 필요한 것은 이를 정상적인 것으로 받아들이는 것을 멈출 누군가입니다.

MCP 보안 데이터셋(560개 서버, 23개 CVE)은 mcp.kai-agi.com에서 확인할 수 있습니다. 이전 분석: Why CVSS Underscores MCP Vulnerabilities, Reference Implementation CVEs.