LiteLLM 1.84.0 이전 버전, MCP 엔드포인트가 아무 토큰이나 받아준 이유

이미지 출처: CISA KEV

CISA가 9월 2일에 알려진 악용 취약점(KEV) 목록에 일곱 건을 한꺼번에 올렸는데, 그 명단 안에 LiteLLM이 들어 있었다. LLM 프록시가 KEV에 오르는 장면은 아직 낯설지만, 사내 AI 게이트웨이가 실제 공격 표면으로 취급되기 시작했다는 신호로 읽는 게 맞다고 봄.

핵심 요약

• LiteLLM 1.84.0 미만의 MCP Streamable HTTP 엔드포인트에서, 위조한 Authorization 헤더만으로 인증을 통과할 수 있었음(CVSS 8.8)
• 키 검증이 실패했을 때 예외를 던지는 대신 빈 인증 객체로 갈아끼우는 OAuth2 passthrough 폴백 경로가 원인
• 1.84.0 이상으로 올리고, MCP 경로의 외부 노출 차단과 업스트림 MCP 서버의 자체 인증을 2차 방어선으로 세워야 함

LiteLLM이 무엇을 대신 들고 있었나

LiteLLM은 BerriAI가 만든 LLM 프록시 겸 게이트웨이임. OpenAI·Anthropic·자체 호스팅 모델을 하나의 API 규격으로 묶어주고, 팀별 가상 키·예산·레이트리밋을 붙여주는 물건이라 도입 속도가 빨랐음. 문제는 여기에 MCP(Model Context Protocol) 중계 기능이 얹히면서 성격이 달라졌다는 점.

MCP를 붙이는 순간 이 프록시는 단순한 토큰 중계기가 아니라 사내 도구들의 관문이 됨. 티켓 시스템, 파일 저장소, 내부 검색, 사내 DB 조회 같은 것들이 MCP 서버로 등록되고, LiteLLM이 그 앞에서 "누가 어떤 툴을 부를 수 있는가"를 판정함. 즉 인증 판정이 무너지면 잃는 게 모델 호출 비용이 아니라 그 뒤에 붙은 도구 전부라는 뜻.

취약점의 구조: 실패를 예외가 아니라 기본값으로 처리함

이번 건은 개념만 놓고 보면 아주 단순함. MCP 인증 핸들러는 업스트림 MCP 서버로 사용자 토큰을 그대로 넘겨주는 OAuth2 passthrough를 지원하고 있었음. 그런데 그 경로에서 LiteLLM 자체 키 검증이 실패했을 때, 요청을 끊는 대신 비어 있는 UserAPIKeyAuth() 객체로 대체하고 흐름을 이어가는 폴백이 존재했음.

결과적으로 형식만 갖춘 Authorization 헤더를 붙여 보내면, 유효한 LiteLLM 키가 하나도 없어도 요청이 MCP 툴 계층까지 도달함. 등록된 툴 목록을 조회하고, 그 툴들을 호출하는 것까지 가능했다는 것. 실행 가능한 형태로 풀어 쓸 이유는 없고, 방어자가 기억할 건 한 줄이면 충분함 — 인증 실패를 "권한 없음"이 아니라 "권한이 비어 있는 사용자"로 번역하면 그 순간 fail-open이 됨.

이런 패턴이 유독 AI 인프라에서 자주 나오는 이유도 짚어둘 만함. 여러 인증 방식(마스터 키, 가상 키, JWT, OAuth 패스스루)을 동시에 지원하려다 보니 분기가 늘어나고, "이 경로에서는 이 검증을 건너뛰어도 된다"는 예외가 쌓임. 그러다 보면 어느 분기 하나가 조용히 열려 있게 되는 것 같음.

지금 확인할 것

• 배포된 LiteLLM 버전 확인. 1.84.0 미만이면 대상임. 컨테이너 이미지 태그만 믿지 말고 실제 실행 중인 패키지 버전을 확인할 것
• MCP 엔드포인트가 인터넷에서 직접 닿는지 점검. 프록시 앞단 로드밸런서·인그레스 규칙에서 MCP 경로가 공개돼 있는 경우가 생각보다 많음
• MCP 서버로 등록된 도구 목록과 각 도구의 권한 범위 재확인. 읽기 전용으로 충분한데 쓰기 권한이 붙어 있는 항목이 있는지
• KEV 등재 건이므로 공공·금융 쪽은 내부 기한 관리 대상에 올려야 함

로그에서 무엇을 찾을 것인가

패치보다 먼저 해야 할 일은 "이미 당했는지" 확인하는 것임. 볼 지점은 이렇게 잡으면 됨.

• 키 식별자가 비어 있는 성공 요청. 정상 트래픽이면 요청 로그에 가상 키 해시나 팀/사용자 식별자가 남음. 이 필드가 비었는데 응답이 200인 MCP 요청은 그 자체로 이상 신호
• 인증 실패 없이 곧바로 도구 목록을 조회한 세션. 정상 사용자는 대개 모델 호출과 섞여서 들어오는데, 툴 목록 조회로 시작해 호출로 바로 넘어가는 흐름은 정찰 패턴에 가까움
• 단일 IP·단일 User-Agent에서 반복되는 MCP 세션 초기화. 자동화 도구 특유의 리듬이 남음
• 업스트림 쪽 로그와 대조. LiteLLM 로그가 지워지거나 부실해도, 실제 도구를 제공한 내부 서비스(파일 서버, 티켓 API 등)에는 호출 흔적이 남음. 게이트웨이 로그와 업스트림 로그의 건수가 맞지 않으면 그 차이를 파고들 것

패치 이후에도 남겨둘 방어선

버전을 올리는 건 최소 조건이고, 같은 유형이 또 나왔을 때 버텨줄 구조를 만드는 게 진짜 대응이라고 생각함.

• MCP 경로는 네트워크 경계로 한 번 더 막기. 사내망·VPN·mTLS 뒤로 넣어서, 애플리케이션 인증이 뚫려도 도달 자체가 안 되게 만드는 게 가장 확실함
• 업스트림 MCP 서버에 자체 인증 걸기. "게이트웨이가 걸러줄 것"이라는 전제를 지우면 이번 같은 폴백 버그의 피해가 한 단계에서 끊김
• 도구 권한 최소화와 분리. 조회용 도구와 변경용 도구를 다른 자격증명으로 나누고, 변경 계열은 승인 절차를 붙일 것
• 키 회전과 예산 상한. 노출 가능성이 있었던 기간의 키는 전부 갈아치우고, 팀별 예산 상한을 실질적인 피해 억제선으로 써야 함
• 인증 코드에 대한 회귀 테스트. "잘못된 토큰이면 반드시 거부된다"는 케이스를 테스트로 박아두는 것. 폴백 분기는 사람 눈으로 리뷰할 때 가장 잘 놓치는 자리임

마무리

AI 인프라는 아직 "편의 기능"과 "보안 경계"의 구분이 흐린 편임. MCP처럼 도구를 붙여주는 기능은 특히 그런데, 붙이는 순간 그 프록시는 사내 시스템으로 들어가는 문이 되어버림. 개인적으로는 AI 게이트웨이를 도입한 조직이라면 이번 기회에 자산 목록에 정식으로 올리고, 웹 서버나 VPN 장비와 같은 등급으로 패치 주기를 관리하시길 추천드림.

혹시 사내에서 LiteLLM이나 비슷한 프록시를 쓰고 계시다면, 오늘 버전 한 번만 확인해보시면 좋겠음. 확인하시다가 이상한 로그를 발견하셨거나, 반대로 "우리는 이렇게 막고 있다" 하는 구성이 있으시면 댓글로 공유해주세요. 같이 정리해보아요!