MCP STDIO 보안 위기, 20만 서버가 '도구 연결'이 아니라 셸 권한이었다

나는 새 프로토콜이 뜨면 기능표보다 먼저 권한이 어디까지 번지는지부터 본다. 콘텐츠 쪽에서 보면 MCP는 그동안 “툴 잘 붙는 표준”처럼 포장되기 쉬웠는데, 운영자 관점에서는 이야기가 전혀 다르다. 이번 MCP STDIO 보안 이슈는 그 착시를 한 번에 깨버렸다. OX Security와 CSA가 정리한 내용을 따라가 보면, 문제의 핵심은 “도구 연결이 편하다”가 아니라 설정 파일 하나가 사실상 셸 실행 권한을 쥐고 있었다는 데 있다.

요약하면 이렇다. 2026년 4월 공개된 분석은 Anthropic MCP의 STDIO transport가 사용자나 외부 입력의 영향을 받은 명령 문자열을 운영체제 셸까지 밀어 넣을 수 있고, 이게 개별 앱의 실수라기보다 여러 공식 SDK와 생태계 전반에 걸친 설계 문제라고 지적했다. OX는 1억 5천만 회 이상 다운로드된 의존성 축, 7천 개 넘는 공개 노출 서버, 많게는 20만 개 수준의 취약 배포 가능성을 언급했고, CSA도 이 사건을 프롬프트 인젝션이 아니라 인프라 레이어의 원격 코드 실행 면으로 봐야 한다고 정리했다. 이쯤 되면 “MCP 썼다”는 말은 더 이상 단순한 생산성 자랑이 아니다.

MCP STDIO가 도구 연결에서 셸 권한으로 바뀌는 구조

이번 사건의 본질은 버그보다 설계였다

이번 이슈가 유난히 무서운 이유는 CVE 하나를 때우면 끝나는 종류가 아니기 때문이다. 보통 개발팀은 보안 사고를 보면 “어느 제품 버전이 취약한가”부터 찾는다. 그런데 이번엔 반대로 봐야 한다. 어떤 제품이 MCP STDIO를 어떻게 감쌌든, 그 밑바닥에 있는 실행 모델 자체가 위험해질 수 있다는 게 출발점이다.

CSA 설명을 풀어 쓰면 구조는 꽤 단순하다. MCP에는 HTTP+SSE처럼 네트워크 서버에 붙는 방식도 있지만, STDIO는 로컬 프로세스를 띄우고 표준입출력으로 통신하는 모델이다. 이 방식 자체는 빠르고 편하다. 문제는 여기서 “어떤 명령으로 그 프로세스를 띄울지”가 사실상 신뢰 경계라는 점이다. 설정 파일이나 레지스트리, IDE 프로젝트 구성, 웹 UI 입력이 그 명령에 영향을 줄 수 있다면, 공격자는 모델을 속이지 않고도 운영체제 실행면으로 내려갈 수 있다.

아래 같은 구조가 왜 위험한지 생각해 보면 감이 빨리 온다.

{
  "mcpServers": {
    "demo": {
      "command": "npx",
      "args": ["some-mcp-server"]
    }
  }
}

겉으로 보면 그냥 서버 하나 연결한 설정처럼 보인다. 하지만 실제 운영에서는 command, args, 설치 경로, fallback 동작, 레지스트리 출처, 프로젝트에 포함된 설정 파일까지 전부 권한면이 된다. 이번 사건이 던진 메시지는 간단하다. MCP 설정은 환경설정이 아니라 실행 정책이라는 것.

왜 ‘20만 서버’라는 숫자가 과장처럼 들리면 더 위험하다

보안 뉴스에서 큰 숫자는 금방 무뎌진다. 20만 인스턴스, 7천 개 공개 노출, 1억 5천만 다운로드 같은 수치는 자칫 마케팅성 공포 조장처럼 들릴 수도 있다. 그런데 나는 오히려 그 반응이 더 위험하다고 본다. 이런 수치는 “정확히 몇 대냐”보다 얼마나 많은 팀이 이걸 안전한 연결 레이어로 오해했는가를 보여주기 때문이다.

이번에 취약성이 거론된 영역은 한 제품에 갇혀 있지 않았다. OX와 후속 보도 기준으로 LiteLLM, LangFlow, Flowise, LibreChat, Windsurf, Cursor 같은 이름이 계속 등장한다. 어떤 곳은 웹 UI에서 MCP 구성을 받아들이는 방식이 문제였고, 어떤 곳은 인증된 사용자라도 낮은 권한으로 설정을 바꿀 수 있으면 위험했다. 또 어떤 IDE는 저장소를 열거나 설정을 불러오는 순간 로컬 실행까지 이어지는 패턴이 논란이 됐다.

즉 이 숫자가 말하는 건 “인터넷에 떠 있는 20만 대가 오늘 밤 다 뚫린다”가 아니다. 더 본질적으로는 MCP 생태계 전체가 ‘도구 연결’이라는 UX 언어 뒤에 실제 실행 권한을 숨겨 왔다는 뜻에 가깝다. 개발자가 느끼는 문장은 “Connect tool”인데, 운영체제가 실제로 받는 문장은 “Run this command”였던 셈이다.

여러 AI 제품에서 반복된 MCP STDIO 공격면

제품별 패치만 믿으면 다시 같은 구멍이 열린다

이 지점에서 가장 많이 나오는 반응은 “그럼 최신 버전으로 올리면 되는 거 아냐?”다. 물론 패치는 해야 한다. 안 하면 더 위험하다. 하지만 패치만으로 안심하는 건 이번 사건을 절반만 이해한 대응이다.

왜냐하면 이번 문제는 개별 제품의 입력 검증 실패를 넘어, 새 MCP 서버를 추가하는 순간 같은 클래스의 위험이 재도입될 수 있는 구조이기 때문이다. 레지스트리에서 받아온 서버, 저장소에 포함된 예제 설정, 자동 등록 기능, IDE 확장, 사내 래퍼 스크립트가 서로 다른 모양으로 같은 위험을 가져온다. Anthropic 측이 이 동작을 설계상 기대된 행동이라고 본다는 보도까지 겹치면서, 더더욱 다운스트림 팀이 알아서 방어해야 하는 그림이 됐다.

이 말은 꽤 냉정하다. 이제 보안팀이나 개발팀은 “우리는 MCP를 쓴다”고 말하는 순간 아래 질문을 같이 받아야 한다.

어떤 transport를 허용하는가
STDIO 서버는 누가 등록할 수 있는가
command와 args는 어디서 오며 누가 검토하는가
프로젝트 안 설정 파일을 열었을 때 자동 실행되는가
레지스트리/마켓플레이스 출처를 어떻게 신뢰하는가
실행 프로세스는 샌드박스, 컨테이너, 권한 축소로 감싸져 있는가

이 질문에 답이 없으면, 패치 이후에도 “다음 번 설정 파일”이 곧 다음 사고가 된다.

관련해서 지난번에 정리한 A2A와 MCP의 역할 분리도 다시 볼 만하다. 그 글에선 MCP를 연결 표준으로 봤다면, 이번 사건은 거기에 반드시 권한 경계와 실행 정책이라는 렌즈를 덧대야 한다는 후속편에 가깝다.

실무 대응은 MCP를 ‘편한 커넥터’가 아니라 ‘셸 권한 면’으로 재분류하는 것

내가 보기엔 대응 원칙은 생각보다 선명하다. MCP를 금지하자는 얘기가 아니라, 분류 체계를 바꾸자는 얘기다. 지금까지 많은 팀이 MCP를 플러그인이나 커넥터 취급했다. 하지만 STDIO 기반 연결이 섞이는 순간 그건 플러그인이 아니라 실행기다.

실무에선 최소한 여기까지는 기본값으로 가져가야 한다.

1. STDIO auto-registration부터 끈다

프로젝트를 열거나 외부 설정을 읽는 순간 자동으로 MCP 서버가 등록되거나 실행되는 흐름은 가장 먼저 의심해야 한다. 편하지만, 공격자가 가장 좋아하는 진입점이기도 하다.

2. MCP 설정 파일을 코드리뷰 대상에 넣는다

mcp.json, IDE 설정, 워크스페이스 파일, 래퍼 스크립트를 더 이상 “개발 편의 설정”으로 분리하면 안 된다. 인프라 코드처럼 리뷰하고, 변경 이력과 승인자를 남겨야 한다.

3. 허용목록만으로 끝내지 말고 실행 환경을 격리한다

공식 레지스트리만 쓰는 걸로는 부족하다. 신뢰된 서버라도 취약할 수 있다. 가능하면 별도 사용자, 컨테이너, 샌드박스, 읽기 전용 파일시스템, 네트워크 제한을 같이 써야 한다.

4. 개발자 워크스테이션도 서버처럼 본다

이번 이슈가 무서운 건 운영 서버뿐 아니라 IDE와 로컬 머신까지 타격 범위에 들어간다는 점이다. AI 코딩 도구가 설치된 노트북은 이제 그냥 편집기가 아니라 민감한 실행 호스트다.

5. 마켓플레이스와 예제 저장소를 공급망으로 취급한다

“예제니까 괜찮겠지”, “스타가 많으니까 괜찮겠지”가 제일 비싼 착각이다. MCP 서버 배포처, npm/PyPI 패키지, 깃허브 템플릿을 모두 공급망 검토 대상으로 올려야 한다.

간단 체크리스트로 줄이면 이렇게 된다.

- 사용 중인 MCP 호스트/클라이언트 목록화
- STDIO transport 사용 여부 확인
- 자동 등록/자동 실행 기능 비활성화
- MCP 설정 파일 코드리뷰 의무화
- 실행 프로세스 샌드박스/권한 축소 적용
- 레지스트리/패키지 출처 검증 및 내부 허용목록 운영
- 개발자 로컬 환경까지 감사 범위에 포함

MCP 보안 하드닝 체크리스트

한국 개발자에게 지금 중요한 건 ‘MCP 도입 여부’보다 ‘MCP 운영 방식’이다

한국 개발자 커뮤니티에서 MCP는 이미 꽤 빠르게 표준 단어가 됐다. Claude Code, Cursor, Windsurf, 각종 오픈소스 에이전트 프레임워크를 조금만 써봐도 MCP 얘기가 바로 나온다. 그래서 이번 사건이 더 중요하다. 지금부터는 “우리도 MCP 붙였다”가 자랑이 아니라, 어떤 transport를 썼고 어떤 권한 모델로 감쌌는지가 실력 차이가 된다.

특히 작은 팀이나 1인 개발자는 더 조심해야 한다. 보안 담당자가 따로 없으니 편한 기본값을 그대로 받아들이기 쉽다. 그런데 AI 도구는 원래 편할수록 위험을 감춘다. 설치가 쉬운 도구, 자동 감지되는 서버, 원클릭 마켓플레이스, 저장소 열자마자 살아나는 설정은 전부 UX적으로는 아름답지만 보안적으로는 질문거리가 많다.

이번 사건을 계기로 기준을 바꾸면 좋겠다. 앞으로 MCP를 검토할 때는 “이거 연결 잘 되나?”보다 먼저 **“이거 결국 누구 권한으로 어떤 명령을 실행하나?”**를 물어야 한다. 그 질문 하나만 앞세워도, 도입 속도는 조금 느려질지 몰라도 사고 비용은 훨씬 크게 줄어든다.

김덕환 운영자가 봤을 때

log8.kr 같은 개인 미디어이자 실험실을 운영하는 입장에선 이 이슈가 더 현실적이다. 새로운 AI 도구를 빨리 붙여서 생산성을 올리고 싶은 마음이 늘 앞서는데, 이번 사건은 그 욕심 앞에 아주 선명한 브레이크를 걸어준다. 연결이 늘수록 작업은 빨라지지만, 그 연결이 곧 셸 권한이면 이야기가 달라진다. 김덕환 운영자가 봤을 때 중요한 건 “MCP를 쓰느냐”가 아니라 MCP를 어디까지 믿지 않을 수 있느냐다. 그 감각이 앞으로 AI 운영 역량의 핵심이 될 가능성이 크다.

KPI impact: published = 0