이 블로그는 MCP 서버를 직접 만들며 배운 걸 기록한다. 그런데 그 MCP가 2026년 들어 보안 이슈의 한복판에 서 있다. 개별 제품의 버그가 아니라 프로토콜과 공식 SDK의 설계 자체가 문제로 지목된 사례가 나왔기 때문이다. 여러 소스를 교차 확인해 정리하고, 마지막엔 내가 만든 서버가 영향받는지 확인하는 방법까지 짚는다.
2026년 4월 — SDK 설계 자체가 도마에
보안 업체 Ox Security가 2026년 4월, MCP SDK의 구조적 결함을 공개했다. 핵심은 stdio 방식이 로컬 서버 프로세스를 명령으로 실행하는 구조인데, 그 명령이 프로세스가 정상적으로 뜨는지와 무관하게 실행된다는 점이다. 별도 검증이나 경고가 없다.
보도에 따르면 노출 규모가 크다. 취약한 프로젝트를 합쳐 다운로드 1억 5천만 건, 공개적으로 접근 가능한 서버 7,000곳 이상, 취약 인스턴스는 최대 20만 개로 추산됐다. 특정 라이브러리 하나의 버그가 아니라 공식 SDK의 기본 동작이 하위 프로젝트로 그대로 퍼진 형태라 파장이 넓었다.
주목할 점은 대응이다. 보도에 따르면 Anthropic은 이 동작이 “의도된 설계”이며 입력 검증은 개발자 책임이라는 입장으로 별도 패치를 하지 않았다고 한다. Ox Security는 대신 개별 오픈소스 프로젝트를 대상으로 30건 넘는 제보와 10여 개의 CVE 발급으로 대응했다. 이 부분은 단일 매체 보도라 그대로 단정하기보다 “이렇게 전해졌다” 정도로 받아들이는 게 안전하다.
CVE-2026-25536 — TypeScript SDK의 교차 클라이언트 유출
더 구체적이고 확실한 건 이쪽이다. 공식 GitHub Advisory에 등록된 CVE-2026-25536(CVSS 7.1, High)은 TypeScript SDK에서 한 클라이언트의 응답이 다른 클라이언트로 새는 정보 노출 취약점이다.
| 항목 | 값 |
|---|---|
| 대상 | @modelcontextprotocol/sdk |
| 영향 버전 | 1.10.0 ~ 1.25.3 |
| 수정 버전 | 1.26.0 |
| 조건 | StreamableHTTPServerTransport + 다중 클라이언트 |
원인은 인스턴스 재사용이다. 하나의 transport를 여러 요청이 공유하면 JSON-RPC 메시지 ID가 충돌한다. 클라이언트 SDK들이 ID를 0부터 증가시키다 보니 서로 다른 클라이언트가 같은 ID를 만들고, 서버는 응답을 엉뚱한 연결로 보낸다. McpServer 인스턴스를 여러 transport에 재사용해도 내부 참조가 덮여 같은 문제가 난다. 도구 호출 결과·리소스 내용·진행 알림까지 전부 영향 범위다.
권고는 명확하다. 요청(또는 세션)마다 서버와 transport 인스턴스를 새로 만들 것. 1.26.0부터는 잘못된 재사용을 조용히 넘기지 않고 에러로 알려준다.
그래서 내 서버는 안전한가
여기가 이 글의 실용적인 부분이다. 이 프로젝트의 서버로 직접 확인해봤다.
# 설치된 SDK 버전 확인
node -e "console.log(require('@modelcontextprotocol/sdk/package.json').version)"
# → 1.29.0두 가지 이유로 영향권 밖이었다.
- 버전: 1.29.0은 수정 버전 1.26.0보다 위다.
- 구조: 이 서버는
StdioServerTransport를 쓰고 클라이언트가 하나뿐이다. 취약점의 전제인 “HTTP transport + 다중 클라이언트 동시 접속”에 해당하지 않는다.
즉 stdio 로컬 서버는 이 CVE의 사정권이 아니다. 반대로 말하면, 서버를 HTTP로 옮겨 여러 클라이언트를 받는 순간 이 조건에 정확히 들어간다. transport를 바꾸는 건 단순한 배포 방식 변경이 아니라 보안 모델이 바뀌는 일이다.
사고들이 공유하는 뿌리
한 보안 업체가 정리한 MCP 사고 타임라인을 보면 2025년부터 패턴이 반복된다. 과도한 권한을 가진 토큰, 검증 없는 입력, 인증이 빠진 엔드포인트, 그리고 도구 설명(metadata)에 악성 지시를 심는 tool poisoning이다. 2025년 5월 GitHub MCP에서 프롬프트 인젝션으로 비공개 저장소가 유출된 사례, 9월 악성 “Postmark MCP Server”가 모든 메일을 공격자에게 몰래 참조로 보낸 사례가 대표적이다.
공통점은 MCP가 LLM에게 실행 권한을 넘기는 통로라는 데서 온다. 도구 하나를 잘못 신뢰하면 그 권한이 그대로 공격 표면이 된다.
서버를 만든다면 최소한 이것만은
- SDK를 최신으로 유지한다. 지금 기준 1.26.0 이상.
- 인스턴스를 재사용하지 않는다. 요청·세션마다 새로 만든다.
- stdio로 시작하고, HTTP로 옮길 땐 인증과 세션 격리를 함께 설계한다.
- 남의 MCP 서버를 붙일 땐 실행 명령을 직접 확인한다. 설정 한 줄이 곧 로컬 명령 실행이다.
- 도구에 주는 토큰 권한을 최소화한다. 사고 대부분이 여기서 커졌다.
MCP는 아직 어리고, 표준이 퍼지는 속도를 보안 모델이 못 따라가고 있다. 초기 웹이 그랬듯 지금은 규격보다 관행이 먼저 굳는 시기다. 직접 서버를 만들어보는 입장에선 이 시기의 사고 사례가 곧 설계 교본이다.
이 글은 웹 검색으로 모은 소스를 교차 확인해 정리했다. 아래 자료는 실제로 본문을 읽은 것만 실었다.
참고 자료
이 글에 대한 의견은 아래 댓글로 남겨주세요 (GitHub 계정 필요). 로그인 없이 남기고 싶다면