Model Context Protocol(MCP)을 쓰는 TypeScript 클라이언트에서, OAuth 자격증명이 원래 가야 할 곳이 아닌 다른 권한 서버로 전달될 수 있는 취약점이 공식 자문에 등재되었습니다. CVE-2026-104850과 GHSA-6qxp-vccf-f47h로 관리되는 이 이슈는, 코드 한 줄의 논리 오류라기보다 서버가 제시하는 값을 믿는 인증 흐름의 설계 문제를 다룹니다.
개요
MCP TypeScript SDK에서 OAuth 클라이언트가 자격증명을 전송할 권한 서버(authorization server)를 충분히 고정하지 않은 채, MCP 서버가 안내하는 값을 따라 동작할 수 있다는 자문이 등록되었습니다. 공식 자문 제목은 "OAuth client could send credentials to an authorization server chosen by the MCP server"로, 즉 서버 쪽이 클라이언트의 인증 대상을 실질적으로 선택할 수 있던 구조를 지적합니다.
유지관리자의 수정 흐름은 원인을 비교적 또렷하게 보여줍니다. Pull Request #2887은 expectedIssuer(기대 발급자) 생략을 폐기(deprecate)하고 SEP-2352의 issuer 검사를 일관되게 적용하는 변경이며, 같은 방향의 변경이 Release 2.2.0 코드베이스에 반영되었습니다. issuer를 명시하지 않는 설정이 위험 경로였다는 해석과 맞물리는 지점입니다.
다만 이 글에서 확정지을 수 없는 부분도 분명합니다. 제공된 근거 기준으로는 정확한 취약 버전 범위와 최종 수정 버전 번호, 공식 심각도 점수(CVSS)와 영향 지표, 그리고 실제 악용 사례나 CISA KEV 등재 여부가 확인되지 않았습니다. 이 항목들은 판단 보류가 아니라 확인이 필요한 한계로 다룰 필요가 있습니다.
영향 범위
기술 분석이 가리키는 영향 범위는 크게 다음 세 겹으로 정리됩니다.
- modelcontextprotocol TypeScript SDK의 OAuth 클라이언트 기능을 실제로 사용하는 환경
expectedIssuer설정을 생략한 채 MCP 서버와 연결하는 배포- 외부의, 충분히 검증되지 않은 MCP 서버에 클라이언트를 연결하는 구성
세 조건은 나란히 서 있는 것이 아니라 서로를 강화합니다. OAuth를 쓰지 않는 구성이라면 이 문제의 직접 대상이 아니고, OAuth를 쓰더라도 모든 연결 상대를 자체 배포한 MCP 서버로 한정하고 있다면 노출 면은 크게 줄어듭니다. 반대로 클라이언트 설정에서 기대 발급자가 비어 있고, 연결 상대가 서드파티 MCP 서버라면, 자격증명이 향할 주소를 서버 쪽 안내가 좌우할 수 있는 조건이 성립합니다. 영향 판단은 "SDK 버전"보다 "연결 상대의 신뢰 경계를 누가 통제하는가"에서 시작하는 편이 실전에 가깝습니다.
결과적으로 위험에 놓이는 것은 SDK 자체가 아니라, 그 SDK가 관리하던 자격증명과 그 자격증명으로 접근 가능했던 리소스입니다. 분석은 자격증명이 공격자가 유도한 서버로 흘러갈 경우 계정 탈취나 토큰 도용, 이를 통한 연동 리소스에 대한 무단 접근 가능성이 이어질 수 있다고 봅니다. 그리고 같은 인증 체계를 공유하는 조직이라면, MCP라는 단일 연동이 아니라 인증 신뢰 경계 전반을 다시 볼 필요도 함께 제기됩니다.
기술적 분석
핵심은 "클라이언트가 누구에게 토큰을 요구하러 갈지를 클라이언트가 스스로 확정하지 못했다"는 점으로 요약됩니다. OAuth에서 클라이언트는 권한 서버의 주소를 스스로 탐색하거나 상대의 안내로 전달받을 수 있지만, 그 주소가 조직이 승인한 발급자와 같은지 검증하는 장치가 없으면 전달받은 값은 단순한 안내가 아니라 지시가 됩니다. MCP 서버가 신뢰 경계 바깥에 있을 때 이 지시는 곧 공격 표면이 됩니다.
수정 방향 두 가지가 이 해석을 뒷받침합니다. 하나는 expectedIssuer 생략 자체를 폐기하는 것으로, "기대 발급자를 적지 않아도 되는 상태"를 안전 기본값에서 제거합니다. 다른 하나는 SEP-2352가 다루는 issuer 검사를 상황마다 다르게 적용하지 않고 일관 적용하는 것입니다. 전자가 설정면의 구멍을, 후자가 코드 경로에서의 누락을 메우는 조합으로 읽히며, 두 변경이 2.2.0 릴리스 코드베이스에 함께 들어갔다는 점이 수정의 방향을 보여줍니다.
공격 성립 조건은 조건문으로 두는 것이 정확합니다. 즉, 신뢰하지 않는 MCP 서버에 OAuth 클라이언트가 연결되고, 그 클라이언트가 기대 발급자를 고정하지 않았다면, 자격증명 노출 경로가 열릴 수 있습니다. 세 번째 조건의 반대도 성립합니다. 기대 발급자를 명시적으로 고정한 구성은 서버가 다른 권한 서버를 제시해도 이를 거부할 기준을 가지므로, 같은 SDK 버전을 쓰더라도 위험의 크기가 달라집니다. 그래서 이 취약점은 패치 여부만으로, 또 버전 인벤토리만으로 상태 판단이 끝나지 않습니다.
악용 상태에 대해 현재 확인된 바는 다음과 같습니다. 조사 범위에서 공개된 개념 증명(PoC)이나 실제 악용 사례는 확인되지 않았습니다. 다만 이는 "악용 조건이 없다"는 증거가 아니라 "조건이 실재하는 환경에서는 노출 경로가 열려 있다"는 상태 그대로 읽어야 합니다. 취약 코드의 함수·파일 단위 세부 경로와 입력 검증 지점, 그리고 제품별 전용 로그 포맷이나 이벤트명 역시 근거에 상세가 없어 이 글에서는 특정하지 않았습니다.
대응 방안
즉시 우선순위는 버전 확인보다 설정 확인에 가깝습니다. issuer 바인딩이라는 원인이 설정값과 직결되기 때문입니다.
expectedIssuer를 생략한 OAuth 클라이언트 설정이 남아 있는지 먼저 찾고, 기대 발급자를 명시적으로 지정합니다.- 신뢰할 수 없는 외부 MCP 서버와의 연결을 일시 중단하거나 허용 목록(화이트리스트)으로 제한해, 서버 쪽이 인증 대상을 선택할 여지를 줄입니다.
- MCP 서버가 안내하는 권한 서버 주소를 운영 정책상 허용된 발급자 목록과 대조하는 검증 절차를 마련합니다.
점검이 끝난 뒤에는 설정을 기록과 연결하는 편이 좋습니다. 근거에서 확인된 것은 issuer 검증이라는 구조이므로, 운용 제안도 그 구조에 맞춰 둘 수 있습니다. OAuth 클라이언트가 자격증명을 보낸 권한 서버나 issuer가 조직이 승인한 발급자 목록과 일치하는지 로그로 대조하고, 승인되지 않은 issuer로 향한 인증 요청에 알림을 걸고, MCP 서버별로 안내된 권한 서버 URL의 변경 이력을 모니터링하는 방식입니다. 특정 제품의 이벤트명을 제시하지 못하는 것은 근거의 한계이므로, 자체 SDK 래퍼나 프록시 지점에서 outbound 인증 대상만이라도 관찰하는 것이 현실적인 출발점이 됩니다.
장기 대응은 코드와 프로세스 양쪽에서 고정합니다.
- issuer 검사 일관 적용과
expectedIssuer생략 폐기가 반영된 라인으로 업그레이드하되, 정확한 취약 버전 범위와 최종 수정 버전은 GHSA-6qxp-vccf-f47h 원문에서 확인해 확정합니다. - 모든 MCP 연동 설정에서
expectedIssuer를 필수 항목으로 다루는 구성 표준을 세워, 누락 자체가 구성 오류로 검출되게 합니다. - MCP 서버 온보딩 시 권한 서버와 issuer를 사전 심사하는 공급자 신뢰 관리 절차를 도입해, 신뢰 경계를 확장할 때마다 인증 대상이 검토를 거치도록 합니다.
정리하면 이 이슈는 "패치 가능한 취약점"이면서 동시에 "MCP 연동의 인증 신뢰 경계를 점검하는 트리거"입니다. 심각도 점수가 확인되지 않은 동안에는, 노출 조건을 가진 배포가 남아 있는가와 기대 발급자를 고정했는가를 우선 판단 기준으로 삼는 것이 근거 범위 안에서 합리적인 순서입니다.
참고자료
- OAuth client could send credentials to an authorization server chosen by the MCP server (GHSA-6qxp-vccf-f47h)
- OAuth client could send credentials to an authorization server chosen by the MCP server · CVE-2026-104850 (GHSA-6qxp-vccf-f47h)
- Release 2.2.0 · modelcontextprotocol/typescript-sdk
- deprecate omitting expectedIssuer and apply the SEP-2352 issuer check consistently
함께 읽으면 좋은 글
- CVE-2026-48356: Adobe Commerce·Magento 파일 업로드 취약점(CWE-434)과 실제 악용 흐름 점검
- CVE-2026-46300: Linux Kernel skb 공유 프래그 마커 보존 결함과 커널 업데이트 점검
- CVE-2026-111497: Google Brotli 미확인 반환값 결함, KEV 등재와 디코더 의존성 점검
본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.
댓글 (0)
댓글을 작성하려면 로그인이 필요합니다.
로그인아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!