Azure MCP Server의 SSRF로 인해 관리 ID 토큰이 URL로 유출될 수 있음

마이크로소프트는 2026년 3월 10일 CVE-2026-26118을 공개했습니다: Azure MCP Server Tools의 서버 측 요청 위조 취약점으로, 이 패키지는 AI 에이전트와 MCP 클라이언트가 자연어로 Azure 리소스에 대해 작업할 수 있게 합니다. MCP 기반 에이전트와 상호작용할 수 있는 공격자는 정상적인 Azure 리소스 식별자 대신 악성 URL을 제출할 수 있으며, 그러면 서버는 해당 주소로 아웃바운드 요청을 보내고 마이크로소프트의 표현대로 “관리 ID 토큰을 포함할 수” 있어 호출자에게 본래 보아서는 안 되는 자격 증명을 넘겨주게 됩니다. 마이크로소프트는 이 취약점에 CVSS 8.8을 부여하고 중요(Important)로 평가했으며, 수정 사항이 포함된 패키지 버전은 1.0.2 및 2.0.0-beta.17입니다. 이 권고에는 패치 전의 악용이나 공개적 공개가 기록되어 있지 않으며, 이로 인한 실제 피해도 기록되어 있지 않습니다. 이 사건은 Orca AI Incident Archive에 수록된 항목 중 하나로, 인용된 출처, 심각도 등급 및 신뢰도 평가가 포함된 전체 기록이 보관되어 있습니다.

권고문이 실제로 말하는 것

Microsoft Security Response Center 기록은 간략하며, 이 취약점에 관해 공개된 세부 사항은 거의 모두 이 기록이나 소수의 후속 질문에 대한 Microsoft의 답변에서 비롯된다. 전체 설명은 다음과 같다. “Azure MCP Server의 서버 측 요청 위조(SSRF)로 인해 권한을 가진 공격자가 네트워크를 통해 권한을 상승시킬 수 있다.” CVE 기록은 2026년 2월 11일에 식별자를 예약했고 3월 10일 14:00 UTC에 이를 공개했으며, Microsoft의 릴리스 노트와 NVD 항목 모두 그날 날짜를 기재하고 있다. NVD는 해당 기록을 분석해 같은 날 오후 18:18 UTC에 게시했다. 이 기사에서 확인된 유일한 규제 기관 공지는 모로코에서 나왔는데, DGSSI의 maCERT 부서는 2026년 3월 11일자 게시판에 CVE-2026-26118을 실었고, 영향을 받는 제품 중 Azure MCP Server Tools를 자체 위험 등급인 Important로 나열했으며, 별도 점수 없이 Microsoft의 릴리스로 돌아가는 링크를 제시했다.

이 약점은 CWE-918에 매핑됩니다. 이는 서버 측 요청 위조(SSRF)이며, 영향 분류는 권한 상승입니다. Microsoft의 기본 점수는 벡터 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H에서 8.8이며, 시간 점수는 E:U/RL:O/RC:C에서 7.7입니다. E:U 구성 요소는 점수가 설정되었을 때 Microsoft가 익스플로잇 코드를 알지 못했음을 의미하고, RL:O는 공식 수정 사항이 제공되었음을 의미합니다. NVD는 동일한 기본 점수를 가지며 이를 High로 분류합니다. Microsoft 자체의 3단계 척도에서는 이를 Important로 부릅니다.

점수만큼이나 중요한 두 가지 필드가 있습니다. Microsoft의 기록에 따르면 악용됨: 아니요 그리고 공개적으로 공개됨: 아니요. NVD 항목에 대한 CISA의 SSVC 결정 기록(2026년 3월 5일 타임스탬프)도 악용 여부에 대해서는 없음이라는 점에 동의하면서, 기술적 영향은 전체이며, 자동화 가능 여부는 아니요라고 판단합니다. FIRST EPSS 모델은 2026년 11월 3일자 조회에서 향후 30일 내 악용 확률을 약 1.0%, 62.8번째 백분위수로 제시했습니다. 이는 발견되어 수정된 결함이며, 실제로 사용된 것으로 알려진 결함은 아닙니다.

리소스 식별자가 아웃바운드 요청이 되는 방식

Azure MCP Server는 AI 에이전트가 도구를 호출하는 데 사용하는 인터페이스인 Model Context Protocol의 Microsoft 구현입니다. 이 서버의 도구는 에이전트가 제공한 매개 변수(스토리지 계정 이름, 구독 식별자, 데이터베이스 이름)를 Azure의 관리 및 데이터 평면에 대한 호출로 변환합니다. Microsoft 설명서에서는 이 서버가 “Azure 사용자 자격 증명 또는 관리 ID”를 사용하여 Entra ID를 통해 인증하며, 액세스는 Azure 역할 기반 액세스 제어로 제한된다고 설명합니다.

결함은 Azure 리소스를 지정해야 하는 매개변수가 대신 URL로 허용되는 지점에 있습니다. Microsoft의 설명에 따르면, 공격자는 “사용자 제공 매개변수를 받는 Azure Model Context Protocol (MCP) Server 도구에 특수 제작된 입력을 보내 이 문제를 악용할 수 있습니다. 공격자가 MCP 기반 에이전트와 상호작용할 수 있다면 정상적인 Azure 리소스 식별자 대신 악성 URL을 제출할 수 있습니다.” 그런 다음 서버는 도구가 의도한 위치가 아니라 지시받은 곳으로 요청을 보냅니다.

성가신 문제를 권한 상승으로 바꾸는 부분은 함께 실려 나가는 것입니다. Microsoft는 아웃바운드 요청이 “자사의 관리 ID 토큰을 포함할 수 있다”고 말하며, 이로 인해 공격자는 “관리자 액세스 없이도” 해당 토큰을 탈취할 수 있습니다. 관리 ID 토큰은 베어러 자격 증명입니다. 이를 보유한 사람은 만료될 때까지 해당 ID가 권한을 부여받은 Azure 서비스에 제시할 수 있습니다. 같은 단락의 완화 측면도 그만큼 중요합니다. 공격자는 “MCP Server의 관리 ID와 연결된 권한”을 얻지만, Microsoft의 표현대로 “더 광범위한 테넌트 수준 또는 관리자 권한을 얻지는 않으며, 침해된 관리 ID에 연결된 권한만 얻습니다.” 영향 범위는 누군가 해당 ID에 부여한 권한 전체이며, 실제로는 단일 도구에 필요했던 것보다 더 큰 경우가 많습니다.

Microsoft는 영향을 받는 도구나 매개변수의 이름을 밝히지 않으며, 이 기사를 위해 검토한 어떤 출처도 밝히지 않는다. 이러한 누락 자체가 하나의 세부 사항이다. 즉, 이 권고문은 단일 엔드포인트가 아니라 사용자가 제공한 매개변수를 받아들이고 URL을 가져오도록 유도될 수 있는 한 부류의 도구를 설명한다.

수정 사항, 그리고 그것을 담은 패키지들

이것은 Windows 업데이트가 아니었습니다. Azure MCP Server Tools는 .NET용 NuGet 패키지, npm 패키지, 그리고 PyPI의 Python 패키지로 배포되며, 수정 사항은 배포에서 사용하는 패키지의 버전을 올리는 것입니다. Microsoft의 권고문에는 영향을 받는 범위가 NuGet, npm 및 PyPI 배포판 전반에 걸쳐 1.0.0부터 1.0.2 미만까지, 그리고 2.0.0-beta.1부터 2.0.0-beta.17 미만까지로 명시되어 있습니다.

npm 레지스트리 날짜에 따르면 수정된 빌드는 권고문보다 먼저 레지스트리에 올라와 있었다. @azure/mcp의 버전 1.0.2는 2026년 3월 6일에 게시되었으며, 이는 CVE가 공개되기 나흘 전이었다. 2.0.0-beta.17은 2026년 2월 6일에 게시되었는데, 이는 Microsoft가 CVE 식별자를 예약한 날보다 닷새 전이자 권고문이 나오기 한 달 전이었다. Microsoft 내부의 순서가 어떻든, 패치된 코드는 공개일에 맞춰 작성된 것이 아니었다. NVD와 GitHub의 권고문 데이터베이스는 그 상한에 동의한다. 이들은 PyPI 범위의 하단에서 조금 다르다. NVD는 2.0.0-beta.1이라고 하고, GitHub 권고문은 2.0.0b14라고 한다. 이는 두 기록이 공개 이후 계속 안고 있는 불일치이며, Python 배포가 얼마나 과거까지 살펴봐야 하는지에만 영향을 준다.

이 보안 권고 자체는 게시 후 10일 뒤인 2026년 3월 20일, Microsoft가 “Azure MCP Server Tools를 제공하는 데 사용된 다양한 패키징 방법을 문서화한 제품을 보안 업데이트 표에 추가했다”는 주석과 함께 개정되었습니다. 다시 말해, 권고의 첫 버전은 제품 이름은 밝혔지만 제품이 배포된 모든 채널을 밝히지는 않았으며, 이는 해결 조치가 “이 KB를 설치하라”가 아니라 “패키지를 업그레이드하라”인 경우 중요합니다.

무엇이 확립되지 않았는가

누가 발견했는가. 마이크로소프트의 권고문에도 CVE.org 기록에도 신고자 이름은 없으며, 해당 CVE의 공로(credits) 항목은 비어 있습니다. 이는 비공개로 누군가에게 공로가 돌아가지 않았다는 증거가 아니라, 공개된 공로가 없다는 것뿐입니다.

익스플로잇 여부.Microsoft는 기록이 없으며, CISA의 SSVC 평가도 이에 동의하고, 이 기사를 위해 검토된 어떤 출처도 실제 환경에서 침해된 신원을 설명하지 않습니다. 해당 기록의 real-harm 필드는 false이며, 이는 그와 일치합니다. 낮은 EPSS는 예측일 뿐 발견된 사실이 아니며, 보고된 사건이 없다는 것이 사건이 전혀 없었다는 증거는 아닙니다.

공개 익스플로잇이 존재하는지 여부. 여기서 보조 근거가 갈린다. 2026년 3월 Blueinfy 블로그의 한 게시물은 “GitHub 등에 있는 공개 개념 증명(proof-of-concept) 익스플로잇”이 있다고 밝히고 “신속한 무기화”를 경고하지만, 링크나 페이로드, 단계별 안내를 제시하지 않으며 그 취약점을 입증하지도 않는다. Microsoft의 기록에 따르면 해당 취약점은 패치 전에 공개적으로 알려지지 않았다. 2026년 11월 4일 CVE 식별자로 GitHub 저장소를 검색한 결과 저장소 하나가 나왔는데, 이는 2026년 3월 17일 공개된 Microsoft Sentinel 탐지 랩이지 익스플로잇이 아니다. 또한 Mallory의 취약점 페이지에는 후보 익스플로잇 두 개가 심사 후 거부되었다고 나와 있다. 이용 가능한 증거로 볼 때, 실제 작동하는 공개 익스플로잇 코드가 있다는 주장은 입증되지 않았으며, 아무도 시도하지 않았다는 주장 역시 마찬가지로 입증되지 않았다.

프레이밍. 공급업체 사고 요약 사이트인 PolicyLayer의 한 페이지는 CVE-2026-26118을 전체 테넌트 탈취로 이어지는 인증되지 않은 원격 코드 실행 체인으로 재구성하며, 특정 연구자와 RSAC 2026 시연에 공을 돌린다. 그 페이지가 직접 인용한 출처들의 제목은 SSRF로 되어 있고, 날짜도 CVE 타임라인과 맞지 않으며, Microsoft의 권고문도 3월 10일 SecurityWeek 보도도 코드 실행을 설명하지 않는다. 이 기사는 SSRF와 토큰에 관한 설명을 확립된 것으로 간주하며 RCE 프레이밍을 반복하지 않는다.

왜 요청이 아니라 토큰이 발견 사항인가

서버 측 요청 위조는 웹 소프트웨어에서 가장 오래된 취약점 유형 중 하나이며, 그 자체로는 보통 공격자가 직접 접근할 수 없는 시스템에 도달하는 수단이다. 이 기록을 보존할 가치가 있게 만드는 것은 요청에 첨부된 자격 증명이다. MCP 서버는 설계상 혼동된 대리자다. 즉, 에이전트가 사용자를 대신해 행동할 수 있도록 신원을 보유하며, 서버의 관점에서 에이전트가 전달하는 모든 매개변수는 공격자의 영향을 받은 텍스트다. 그러한 매개변수 중 하나가 이름이 아니라 목적지가 되면, 대리자는 자신의 인가 권한을 목적지까지 그대로 가지고 간다.

마이크로소프트의 문서는 그 위험이 어디에 집중되는지를 더 분명히 밝힙니다. 문서는 로컬 서버를 “조직 내 개발자 사용만을 엄격히 의도한 것”이라고 설명하는 한편, Microsoft Foundry와 Copilot Studio에서 자체 호스팅 원격 서버를 위한 배포 가이드를 별도로 게시합니다. 이는 개발자 본인의 로그인이 아니라 관리 ID가 일반적으로 사용되는 자격 증명인 구성입니다. 권고안이 제시하는 토큰 탈취 경로는 구체적으로 관리 ID에 관한 것입니다. 모든 설치가 노출되었다고 말하지 않으며, 얼마나 많은 설치가 노출되었는지도 밝히지 않습니다.

일반적인 교훈은 이제 OWASP의 AI Security Verification Standard가 이 사례를 통해 가르치는 바로 그 교훈이다. AISVS 오케스트레이션 장은 CVE-2026-26118을 구체적 사례 중 하나로 인용하며, “MCP 도구 매개변수는 공격자가 제어하는 것으로 간주해야 하며, MCP 서버의 아웃바운드 요청은 다른 모든 에이전트 주도 I/O에 요구되는 것과 동일한 이그레스 및 오리진 정책을 통과해야 한다”는 결론을 도출한다. 그것은 통제 권고사항이지 이 사건에 대한 조사 결과는 아니지만, 무엇이 바뀌어야 하는가라는 질문에 누군가가 공개한 가장 구체적인 답변이다.

이후에 무엇이 바뀌었나요?

세 가지가 있는데, 어느 것도 극적이지 않다. Microsoft는 세 생태계 모두에서 수정 패키지를 배포했고, 권고문을 수정해 그 패키지들의 이름을 명시했다. 취약점 인텔리전스 생태계는 이를 조용히 받아들였다. 낮은 EPSS 점수와 2026년 6월 17일에 마지막으로 수정된 NVD 기록이 있었다. 그리고 표준 커뮤니티는 이를 교육 사례로 채택했는데, 이는 패치보다 느리지만 더 지속적인 대응 방식이다.

영향을 받는 빌드를 아직 실행 중인 사람이라면, 해결 방법은 변함없고 화려하지도 않습니다. 배포가 건드리는 모든 패키지 관리자에서 안정 라인의 1.0.2 이상 또는 미리 보기 라인의 2.0.0-beta.17 이상으로 이동하십시오. 그 외에도, 권고문 자체의 논리는 세 가지 통제를 함의합니다 — 서버가 아웃바운드로 접근할 수 있는 대상을 제한하고, 관리 ID에 해당 도구가 실제로 필요로 하는 역할만 부여하며, URL이 될 수 있는 모든 도구 매개변수를 적대적 입력으로 취급하는 것입니다. CVE-2026-26118에서 살아남기 위해 이 중 어느 것도 필수는 아니었습니다. 각각은 다음 통제가 공격자에게 지니는 가치를 줄여 줄 것입니다.

아카이브가 이것을 어떻게 분류하는지

이 기록은 취약점으로 등록되어 있습니다. 즉, 악용된 것으로 알려진 것이 아니라 발견된 사항이며, 신뢰도 등급은 A로, 1차 출처들이 일치하는 충실한 문서화를 의미하고, 분쟁 상태로 표시되어 있지 않습니다. 실제 피해(real-harm) 필드는 false이고 AI 관련성은 확인되었습니다. 영향을 받는 제품이 우연히 인접해 있는 범용 서비스가 아니라 AI 에이전트와 클라우드 제어 평면 사이의 브리지이기 때문입니다. 날짜는 일 단위 정밀도로 2026년 3월 10일로 기록되어 있으며 종료 날짜는 없습니다. 이는 캠페인이 아니라 단일 시점이기 때문입니다. 지역은 전 세계이며 랜드마크 플래그는 false입니다.

한 필드가 공개된 점수와 다르게 읽힙니다. 아카이브의 심각도는 자체 척도에서 중간으로 기록되어 있습니다. Microsoft와 NVD가 모두 공개하는 수치는 8.8이며, Microsoft는 이를 중요(Important)로 부르고 NVD는 높음(High) 구간으로 분류합니다. 해당 기록의 요약은 그 8.8을 맨 앞에 제시하며, 이 불일치는 사실의 차이가 아니라 구간 분류 방식의 차이입니다.

기록이 전달하지 못하는 것은 이 이야기에서 얼마나 많은 부분이 공백인지다. 잘못된 형식으로 요청하는 사람에게 누구든 클라우드 아이덴티티를 넘겨주는 결함이 있다. 발표 전에 이미 배포된 수정이 있다. 공로를 인정받은 발견자도, 이름이 밝혀진 도구도, 확인된 악용도 없으며, 외부인이 어떤 호스팅 배포 환경이 강력한 아이덴티티를 보유한 채 취약한 빌드를 실행한 적이 있는지 알 방법도 없다. 이 권고문은 결함이 무엇을 하는지에 대해서는 정확하지만 거의 모든 다른 것에 대해서는 침묵하며, 그 침묵이야말로 이 권고문에서 주목할 가장 유용한 점이다.