CISA, KEV에 LiteLLM의 MCP 인증 우회 추가: 아무 Bearer 토큰이나 충분했다

2026년 9월 2일, 미국 사이버보안 및 인프라 보안국(CISA)은 CVE-2026-59822를 "BerriAI LiteLLM 부적절한 인증 취약점"으로 알려진 악용 취약점(KEV) 카탈로그에 추가했으며, 이는 그날 배치된 7개 결함 중 하나였습니다. 이 버그는 LiteLLM의 MCP Streamable HTTP 엔드포인트에 있습니다. LiteLLM 키 검증이 실패했을 때 OAuth2 패스스루 폴백이 요청을 거부하는 대신 빈 UserAPIKeyAuth() 객체로 대체했기 때문에, 조작된 Authorization Bearer 헤더라도 인증된 MCP 세션을 열 수 있었습니다. 해당 엔드포인트에 도달한 공격자는 게이트웨이에 구성된 모든 MCP 도구를 나열하고 호출할 수 있었으며, 그 도구를 통해 뒤에 있는 서비스에도 접근할 수 있었습니다. 1.84.0 이전의 모든 버전이 영향을 받으며, 연방 민간 기관에는 2026년 9월 16일까지 해결할 기한이 주어졌습니다. LiteLLM의 MCP 인증 우회에 대한 KEV 등재인 이 기록은 다음 아카이브의 한 항목으로 포함되어 있습니다: OrcaRouter AI Incident Archive, 여기에는 전체 기록 세트와 이 사건의 인접 항목이 포함되어 있습니다.

프록시의 버그가 CVSS 점수가 시사하는 것보다 더 중요한 이유는 프록시 뒤에 무엇이 있는지에 달려 있다. Wiz의 위협 연구팀은 이를 직설적으로 말한다: "LiteLLM 프록시는 라우팅하는 모든 모델 제공업체(OpenAI, Anthropic, Azure, Gemini 포함)의 키를 보유할 수 있다. 또한 클라우드 IAM 권한으로 실행되고 MCP 도구 서버를 통해 내부 서비스에 연결될 수도 있다. 단 한 번의 침해로 공격자는 프록시 자체뿐 아니라 프록시 다운스트림의 자격 증명과 서비스에 접근할 수 있다." Wiz Research는 이 결함을 발견했다고 밝혔으며, Wiz의 허니팟은 나중에 이를 이용하려는 시도를 기록했다.

메커니즘: 유효한 세션을 반환한 실패한 검사

BerriAI 자체 권고문인 GHSA-7488-6r32-c95q는 이 결함을 두 문장으로 설명합니다. "MCP 인증 핸들러는 업스트림 MCP 서버에 대한 OAuth2 패스스루를 지원했지만, 폴백 경로는 실패한 LiteLLM 키 검증을 빈 UserAPIKeyAuth() 객체로 대체할 수 있었습니다. 이로 인해 조작된 Authorization 헤더가 포함된 요청이 유효한 LiteLLM 키 없이 MCP 도구에 도달할 수 있었습니다." 중요한 단어는 폴백입니다. 코드에는 업스트림 MCP 서버의 OAuth 토큰을 그대로 전달하는 배포를 위한 분기가 있었는데, LiteLLM 키 검증에 실패하면 해당 분기는 오류 대신 빈 인증 객체를 반환했습니다.

빈 인증 객체는 인증 객체가 없는 것과 같지 않습니다. 다운스트림 코드는 성공적으로 생성된 UserAPIKeyAuth를 보고 진행했지만, 여기에는 테넌트도, 사용자도, 스코프도 연결되어 있지 않았습니다. Wiz의 글은 그 실제 결과를 더 직설적으로 표현합니다. "토큰 검증이 실패하면 서버는 요청을 거부하는 대신 제한이 전혀 없는 빈 UserAPIKeyAuth() 객체를 반환합니다. 어떤 Bearer 토큰이든(단 한 문자, 예를 들어 x라도) 전체 MCP 접근 권한을 부여합니다."

공격자가 그것으로 얻는 것은 일종의 메뉴다. MCP 프로토콜은 도구 목록을 노출하므로, 인증된 세션은 게이트웨이가 접근하도록 구성된 모든 도구의 이름과 스키마를 반환한다. Wiz의 예시에서는 데이터베이스, 코드 저장소, 내부 API가 여기에 해당한다. 공급업체 권고문은 그 효과를 분명히 밝힌다. “공격자는 이를 이용해 구성된 MCP 도구를 나열하고 호출하며, MCP를 통해 노출된 연결 서비스에 접근할 수 있다.” 그런 다음 도구 호출은 프록시 자체가 해당 백엔드에 대해 보유한 권한으로 실행되며, 이것이 바로 Wiz가 설명하는 자격 증명 집중 문제다.

5월의 수정, 7월의 CVE, 9월의 연방 기한

날짜들은 독자가 짐작할 수 있는 방식으로 맞아떨어지지 않으며, 그 간격이 흥미로운 부분이다. LiteLLM 1.84.0 — 권고문이 패치된 버전으로 명시한 첫 버전 — 은 패키지 인덱스 자체의 릴리스 메타데이터에 따르면 2026년 5월 14일 PyPI에 업로드되었다. CVE 식별자는 2026년 7월 7일 CVE Program에 예약되었고, 기록은 다음 날인 7월 8일에 게시되었다. OSV 항목 PYSEC-2026-3479은 7월 23일에 뒤따랐다. KEV 목록 등재는 9월 2일에 이루어졌으며, 조치 기한은 9월 16일이었다.

두 가지 사실이 뒤따릅니다. 첫째, 패치된 빌드는 CISA가 해당 결함을 악용된 것으로 등재하기 전까지 석 달 넘게 공개되어 있었습니다. 따라서 마감 기한의 적용을 받는 조직들은 그동안 내내 작동하는 업그레이드를 이용할 수 있었고, KEV 등재는 수정 사항이 나온 시점이 아니었습니다. 둘째, 그 이후 버전 격차는 더 벌어졌습니다. 현재 PyPI의 LiteLLM 릴리스는 2026년 10월 27일에 업로드된 1.106.5입니다. 여전히 1.84.0 미만에 머물러 있는 배포는 이제 단순히 패치 하나가 부족한 것이 아니라 20개가 넘는 마이너 릴리스 뒤처져 있습니다.

그 리스팅이 입증하는 것과 입증하지 못하는 것

CISA가 해당 배치에 대한 경보에서 추가는 "활성 악용의 증거를 기반으로" 이루어진다고 밝혔으며, 카탈로그의 CVE-2026-59822에 대한 기계 판독 가능 항목에는 추가 날짜 2026년 9월 2일, 기한 2026년 9월 16일, 알려진 랜섬웨어 캠페인 사용 값 "알 수 없음", 그리고 두 가지 약점인 CWE-287(부적절한 인증) 및 CWE-306(중요 기능에 대한 인증 누락)이 포함되어 있습니다.

• 확인된 사항: CISA는 이 결함을 실제로 악용된 것으로 평가하고 연방 교정 목록에 올렸습니다. CISA 코디네이터에 귀속되고 2026년 9월 2일 타임스탬프가 찍힌 NVD의 SSVC 기록은 악용 상태를 "활성", 자동화 가능성을 "예", 기술적 영향을 "부분적"으로 기록합니다.

• 확인됨: 통제된 환경에서 익스플로잇이 관찰되었습니다. Wiz는 단일 문자 토큰이 포함된 요청이 모델 열거 엔드포인트를 탐색하는 허니팟 트래픽을 공개했습니다. 해당 요청은 "Authorization: Bearer x"를 포함하여 /v1/models로 보내는 GET 요청이었습니다. The Hacker News는 9월 3일 KEV 배치를 보도하면서 같은 활동을 Wiz가 "CVE-2026-59822와 관련된 익스플로잇 시도가 자사 허니팟을 대상으로 모델 열거 엔드포인트를 탐색하는 것"을 관찰한 것으로 설명했습니다.

• 확인된 사항: 심각도 점수는 둘 다 존재하며 프레임워크에 따라 다릅니다. BerriAI의 권고는 이 취약점의 CVSS 4.0 점수를 8.8(높음)로 평가하며, 기밀성 높음, 무결성 낮음, 가용성 없음으로 표시합니다. NVD에서 기본으로 사용되는 NIST 자체의 CVSS 3.1 평가는 이를 8.2로 봅니다. 두 숫자는 서로 다른 점수 체계 아래 동일한 결함을 설명하는 것이므로, 하나가 다른 하나를 대체한 것처럼 비교해서는 안 됩니다.

• 확인되지 않음: 이름이 공개된 피해자. CISA의 경고, BerriAI의 권고문, Wiz의 분석 글, The Hacker News의 보도 중 어느 것도 이 결함을 통해 MCP 도구에 접근이 이루어진 조직을 식별하지 않으며, 그러한 조직에서 탈취된 자격 증명이나 데이터를 보고하지도 않는다. 공개된 익스플로잇 기록은 허니팟 텔레메트리와 연방 당국의 판단이며, 공개된 침해 사고가 아니다.

• 입증되지 않음: 어떤 랜섬웨어 그룹도 이를 사용하지 않는다는 점. KEV 필드는 "Unknown"으로 표시되는데, 이는 CISA가 부여하는 값이지 어느 쪽으로든 부재를 입증하는 결과가 아닙니다.

6월의 선례, 그리고 이것이 아닌 원격 코드 실행 체인

이것은 2026년에 KEV 카탈로그에 등재된 두 번째 LiteLLM 취약점이며, 앞선 취약점은 이것과 혼동하기 쉽다. 2026년 6월 8일에 추가되어 6월 22일이 기한인 CVE-2026-42271은 LiteLLM의 MCP 서버 테스트 엔드포인트에서 발생하는 명령 주입 취약점이다. Wiz는 사용자가 MCP 서버 구성을 저장하기 전에 테스트할 수 있게 하는 엔드포인트를 설명하는데, 여기서 command 필드가 검증 없이 하위 프로세스 실행으로 전달된다. 공격자들은 command가 암호화폐 채굴기를 다운로드해 실행하는 가짜 stdio 서버 구성을 제출했고, 테스트가 성공한 것처럼 보이도록 정상으로 보이는 MCP 핸드셰이크를 반환했다. CISA의 등재 항목에는 CWE-78과 CWE-77이 나열되어 있는데, 이는 인증이 아니라 명령 및 인자 주입이다.

그 취약점은 연쇄되는 바로 그 취약점이다. Wiz는 CVE-2026-42271이 "Starlette 호스트 헤더 검증 우회(CVE-2026-48710)와 연쇄되어 완전 무인증 RCE를 달성할 수 있다"고 말하며, 외부 연구자들이 Qilin 랜섬웨어 그룹을 해당 연쇄의 활발한 악용과 연관 지었다고 밝혔다. CVE-2026-48710은 LiteLLM 우회와 같은 9월 2일 배치로 KEV 카탈로그에 추가되었으며, 마감 기한도 같은 9월 16일이고, CISA 자체의 Starlette 취약점에 대한 카탈로그 비고에는 CVE-2026-42271과 연쇄될 수 있다고 명시되어 있다. Qilin 연결은 그 조합에 해당한다. 그것은 CVE-2026-59822에 관한 발견이 아니며, 검토된 출처 중 어디에도 해당 랜섬웨어 그룹을 인증 우회와 연결하는 내용은 없다.

하나의 행정적 세부 사항이 두 LiteLLM 항목을 구분한다. 6월 목록의 필수 조치는 더 오래된 구속력 있는 운영 지침인 BOD 22-01을 인용하는 반면, 9월 목록은 BOD 26-04, "위험에 기반한 보안 업데이트 우선순위 지정"을 인용한다. CISA의 경보는 그 변경을 설명하지 않으며, 카탈로그도 이에 대해 주석을 달지 않는다.

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

해결 경로는 짧습니다. BerriAI의 권고는 1.84.0 이상으로 업그레이드할 것을 권장하며, 즉시 전환할 수 없는 팀을 위한 우회 방법을 제시합니다: "MCP 라우트를 비활성화하거나 리버스 프록시 또는 API 게이트웨이에서 /mcp/ 및 관련 MCP 엔드포인트에 대한 접근을 차단하십시오." 이 우회 방법은 기능을 제어하는 대신 제거하는 조잡한 수단입니다 — 하지만 패치되지 않은 배포에 대해 공급업체가 명시하는 유일한 완화책입니다.

CISA가 진입점에 대해 요구하는 조치 문구는 연방 기관들을 동일한 딜레마에 놓습니다. 즉, 공급업체 지침에 따라 그리고 BOD 26-04에 맞춰 완화 조치를 적용하거나, "완화 조치를 사용할 수 없는 경우 제품 사용을 중단"해야 하며, 자산의 인터넷 노출을 평가할 책임은 각 기관에 있습니다. 이 지침은 연방 민간 행정부 기관에만 구속력이 있으며, CISA는 다른 조직에도 동일한 위험 기반 우선순위 지정을 채택하도록 권장하지만 이를 의무화하지는 않습니다.

허니팟 외부의 누군가가 마감 시한까지 조치를 취했는지는 공개되지 않았다. CISA와 BerriAI 모두 얼마나 많은 LiteLLM 배포가 노출되었는지, 얼마나 많은 배포가 9월 16일 전에 패치되었는지, 또는 얼마나 많은 배포가 우회 경로를 통해 접근되었는지에 대한 수치를 발표하지 않았다.

무엇이 아직 열려 있나요?

세 가지 공백은 {{1}}덮어두기보다는 짚고 넘어갈 가치가 있습니다{{/1}}. {{2}}CVE-2026-59822를 특정 침해 사건과 연결하는{{/2}} 공개 사고 보고서는 없으므로, KEV 등재는 {{3}}CISA의 악용 증거와 Wiz의 허니팟 관찰{{/3}}에 근거하며 {{4}}문서화된 피해자{{/4}}에 근거한 것은 아닙니다. {{5}}폴백 경로가 왜 그렇게 작성되었는지{{/5}} 또는 {{6}}1.84.0 이전에 얼마나 오래 존재했는지{{/6}}에 대한 공급업체 성명은 없습니다 — 권고문은 {{7}}결함과 그 수정{{/7}}을 설명할 뿐 {{8}}그 이력{{/8}}은 설명하지 않습니다. 그리고 해당 배치의 기한은 일률적이지 않았습니다: {{9}}9월 2일에 추가된 7개 항목 중 5개{{/9}}에는 {{10}}9월 5일{{/10}} 기한이 적용되었고, {{11}}LiteLLM 및 Starlette 항목{{/11}}에는 {{12}}9월 16일{{/12}}이 적용되었습니다. CISA는 그 이유를 밝히지 않습니다.

확정된 것은 점수보다 범위가 좁고 더 유용하다. 영향을 받은 버전에서는 Authorization 헤더의 단일 문자가 MCP 엔드포인트에 유효한 키와 구별되지 않았으며, 그렇게 동작한 버전들은 2026년 5월에 더 이상 최신 버전이 아니게 되었다.