무슨 일이 있었나
2026-10-02(창 내)에 게시된 WorkOS 분석은 하나의 근본 원인(검증되지 않은 인증 입력 신뢰)을 공유하는 세 가지 MCP 생태계 인증 결함을 상세히 설명했으며, 공식 MCP Python SDK의 이 GHSA-qx49-fqc8-xw99 문제도 포함된다. SDK의 OAuth 클라이언트는 발급자를 일관되게 검증하지 않았고 자격 증명을 발급 서버에 바인딩하지 않았다; 1.30.0 / 2.2.0에서 수정되었으며 CVE는 할당되지 않았다. 동반된 rmcp(Rust SDK) 결함 CVE-2026-63127(CVSS 8.2, 2.0.0에서 수정) 및 LiteLLM 헤더 신뢰 결함 CVE-2026-59822(CVSS 8.8, 1.84.0에서 수정, 9월 2일 KEV 등재)가 동일한 패턴을 완성한다.
왜 중요한가
MCP 생태계는 표준 에이전트 도구 연결 메커니즘이다; 클라이언트 측 OAuth 결함은 에이전트를 단일 악성 MCP 서버에 연결하는 것만으로 애플리케이션의 OAuth 클라이언트 자격 증명이 유출되고 공격자가 합법적인 리소스에 대한 토큰을 얻을 수 있음을 의미한다. 무인 머신 간 에이전트 연결을 실행하는 AI 배포의 경우, 이는 사용자가 없어 알아차릴 사람이 없는 에이전트에서 자격 증명 도용으로 이어지는 직접적인 경로이다.
공격 경로
악성 MCP 서버가 클라이언트에 로그인 위치를 지시하고, SDK가 사용된 주소에 대해 발급자(RFC 8414)를 일관되게 검증하지 않으며 클라이언트 등록/시크릿을 발급한 서버에 바인딩하지 않는다 — 따라서 404(레거시 폴백) 또는 403 insufficient_scope를 트리거하면 SDK가 클라이언트 시크릿, 인증 코드 및 PKCE 검증자를 공격자 제어 토큰 엔드포인트로 전송한다; 공격자는 범위 내의 합법적인 리소스에 대한 토큰을 보유하게 된다
영향받는 시스템
MCP Python SDK mcp 1.9.1 ~ 1.29.1 및 2.0.0 ~ 2.1.1(공식 Model Context Protocol 참조 SDK)
완화 방안
mcp 1.30.0 또는 2.2.0+로 업그레이드; ClientCredentialsOAuthProvider 및 PrivateKeyJWTOAuthProvider에 issuer=를 명시적으로 전달(3.0에서 필수); 1.30.0 이전에 저장된 등록을 지우고 예상 발급자에 대해 재등록; 취약한 클라이언트가 신뢰할 수 없는 서버에 연결된 적이 있으면 시크릿을 교체