"버그가 아니라 스펙입니다": 세 곳의 벤더가 패치하지 않는 AI 코딩 에이전트의 제로 클릭 RCE

요약 (TL;DR) — 프롬프트 인젝션 (Prompt Injection)을 통해 프로젝트를 여는 순간, 어떠한 대화창이나 클릭 없이도 AI IDE의 mcp.json을 재작성하여 임의 코드 실행 (Arbitrary Code Execution)을 유도할 수 있습니다. 이는 동일한 유형의 12개 이상의 CVE 중 하나입니다. 근본 원인은 공식 MCP SDK에 있으며, Anthropic, Google, Microsoft는 파일 재작성이 "사용자의 명시적 권한을 필요로 한다"는 근거를 들어 자사 도구에 대한 CVE 발행을 거부했습니다. 실제로 그 권한은 대개 "IDE를 설치했다"는 사실로 갈음됩니다.

이전 포스트에서 저는 AI 코딩 에이전트의 실제 공격 표면 (Attack Surface)은 "모델이 폭주하는 것"이 아니라 "설정 파일 (Config File)"이라고 주장했습니다. 당시 최악의 사례(TrustFall)는 여전히 인간의 개입이 필요했습니다: 악성 저장소(Repo)를 클론하고, 열고, 신뢰 대화창에서 엔터(Enter)를 눌러야 했습니다.

CVE-2026-30615는 그 엔터(Enter) 키조차 필요 없게 만듭니다.

제로 클릭 체인 (The zero-click chain)

2026-04-15에 OX Security에 의해 공개되었습니다. Windsurf IDE 1.9544.26 버전에서 이 체인은 다음과 같습니다:

1. 공격자는 IDE가 렌더링할 HTML 콘텐츠를 준비합니다 — 악성 웹 페이지, 오염된 저장소의 README, 또는 변조된 도구 설명 등이 해당됩니다.
2. 주입된 명령어가 로컬 mcp.json을 조용히 덮어쓰고, 공격자가 제어하는 STDIO 서버를 등록합니다.
3. MCP SDK가 설정을 다시 읽고 등록된 바이너리 (Binary)를 실행합니다.
4. 임의 명령 실행 (Arbitrary Command Execution). CVSS 8 / High.

승인 대화창도 없고, 확인 단계도 없습니다. OX가 테스트한 IDE들 중 Windsurf만이 유일한 진정한 제로 클릭 (Zero-click) 이었습니다 — Cursor, Claude Code, Gemini CLI는 각각 최소 한 번의 사용자 동작을 요구했습니다.

Codeium (Windsurf)은 패치를 배포했습니다. 이 부분은 모두가 동의하는 지점입니다. 논쟁은 그 외의 다른 곳에서 시작됩니다.

이것은 버그가 아니라 하나의 클래스 (Class)입니다

동일한 공개 내용에서는 12개 이상의 CVE를 하나의 패턴 — MCP STDIO를 통한 RCE — 아래로 그룹화합니다:

• LangFlow (CVE 미할당)
• GPT Researcher (CVE-2025-65720)
• LiteLLM (CVE-2026-30623)
• Agent Zero (CVE-2026-30624)
• Windsurf (CVE-2026-30615)
• DocsGPT (CVE-2026-26015)
• Flowise, Upsonic, Bisheng, Jaaz 및 기타

공통된 근본 원인: 공식 MCP SDK가 사용자 제어 가능한 설정(config) 값을 검증(sanitization) 없이 StdioServerParameters로 전달하며, 이것이 하위 프로세스(subprocess)를 생성하는 과정으로 직결됩니다. OX는 이 근본 원인을 제가 취약점 보고서에서 이전에 본 적 없는 카테고리인 **"패치되지 않음 (Won't Be Patched)"**로 분류했습니다. Anthropic의 입장은 이것이 프로토콜 수준에서 수정해야 할 결함이 아니라, 스펙에 부합하는(spec-conformant) 동작이라는 것이기 때문입니다.

알려진 운영 측면의 완화 방법(mitigation)이 있습니다: STDIO command 값을 {npx, uvx, python, python3, node, docker, deno}와 같이 알려진 실행기(launcher)로 허용 목록(allowlist)에 등록하는 것입니다. 이렇게 하면 "원하는 임의의 바이너리를 가리키는" 경로를 차단할 수 있습니다. 하지만 이는 각 다운스트림 구현체(downstream implementation)가 스스로 추가해야 하는 사항입니다. SDK의 기본 설정은 아닙니다.

점점 줄어드는 검토 표면 (review surface)

세 가지 사건을 나열해 보면 그 추세를 놓치기 어렵습니다:

• 제1막 — TrustFall: 설정 파일이 처음부터 악의적입니다. 클론(clone)하고, 열고, 신뢰 대화 상자(trust dialog)에서 엔터를 누릅니다. 최소한 대화 상자라도 나타납니다.
• 제2막 — AWS Kiro: 간접 프롬프트 주입(indirect prompt injection)이 trustedCommands: ["*"]를 작성합니다. 설정은 사용자가 검토한 이후에 변경되므로, 그 순간을 놓치게 됩니다.
• 제3막 — Windsurf 제로 클릭: HTML을 열면 mcp.json이 조용히 재작성됩니다. 대화 상자가 전혀 나타나지 않습니다. 재작성이 발생했다는 사실조차 IDE에 드러나지 않습니다.

각 막은 인간이 무언가 잘못되었다는 것을 알아차릴 수 있는 표면을 더 많이 깎아냅니다. 제3막에 이르면, 이벤트 자체는 보이지 않게 됩니다.

그렇다면 이것은 누구의 문제인가?

이 부분에 대해서는 진심으로 여러분의 의견을 듣고 싶습니다.

Google, Microsoft, Anthropic은 이 부류에 속하는 자사 도구들에 대해 CVE를 발행하는 것을 거부했습니다. 명시된 이유는 표면적으로는 타당합니다: 이러한 파일을 수정하려면 사용자의 명시적인 권한(explicit permission)이 필요하기 때문입니다.

하지만 그 권한이 실제로 무엇인지 자세히 살펴보십시오. 인젝션(Injection)은 에이전트가 이미 쓰기 권한(write access)을 가지고 있는 워크스페이스 내부의 파일을 재작성합니다. 이 권한은 당신이 프로젝트를 열었을 때 일괄적으로(in bulk) 부여한 것입니다. 쓰기 작업마다 개별적인 프롬프트(prompt)는 나타나지 않습니다. 따라서 "사용자의 명시적 권한(explicit user permission)"은 "당신이 IDE를 실행했다"는 사실로 축소되어 버립니다. 만약 _취약점이 아님(not a vulnerability)_의 기준이 "사용자가 소프트웨어 사용에 한 번 동의했다"라면, 설정 파일(config file)과 관련된 거의 모든 것은 취약점이 될 수 없게 됩니다.

제가 벤더들이 악의적으로 행동하고 있다고 주장하는 것은 아닙니다. 프로토콜 수준(protocol-level)의 수정은 진정으로 어려우며, "스펙 준수(spec-conformant)\

그리고 이것이 일반적인 MCP와 동일한 태세(posture)를 노출하기 때문에, 단순히 _질문_할 수도 있습니다. 여기 Codex가 정확히 그렇게 수행하는 모습이 있습니다. 플릿(fleet) 내에서 가장 위험한 호스트를 추출하고 그 이유를 밝혀내는 과정입니다:

표시된 이유 중 하나에 주목하십시오: **신뢰할 수 없는 원격 MCP 서버 (untrusted remote MCP server)**입니다. 이는 CVE-2026-30615가 심어놓은 mcpServers 항목과 동일한 클래스입니다. 다만 여기서는 사후에 사람(또는 다른 에이전트)이 실제로 확인할 수 있는 태세(posture)로서 드러난다는 점이 다릅니다. (해당 CVE 자체는 STDIO 명령 기반입니다. Sigil의 STDIO 명령 점수 산정 방식은 #53에서 추적됩니다. 공격 표면(attack surface)인 mcpServers 키는 동일합니다.)

이 내용은 이 포스트의 핵심이 아니기에 의도적으로 마지막에 배치했습니다.

핵심 (The point)

제1막은

• CVE-2026-30615: Windsurf Zero-Click MCP Prompt Injection RCE — PolicyLayer
• MCP 공급망 권고: AI 생태계 전반의 RCE 취약점 — OX Security
• Anthropic MCP 설계 취약점으로 인한 RCE 발생, AI 공급망 위협 — The Hacker News
• 프롬프트가 셸이 될 때: AI 에이전트 프레임워크의 RCE 취약점 — Microsoft Security Blog
• 공격받는 에이전트형 IDE: 실제 CVE 분석 — Idan Habler