AI 도구를 외부 서비스와 연결하는 표준인 MCP(Model Context Protocol)의 공식 파이썬 SDK에서 심각한 보안 결함이 발견됐습니다. 이 결함이 있는 버전을 쓰면, 악의적인 MCP 서버가 클라이언트를 속여 진짜 로그인 서비스 대신 자신에게 OAuth(로그인 인증) 정보인 클라이언트 비밀키, 인가 코드, PKCE 검증 키를 보내도록 만들 수 있습니다. 공격자는 이 정보로 진짜 서비스에서 유효한 접근 토큰을 발급받아 해당 앱이 가진 권한을 그대로 사용할 수 있습니다. 보안업체 Cycode가 이를 실제로 재현해 보고했으며, 아직 실제 공격 사례는 확인되지 않았습니다. SDK 1.30.0과 2.2.0 버전에서 수정됐으므로 즉시 업그레이드하고, 일부 인증 방식은 추가 설정(issuer=)까지 해야 완전히 안전합니다.
MCP 공식 파이썬 SDK의 결함으로, 악의적인 MCP 서버가 클라이언트를 속여 OAuth 클라이언트 비밀키·인가 코드·PKCE 키를 공격자에게 전송하게 만들 수 있음이 발견됐다.
공격자는 탈취한 정보로 진짜 로그인 서비스에서 유효한 접근 토큰을 발급받아 해당 앱과 동일한 권한을 행사할 수 있다. 클라이언트 비밀키는 장기간 유효해 교체 전까지 계속 악용될 수 있다.
SDK가 서버가 알려준 인증 서버(로그인 서비스) 주소를 제대로 검증하지 않아, 악성 서버가 임의의 주소로 유도할 수 있었다.
SDK 1.x는 1.30.0, 2.x는 2.2.0으로 업그레이드해야 한다. 일부 인증 방식(ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider)은 업그레이드 후에도 issuer= 옵션을 직접 설정해야 완전히 안전하며, 저장된 OAuth 등록 정보 삭제와 필요시 비밀키 교체·토큰 폐기도 권고된다.
HTTP로 신뢰할 수 없는 MCP 서버에 연결하면서 실제 로그인 정보를 다루는 클라이언트 애플리케이션이라면 우선순위로 패치해야 하며, 특히 issuer= 미설정 시 업그레이드만으로는 방어되지 않는 점을 놓치기 쉽다.
본문
Swati Khandelwal 2026년 9월 29일 신원 보안 / 인공지능
악의적인 MCP 서버가 공식 MCP 파이썬 SDK로 만들어진 애플리케이션을 속여, 실제 서비스에 로그인할 때 사용하는 OAuth(로그인 인증) 정보를 넘겨주게 만들 수 있다고 SDK 관리자들이 보안 권고문에서 밝혔다.
영향을 받는 버전은 클라이언트 비밀키(client secret), 인가 코드(authorization code), PKCE 증명 키(proof key)를 공격자가 통제하는 토큰 엔드포인트로 전송했다. 이 문제는 버전 1.30.0과 2.2.0에서 수정됐다.
MCP(Model Context Protocol)는 AI 애플리케이션을 외부 도구 및 데이터와 연결하는 공개 표준이며, 이 패키지는 MCP 서버와 클라이언트를 구축하기 위한 공식 파이썬 SDK다.
탈취한 인증 정보를 이용하면 공격자는 실제 로그인 서비스로부터 유효한 접근 토큰(access token)을 발급받을 수 있다. 이 결함을 신고한 보안업체 Cycode는 테스트를 통해 이 전체 교환 과정을 실증했으며, 결과로 얻은 토큰은 해당 앱에 부여된 권한을 그대로 가진다고 밝혔다. 클라이언트 비밀키는 수명이 길어서 교체되기 전까지는 계속 악용될 수 있다.
이 결함은 사람이 개입하지 않고 동작하는 두 종류의 제공자(provider)에 대해서는 위험도 높음(7.5)으로 평가됐다. 사람이 직접 로그인을 시작해야 하는 대화형(interactive) 제공자 기준으로는 6.5점이다. 9월 29일 기준 CVE 번호는 아직 부여되지 않았다.
서버가 인증 정보를 탈취하는 방법
MCP 클라이언트가 로그인해야 할 때, 자신이 연결하는 서버에게 로그인 서비스(인가 서버, authorization server)의 위치를 묻는다. 결함이 있는 버전에서는 SDK가 그 응답을 항상 검증하지는 않았다. 악의적인 서버는 공격자 자신의 서버를 지정하거나, 사용자의 실제 서비스 이름을 담은 로그인 정보를 보여주면서 실제로는 인증 정보를 다른 곳으로 보내도록 유도해, 클라이언트를 원하는 로그인 서비스로 유도할 수 있었다.
그러면 클라이언트는 자신의 비밀키, 인가 코드, PKCE 증명 키를 실제 서비스가 아닌 공격자에게 전송한다. 이 증명 키는 탈취된 인가 코드가 재사용되는 것을 막기 위한 일회성 값이므로, 이를 넘겨주는 것은 그 보호 장치 역시 무력화시키는 셈이다.
대화형 제공자의 경우 사람이 여전히 로그인을 승인해야 한다. Cycode는 사용자가 승인하는 페이지가 진짜 로그인 페이지이기 때문에 이상해 보이는 부분이 전혀 없다고 밝혔다. 반면 두 종류의 머신 대 머신(machine-to-machine) 제공자는 로그인 절차도, 사람의 개입도 전혀 필요하지 않다.
영향을 받는 대상
애플리케이션이 SDK를 HTTP 기반 MCP 클라이언트로 사용하면서 OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider, 혹은 더 이상 사용되지 않는 1.x의 RFC7523OAuthClientProvider 중 하나의 인증 제공자를 쓰고, 완전히 신뢰하지 않는 서버에 연결하면서 실제 로그인 서비스의 인증 정보를 보유하고 있다면 영향을 받는다. SDK로 만든 MCP 서버, 로컬(stdio) 클라이언트, 자체적으로 토큰을 붙이는 클라이언트는 영향을 받지 않는다.
| 라인 | 영향받는 버전 | 수정된 버전 |
|---|---|---|
| 1.x | 1.9.1 ~ 1.29.1 | 1.30.0 |
| 2.x | 2.0.0 ~ 2.1.1 | 2.2.0 |
해야 할 일
1.x 라인은 1.30.0으로, 2.x 라인은 2.2.0으로 업그레이드해야 한다. 수정된 버전에서는 클라이언트가 어떤 로그인 서비스를 기대하는지 먼저 확인한 뒤 해당 정보를 가져오며, 다른 서비스를 지정하는 응답은 거부한다.
업그레이드만으로 완전한 해결책이 되지 않는 제공자가 두 가지 있다. ClientCredentialsOAuthProvider나 PrivateKeyJWTOAuthProvider를 사용한다면, 권고문은 "업그레이드해도 해당 인증 정보가 속한 로그인 서비스를 지정하는 issuer= 를 함께 설정하지 않으면 아무것도 바뀌지 않는다"고 밝혔다. 이를 설정하지 않으면 여전히 MCP 서버가 지정하는 대로 따라간다.
1.30.0 버전에서는 이에 대한 경고가 표준 지원 중단(deprecation) 경고로 표시되는데, 파이썬은 기본적으로 이를 숨기기 때문에 놓치기 쉽다. 더 이상 사용되지 않는 RFC7523OAuthClientProvider에는 issuer= 옵션 자체가 없으므로, 다른 두 제공자 중 하나로 옮겨야 한다.
업그레이드 후에는 저장된 OAuth 클라이언트 등록 정보를 한 번 정리해야 한다. 기존 등록 정보는 특정 로그인 서비스에 묶여 있지 않고 그 상태가 계속 유지되기 때문이다. 클라이언트가 신뢰할 수 없는 서버에 이미 연결됐을 가능성이 있다면, 해당 클라이언트의 비밀키를 교체하고 로그인 서비스에서 토큰을 폐기해야 한다. 이전 버전에서는 신뢰하는 MCP 서버에만 연결하는 것 외에 다른 우회 방법이 없다.
공개 경위
이 인가 서버 검증 기능은 9월 7일 발표된 1.30.0과 2.2.0 릴리스 노트에 보안 수정이 아닌 동작 변경 사항으로 포함되어 배포됐다. 보안 권고문은 9월 28일, Cycode가 자체 분석글을 발표한 것과 같은 날 뒤이어 나왔다. 이 권고문은 Cycode 연구원을 포함해 8명의 신고자에게 공을 돌렸다.
권고문과 Cycode 모두 이 결함을 이용한 실제 공격 사례는 보고하지 않았으며, 다른 곳에서도 보고된 바 없다.
관련 투런 솔루션
이 뉴스의 취약점·위협, 투런 솔루션으로 대응하세요.
