Python으로 MCP(Model Context Protocol) 클라이언트를 만들고 있다면 패키지 버전을 확인할 필요가 있습니다. 공식 modelcontextprotocol/python-sdk 저장소는 2026년 9월 28일 OAuth 클라이언트와 관련된 High 등급 보안 취약점 GHSA-qx49-fqc8-xw99을 공개했습니다.
핵심은 신뢰할 수 없는 MCP 서버가 OAuth 인증 과정에서 클라이언트 자격증명이 전송되는 인증 서버를 잘못 유도할 수 있었다는 점입니다. 서버를 공격하는 코드가 아니라 MCP 클라이언트가 OAuth 자격증명을 다루는 경로가 영향을 받습니다.
영향받는 버전
공식 GitHub Security Advisory에 따르면 영향 범위는 다음과 같습니다.
1.x: mcp 1.9.1 이상, 1.30.0 미만
2.x: 2.0.0a1 이상, 2.2.0 미만
수정 버전은 각각 1.30.0과 2.2.0입니다. 공식 보안 정책은 지원되는 각 메이저 라인의 최신 릴리스를 사용할 것을 권장합니다.
내 프로젝트 버전 확인하기
가상환경을 활성화한 뒤 다음처럼 설치된 버전을 확인할 수 있습니다.
python -m pip show mcp출력의 Version이 1.9.1~1.29.1 또는 2.0 계열에서 2.2.0보다 낮다면 업데이트 대상인지 확인해야 합니다. requirements.txt, pyproject.toml, lock 파일에 버전이 고정돼 있다면 실제 설치 버전과 선언된 버전을 모두 봅니다.
1.x를 유지해야 한다면 1.30.0 이상으로
아직 2.x로 마이그레이션할 준비가 안 된 프로젝트라면 무조건 메이저 버전을 올리기보다 1.x의 수정 버전으로 먼저 이동할 수 있습니다.
python -m pip install -U "mcp>=1.30.0,<2"업데이트 후에는 테스트를 실행하고 OAuth 로그인·토큰 저장·서버 연결 동작을 실제 개발 환경에서 확인합니다.
2.x 프로젝트는 2.2.0 이상으로
python -m pip install -U "mcp>=2.2.0,<3"의존성을 업데이트한 뒤 python -m pip show mcp로 실제 설치 버전을 다시 확인합니다. CI를 사용한다면 로컬만 업데이트하고 끝내지 말고 lock 파일과 CI 환경도 같은 버전으로 맞추는 것이 중요합니다.
어떤 사용자가 특히 영향받을까
공식 advisory는 HTTP 기반 MCP 클라이언트에서 OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider 등을 auth handler로 사용하는 경우를 주요 영향 대상으로 설명합니다. 반면 SDK로 만든 MCP 서버 자체, stdio 클라이언트, 자체 토큰·헤더를 직접 붙이는 클라이언트는 이 취약점의 직접 영향 대상이 아니라고 명시합니다.
즉 MCP를 쓴다는 이유만으로 모든 Python 프로젝트가 동일한 위험에 놓인 것은 아닙니다. 먼저 자신이 서버인지 클라이언트인지, HTTP OAuth 인증을 실제로 사용하는지를 구분해야 합니다.
ClientCredentialsOAuthProvider를 쓴다면 issuer도 확인한다
중요한 추가 조치가 하나 있습니다. 공식 advisory는 ClientCredentialsOAuthProvider나 PrivateKeyJWTOAuthProvider를 사용하는 경우 단순히 버전만 올리는 것으로 끝나지 않고, 자격증명이 속한 인증 서버를 issuer=로 명시하도록 권장합니다.
수정 버전에서는 issuer가 맞지 않는 인증 서버 메타데이터를 거부하도록 보호가 강화됐지만, unattended provider에서 issuer를 생략하면 향후 3.0에서 필수로 바뀔 예정이라는 경고도 추가됐습니다.
이미 신뢰하지 않는 MCP 서버에 연결했다면
업데이트 이전 버전으로 신뢰할 수 없는 MCP 서버에 OAuth 자격증명을 가진 상태에서 연결한 적이 있다면, 공식 advisory는 해당 인증 서버에서 client secret 교체와 토큰 폐기를 검토하도록 안내합니다. 과거 1.x에서 저장된 OAuth client registration은 issuer 정보가 없을 수 있어 저장 정보를 한 번 지우고 다시 등록하는 조치도 권장합니다.
실제 비밀키나 토큰을 코드 저장소에 올리지 말고, 사용 중인 인증 제공자의 공식 회전·폐기 절차를 따르는 것이 좋습니다.
requirements 파일도 함께 고정한다
로컬에서만 pip install -U를 실행하면 다음 배포에서 취약 버전이 다시 설치될 수 있습니다. 따라서 프로젝트가 1.x를 유지한다면 최소 버전을 1.30.0 이상으로, 2.x를 사용한다면 2.2.0 이상으로 명시하고 lock 파일을 갱신합니다.
Codinginpy의 Python 글 모음처럼 개발환경을 다룰 때는 ‘지금 실행되는가’뿐 아니라 다음 배포에서도 같은 안전한 버전이 재현되는지 확인하는 습관이 중요합니다.
정리
이번 취약점은 MCP Python SDK의 모든 기능이 위험하다는 뜻이 아니라 특정 HTTP OAuth 클라이언트 흐름에서 인증 서버 검증과 자격증명 바인딩이 충분하지 않았던 문제입니다. 영향 버전을 사용한다면 1.x는 1.30.0 이상, 2.x는 2.2.0 이상으로 업데이트하는 것이 우선입니다.
그 다음 자신의 OAuth provider 종류를 확인하고, unattended provider라면 issuer 설정, 과거 노출 가능성이 있다면 secret·token 회전까지 검토하면 됩니다.