MCP 보안: 20만 개의 취약한 인스턴스가 거버넌스된 모듈을 구매 기준으로 만드는 이유

공개

2026년 4월과 5월, OX Security는 명령어 주입과 원격 코드 실행을 가능하게 하는 모델 컨텍스트 프로토콜(MCP) STDIO 구성의 시스템적 아키텍처 결함을 공개했습니다. 이 권고는 MCP 공급망 전반의 10개 CVE — 약 20만 개의 취약한 인스턴스, 1억 5천만 다운로드에 영향 — 를 다룹니다. 취약점은 단일 패키지에 있지 않습니다. 대부분의 커뮤니티 MCP 서버가 함께 출시되는 기본 구성 패턴에 있습니다.

Cloud Security Alliance는 자사 연구 노트에 "MCP 보안 위기: AI 에이전트 인프라의 시스템적 설계 결함"이라는 제목을 붙였습니다. OWASP는 MCP Top 10 프로젝트를 출범하여 MCP 지원 시스템 수명 주기 전반에서 가장 중요한 보안 우려사항을 목록화했습니다. Aembit는 전송 위험과 공급망 위협을 다루는 가이드를 발행했습니다. TrueFoundry는 MCP 보안 위험과 모범 사례에 대한 엔터프라이즈 가이드를 발행했습니다.

이들 모두에 공통된 패턴: 취약점 표면은 커뮤니티 MCP 서버가 프로덕션 시스템이 요구하는 거버넌스 레이어 없이 구축되고 배포되기 때문에 존재합니다.

취약점이 실제로 무엇인가

MCP 서버는 전송을 통해 AI 에이전트 클라이언트와 통신합니다. STDIO 전송 — 로컬 개발과 많은 프로덕션 배포의 기본값 — 은 표준 입력과 출력을 통해 메시지를 전달합니다. OX Security 공개는 일반적인 STDIO 구성 패턴이 명령어 주입을 허용함을 식별했습니다: 조작된 입력이 MCP 서버를 실행하는 호스트에서 임의의 명령어를 실행할 수 있습니다.

이것은 이론적인 공격 경로가 아닙니다. MCP 서버는 에이전트 클라이언트와 동일한 머신에서 동일한 프로세스 권한으로 실행됩니다. STDIO를 통해 받은 입력을 기반으로 셸 명령어를 받아 실행하는 서버는 구조적으로 원격 코드 실행 표면입니다. 20만 인스턴스 추정치는 커뮤니티 MCP 채택의 규모를 반영합니다 — 레지스트리에 게시되고, 저장소에서 복제되고, 프로덕션용으로 결코 강화되지 않은 기본 구성으로 배포된 서버들입니다.

Backslash Security는 별도로 MCP 2026-07-28 릴리스 후보 자체가 도입한 세 가지 새로운 공격 표면 — 20일 후에 확정되는 바로 그 스펙 — 을 식별했습니다. 새로운 역량(서버 렌더링 UI, 장기 실행 작업, 헤더 기반 라우팅)은 보안 커뮤니티가 여전히 매핑 중인 새로운 진입점을 만듭니다.

2026년 침해 타임라인

OX Security의 공개는 고립된 사건이 아니었습니다. 그것은 2026년 상반기 내내 확대된 침해 타임라인 안에 자리하며, 명명된 취약점이야말로 "거버넌스는 좋은 관행"을 "거버넌스는 구매 기준"으로 바꾸는 것입니다.

2026년에 네 개의 새로운 CVE가 나타났습니다: CVE-2026-33032("MCPwn", CVSS 9.8, 2,600개가 넘는 노출 인스턴스), CVE-2026-0755(Gemini MCP 도구, CVSS 9.8), CVE-2026-35394(Mobile MCP RCE, 2026년 4월, Android intent injection, CWE-939), 그리고 2026년 2월 가짜 Oura MCP 트로이목마가 StealC 멀웨어를 배포했습니다. Practical DevSecOps는 공개 MCP 서버의 30~82%가 악용 가능한 결함을 지니고 있으며, 인증에 OAuth를 사용하는 곳은 8.5%에 불과하다는 것을 발견했습니다.

더 큰 그림은 더 어둡습니다: 지난 1년간 47~53%의 조직이 에이전트 관련 보안 인시던트를 보고했으며, AI 에이전트 중 단 14.4%만이 전체 보안 승인을 받고 프로덕션에 도달합니다. 도입과 거버넌스 사이의 간극이 바로 MCP 보안 위기가 존재하는 곳입니다.

클라이언트 측 OAuth RCE — 새로운 공격 클래스

위의 CVE들은 서버 측 취약점입니다 — MCP 서버가 표적입니다. 2025년 9월, Obsidian Security는 클라이언트 호스트를 표적으로 하는 완전히 다른 공격 클래스를 공개했습니다. MCP Authorization 스펙의 OAuth 디스커버리 흐름은 백도어를 엽니다: URL 살균 없이 OAuth를 위해 브라우저를 생성하는 데스크톱 및 CLI MCP 클라이언트는 OS 명령어 주입과 원격 코드 실행에 취약합니다. 악의적인 원격 MCP 서버가 클라이언트 머신을 손상시킬 수 있습니다.

4개의 CVE가 할당되었으며, 그중 CVE-2025-54074는 Cherry Studio에 영향을 미칩니다. 영향을 받는 클라이언트는 생태계 전반에 걸쳐 있습니다: Cherry Studio, Gemini-CLI, MCP Inspector, VS Code, Windsurf, Smithery.ai, Lutra.ai, Glue.ai. 이 공격은 취약한 서버를 요구하지 않습니다 — 공격자가 통제하는 모든 서버에 취약한 클라이언트가 연결되기를 요구합니다.

이 클래스는 완화가 다른 레이어에 존재한다는 점에서 서버 측 공급망 공격과 구별됩니다. 서버 측 강화(감사 로그, 속도 제한, 타입화된 오류, 킬 스위치)는 클라이언트 호스트를 보호하지 않습니다. 클라이언트는 브라우저를 생성하기 전에 OAuth 리디렉션 URL을 살균하고 디스커버리 문서를 검증해야 합니다. 브라우저를 생성하는 프레임워크가 열 URL을 제한해야 합니다.

BlueRock Security는 스캔한 7,000개 이상의 MCP 서버 중 36.7%가 Server-Side Request Forgery(SSRF)에 취약하다는 것을 발견했습니다 — 손상된 MCP 서버가 실행되는 호스트에서 임의의 아웃바운드 요청을 하게 하는 공격입니다. Obsidian의 클라이언트 측 발견과 결합하면, 공격 표면은 이제 연결의 양 끝에 걸쳐 있습니다: 서버가 클라이언트를 공격할 수 있고(OAuth RCE), 서버가 실행되는 네트워크를 공격할 수 있습니다(SSRF).

두 개의 추가 CVE가 타임라인을 새로운 공격 클래스로 확장합니다:

• CVE-2026-39313 — mcp-framework HTTP Server 서비스 거부. HTTP 전송 레이어에 대한 조작된 요청을 통한 메모리 고갈. 이것은 RCE가 아닌 MCP HTTP 전송에 대한 최초로 문서화된 DoS 공격입니다 — 새로운 취약점 범주입니다.
• CVE-2026-33224 — Bisheng MCP 도구 구성 내 인증된 원격 명령어 실행. 이것은 STDIO 공급망 권고를 새로운 영향받는 제품으로 확장하여, 구성 레이어 공격 표면이 원래의 OX Security 공개에 국한되지 않음을 확인합니다.
• CVE-2026-27826 — MCP Atlassian SSRF (CVSS 8.2, sooperset:mcp-atlassian 버전 < 0.17.0). 이 취약점은 인증되지 않은 상태이며 MCP 도구 핸들러가 아닌 HTTP 미들웨어 및 의존성 주입 레이어에 존재한다는 점에서 특징적입니다. 도구 핸들러에만 집중하는 보안 검토는 HTTP 전송 레이어 전체를 간과합니다. 클라우드 배포에서 SSRF는 인스턴스 메타데이터 엔드포인트(169.254.169.254)를 통해 IAM 역할 자격 증명 도난을 가능하게 합니다. 미들웨어-비-도구-핸들러 위치는 도구 수준 코드 분석으로는 감지할 수 없는 별도의 공격 표면입니다.

Reddit의 r/AI_Agents 커뮤니티는 보고하기를 60일(2026년 1월~3월) 동안 MCP 서버에 대해 30개의 CVE가 접수되었으며, 12,000개 이상의 인스턴스가 노출되었다고 했습니다. Practical DevSecOps는 그 30개 CVE 중 13개(약 43%)가 명령어 실행 취약점임을 확인했습니다. 속도는 안정화되는 것이 아니라 가속화되고 있습니다.

거버넌스 레이어 — 감사 로그, 속도 제한, 타입화된 오류, 킬 스위치 아키텍처, PII 경계 — 는 서버 측 공격 표면을 다룹니다. 클라이언트 측 OAuth RCE 클래스는 클라이언트 수준의 URL 살균을 요구하며, 이는 MCP 스펙과 클라이언트 프레임워크가 여전히 강제하도록 업데이트 중인 별도의 완화입니다. 두 레이어 모두 필요합니다.

왜 커뮤니티 서버가 노출인가

대부분의 커뮤니티 MCP 서버는 역량을 시연하기 위해 구축됩니다 — 에이전트를 도구에 연결하고, 결과를 반환합니다. 이들은 운영되도록 구축되지 않았습니다. 프로덕션 시스템이 요구하는 거버넌스 통제가 기본적으로 부재합니다:

• 감사 로깅 없음. 도구 호출이 요청, 응답, 지연, 결과와 함께 로깅되지 않습니다. 인시던트가 발생하면 재구성할 추적이 없습니다.
• 속도 제한 없음. 도구가 제한 없이 호출될 수 있습니다. 손상되거나 오작동하는 에이전트가 업스트림 API 할당량을 소진하거나 대규모로 의도치 않은 부작용을 유발할 수 있습니다.
• 타입화된 오류 계약 없음. 오류가 문자열이나 비구조화된 응답으로 반환됩니다. 에이전트는 일시적 실패와 영구적 실패를 구분할 수 없고, 운영자는 인시던트를 프로그래밍 방식으로 분류할 수 없습니다.
• 킬 스위치 없음. 운영자 런북도, 폴백 경로도, 오케스트레이션 백본을 건드리지 않고 모듈을 비활성화할 방법도 없습니다.
• 테스트 커버리지 없음. 오류 경로가 테스트되지 않았습니다. 개발 중에 결코 실행되지 않은 실패 모드가 바로 프로덕션에서 발생하는 것입니다.

이것들은 이색적인 보안 요구사항이 아닙니다. 어떤 프로덕션 API든 강제하는 것과 동일한 통제입니다. 문제는 MCP 서버가 프로덕션 통합이 아니라 개발 유틸리티인 것처럼 배포되고 있다는 점입니다.

거버넌스된 모듈은 어떤 모습인가

우리가 발행하는 MCP 모듈 코드 표준은 이러한 각 격차를 해결하는 거버넌스 레이어를 정의합니다. 이 표준은 보안 프레임워크가 아닙니다 — 보안을 강제 가능하게 만드는 코드 표준입니다. 통제는 구체적입니다:

감사 로깅. 모든 도구 호출은 타임스탬프, 에이전트 ID, 도구 이름, 입력 해시(원시 입력이 아닌 — PII 경계), 출력 상태, 지속 시간, 업스트림 시스템을 로깅합니다. 로그는 관측 가능성 파이프라인으로 전송되는 구조화된 JSON입니다. 인시던트가 발생하면 감사 추적이 요청 인수와 핸들에서 전체 워크플로 상태를 재구성합니다 — 세션 저장소 로그와의 상관관계 분석이 필요 없습니다.

속도 제한. 각 도구는 등록 호출에서 자체 속도 제한을 선언합니다. 백본은 에이전트별, 도구별, 윈도우별로 제한을 강제합니다. 제한에 도달하면 에이전트는 Retry-After 헤더가 있는 429 응답을 받습니다 — 충돌하거나 맹목적으로 재시도하지 않습니다. 속도 제한이 업스트림 API가 아닌 모듈 경계에서 강제되기 때문에 손상된 에이전트는 업스트림 할당량을 소진할 수 없습니다.

타입화된 오류 계약. 모듈은 날 문자열이 아닌 타입화된 예외 — MCPAuthError, MCPRateLimitError, MCPTimeoutError, MCPValidationError, MCPUpstreamError — 를 발생시킵니다. 백본은 이를 잡아 에이전트가 추론할 수 있는 구조화된 응답으로 변환합니다. 모든 오류가 코드를 지니기 때문에 운영자는 인시던트를 프로그래밍 방식으로 분류할 수 있습니다.

PII 경계 처리. 모듈은 어떤 입력 필드에 PII가 포함되는지 선언합니다. 백본은 로깅 전에 이 필드들을 해시(SHA-256)하고, 원시 PII를 감사 파이프라인에 보내지 않습니다. 도구 핸들러는 여전히 원시 값을 받습니다 — PII 처리는 비즈니스 로직 내부가 아니라 로깅 경계에서 강제됩니다.

테스트 커버리지. 모든 도구는 요청/응답 테스트와 오류 경로 커버리지를 가집니다. 통합 테스트는 샌드박스 환경에 대해 실행됩니다. 모의 테스트는 도구 등록, 인수 매핑, 응답 정규화, 오류 전파, 상태 전환을 검증합니다. 개발 중에 결코 실행되지 않은 실패 모드는 출시되지 않습니다.

38개 도구 증명 사례

이 통제들은 이상적인 목표가 아닙니다. 이들은 mcp_hospirfq_processor의 구조입니다 — 완전한 RFQ 수명 주기에 걸쳐 38개 도구를 등록하는 모듈: 요청 생성, 카탈로그 검색, 견적 생성, 가격 계층, 가용성 확보, 취소 정책, 번들 발견, 주문 인계.

모듈의 오류 핸들러는 모든 실패 모드에 대해 타입화된 오류 코드 — GRAPHQL_QUERY_FAILED, VALIDATION_FAILED, HOLD_NOT_FOUND, HOLD_ALREADY_EXPIRED, AVAILABILITY_INSUFFICIENT, PRICING_MODE_UNSUPPORTED — 를 정의합니다. 각 오류는 코드와 구조화된 세부사항을 지닙니다. handle_errors 데코레이터가 모든 도구 메서드를 래핑하므로 어떤 도구도 비구조화된 예외를 반환하지 않습니다. 상태 관리자는 유효한 상태 전환을 강제합니다 — 확보는 확인, 해제, 또는 만료될 수 있지만, 초기에서 완료로 건너뛸 수 없습니다.

이것이 실제로 거버넌스된 모듈의 모습입니다: 모든 도구에 스키마가 있고, 모든 오류에 코드가 있고, 모든 호출에 로그가 있고, 모든 상태 전환에 검증기가 있습니다. 거버넌스는 누군가 읽을 수도 있는 문서가 아니라 코드 안에 있습니다.

킬 스위치 아키텍처

거버넌스 레이어는 모듈을 넘어 오케스트레이션 백본까지 확장됩니다. 엔지니어링 브리프는 운영 자세를 명시합니다:

• 운영자 런북. 배포, 롤백, 인시던트 응답, 일반적 작업이 문서화됩니다. 모듈이 오작동하면 운영자는 Slack 스레드가 아니라 런북을 따릅니다.
• 폴백 경로. 백엔드를 사용할 수 없을 때 우아한 저하. 업스트림에 도달할 수 없는 모듈은 구조화된 오류를 반환하고, 에이전트는 폴백 도구로 라우팅하거나 사람에게 에스컬레이션합니다.
• 피처 플래그 롤아웃. 모듈은 환경별로 활성화됩니다. 모듈은 오케스트레이션 백본을 건드리지 않고 비활성화될 수 있습니다 — 킬 스위치는 코드 배포가 아니라 구성 변경입니다.
• 관측 가능성. 구조화된 로그, 메트릭, 트레이스가 모니터링 스택으로 전송됩니다. 에이전트의 동작은 엔드투엔드로 감사 가능합니다 — 기업이 재무 통제에 적용하는 것과 같은 자세입니다.

킬 스위치 아키텍처는 OX Security 공개가 20만 개의 커뮤니티 서버에서 누락된 것으로 드러낸 통제입니다. 취약점이 공개되면 운영자의 첫 질문은: 에이전트를 다운시키지 않고 이 모듈을 비활성화할 수 있는가? 거버넌스된 배포에서는 답이 예입니다. 커뮤니티 서버 배포에서는 답이 보통 아니오입니다 — 서버가 에이전트의 도구 목록에 연결되어 있어, 제거하려면 코드를 편집하고 재배포해야 합니다.

왜 지금 이것이 구매 기준인가

PwC 2026 글로벌 CEO 설문조사(CEO 4,454명)는 조직의 56%가 AI로부터 측정 가능한 재무적 이익을 보고하지 못한다는 사실을 발견했습니다. WRITER 엔터프라이즈 AI 채택 설문조사는 기업의 35%가 AI 에이전트가 배포되면 플러그를 뽑을 수 없음을 발견했습니다. 이 조합이 구매 기준입니다: 비활성화할 수 없는 시스템은 부채이고, 측정 가능한 이익을 내지 못하는 시스템은 비용입니다. 거버넌스 — 감사 로그, 속도 제한, 타입화된 오류, 킬 스위치 아키텍처 — 는 AI 에이전트를 안전하게 배포하고 안전하게 폐기할 수 있게 만드는 통제입니다.

Gartner는 2026년 말까지 불충분한 AI 위험 가드레일로 인한 "AI에 의한 죽음" 법적 청구가 2,000건을 초과할 것으로 예측합니다. EU AI법은 2026년 8월 2일 — 오늘로부터 25일 후 — 완전히 적용됩니다. 제50조 투명성 규칙은 AI 생성 콘텐츠 공개를 요구합니다. 위험 분류, 문서화, 기록 보관이 고위험 시스템에 의무화됩니다. 거버넌스된 모듈이 이미 함께 출시하는 감사 로그와 운영자 런북은 EU AI법이 요구할 규정 준수 증거입니다.

MCP 2026-07-28 스펙은 20일 후에 확정됩니다. 출시되면 "Model Context Protocol"에 대한 검색과 인용 볼륨이 급증할 것이며 — 보안 표면에 대한 정밀 조사도 마찬가지입니다. 거버넌스 기준을 충족하지 못하는 커뮤니티 서버가 표시될 것들입니다.

결정

팀이 MCP 기반 에이전트 배포를 평가할 때, 질문은 더 이상 "연결되는가?"가 아닙니다. 커뮤니티 서버는 연결됩니다. 질문은: 무언가 잘못되면 그것을 볼 수 있고, 멈출 수 있고, 무슨 일이 있었는지 증명할 수 있는가?

거버넌스된 모듈은 세 가지 모두에 예라고 답합니다. 커뮤니티 서버는 기본적으로 세 가지 모두에 아니오라고 답합니다. 20만 개의 취약한 인스턴스가 그 증거입니다.

---

NetSuite, BigCommerce, 세 개의 공급업체 카탈로그를 운영하는 유통업체는 이메일 또는 포털로 RFQ를 수신하고, 카탈로그 그래프에 대해 제품과 대체품을 해결하고, 고객 계층별로 가격을 책정하고, 만료와 함께 재고를 확보하고, 승인된 견적을 NetSuite에 다시 기록하는 에이전트를 얻습니다 — 모든 단계가 로깅되고, 모든 도구가 속도 제한되며, 모든 모듈이 구성으로 비활성화 가능합니다. 그 빌드는 4단계 메서드의 23단계이며 일반적으로 58주 내에 라이브됩니다.

범위 정의 빌드를 요청하세요. 1주 발견. 시스템 인벤토리, 워크플로 맵, 고정 범위를 받습니다 — 우리와 빌드할지 여부와 관계없이.