LiteLLM CVE‑2026‑42271, 실제 공격에 이용… AI 게이트웨이 결함이 인증 없는 원격 코드 실행으로 연결.

발행: (2026년 6월 12일 AM 12:22 GMT+9)
11 분 소요
원문: Dev.to

Source: Dev.to

AI 인프라가 점점 더 심각한 공격 표면이 되고 있습니다. 최신 사례는 BerriAI LiteLLM에 존재하는 명령어 주입 취약점인 LiteLLM CVE‑2026‑42271이며, CISA가 실제 악용 증거를 확인하고 이를 Known Exploited Vulnerabilities 카탈로그에 추가했습니다.
LiteLLM은 다양한 LLM 제공자를 OpenAI 호환 인터페이스를 통해 라우팅하는 데 사용되는 인기 있는 오픈소스 AI 게이트웨이이자 Python SDK입니다. 따라서 매우 민감한 인프라 구성 요소가 됩니다. 보통 애플리케이션, 사용자, API 키, 모델 제공자, 내부 도구, AI 워크플로 사이에 위치합니다.

이 취약점 자체만으로도 인증된 사용자(유효한 프록시 API 키 보유)가 LiteLLM 호스트에서 임의의 명령을 실행할 수 있어 위험합니다. 하지만 CVE‑2026‑48710(Starlette Host 헤더 검증 우회)과 연계될 경우 위험이 더욱 심각해집니다. Horizon3.ai는 이 체인이 인증을 완전히 우회하고, 취약한 LiteLLM 배포에서 인증되지 않은 원격 코드 실행(RCE) 으로 이어질 수 있다고 보고했습니다. :contentReference[oaicite:0]{index=0}

CVE‑2026‑42271 개요

CVE‑2026‑42271은 LiteLLM Python 패키지에 존재하는 명령어 주입 취약점입니다. NVD에 따르면 1.74.2 이상 1.83.7 미만 버전이 영향을 받습니다. 이 문제는 요청 본문에 전체 서버 구성 데이터를 포함할 수 있는 두 개의 MCP 서버 프리뷰 엔드포인트에서 발생했으며, 여기에는 stdio 전송에 사용되는 명령 실행 필드가 포함됩니다. :contentReference[oaicite:1]{index=1}

취약한 엔드포인트:

  • POST /mcp-rest/test/connection
  • POST /mcp-rest/test/tools/list

이 엔드포인트들은 MCP 서버를 저장하기 전에 테스트하거나 미리 보기 위해 설계되었습니다. 문제는 command, args, env와 같은 필드를 허용했다는 점입니다. stdio 구성을 사용해 호출하면 LiteLLM은 제공된 서버 설정에 연결을 시도하면서 프록시 호스트에서 해당 명령을 서브프로세스로 실행합니다.

쉽게 말해, 이 엔드포인트에 접근할 수 있는 사용자는 LiteLLM 프록시가 서버에서 명령을 실행하도록 만들 수 있습니다.

왜 중요한가?

LiteLLM은 단순한 라이브러리가 아닙니다. 흔히 AI 게이트웨이로 배포되며, 모델 제공자 API 키, 프록시 자격 증명, 환경 변수, 내부 서비스 토큰, 로그 데이터, AI 트래픽 라우팅 규칙 등을 보관하거나 접근할 수 있습니다.
공격자가 LiteLLM 호스트에서 명령 실행 권한을 얻으면 다음과 같은 악용이 가능합니다:

  • 모델 제공자 자격 증명 탈취
  • 프록시가 저장한 API 키 및 비밀 정보 추출
  • 환경 변수 접근
  • AI 게이트웨이 동작 변경
  • 연결된 AI 인프라로의 횡방향 이동
  • 게이트웨이에 연결된 하위 시스템 침해
  • 악성코드, 채굴 프로그램, 지속성 메커니즘 배포

CISA가 CVE‑2026‑42271을 KEV에 추가했다는 것은 방어자가 이를 이론적 위험이 아닌 실제 존재하는 위협으로 간주해야 함을 의미합니다. KEV 카탈로그는 실제 공격에서 악용된 취약점을 강조하기 위해 사용됩니다. :contentReference[oaicite:2]{index=2}

영향을 받는 버전 및 업데이트

  • LiteLLM: 1.83.7 이상으로 업그레이드
  • Starlette(취약 버전 포함 시): 1.0.1 이상으로 업그레이드
    NVD는 CVE‑2026‑48710을 Starlette Host 헤더 검증 결함으로 설명하며, Starlette 1.0.1에서 수정되었습니다. :contentReference[oaicite:3]{index=3}

핵심 문제는 MCP 프리뷰 엔드포인트가 저장 전 전체 서버 구성을 받아들였다는 점입니다. 이 구성에는 stdio 전송에 사용되는 필드가 포함될 수 있습니다. 안전한 설계라면 테스트 엔드포인트가 일반 인증 사용자에게 프록시 호스트에서 임의 서브프로세스 실행을 허용해서는 안 됩니다.

취약한 흐름

  1. 사용자가 MCP 테스트 엔드포인트 중 하나에 요청을 보냅니다.
  2. 요청 본문에 stdio MCP 서버 구성이 포함됩니다.
  3. 구성 안에 공격자가 조작한 command, args, env 필드가 들어갑니다.
  4. LiteLLM이 연결 테스트를 시도합니다.
  5. 프록시 호스트가 제공된 명령을 서브프로세스로 실행합니다.

패치 이전에는 이 엔드포인트가 유효한 프록시 API 키로 보호되었지만, 내부 키를 가진 인증 사용자라도 호스트에서 명령을 실행할 위험이 있었습니다. LiteLLM 1.83.7에서는 권한 검사를 PROXY_ADMIN 역할로 변경해, 공개 보고서에 명시된 저장 엔드포인트와 동일한 동작을 하도록 수정했습니다. :contentReference[oaicite:4]{index=4}

가장 우려되는 점: 익스플로잇 체인

Horizon3.ai는 CVE‑2026‑42271이 CVE‑2026‑48710(Starlette “BadHost” 헤더 검증 우회)과 연계될 경우, 취약한 배포에서 LiteLLM 인증을 완전히 우회할 수 있다고 보고했습니다. :contentReference[oaicite:5]{index=5}

Starlette는 많은 Python 웹 서비스에서 사용되는 경량 ASGI 프레임워크이며, AI 인프라에서도 널리 쓰입니다. CVE‑2026‑48710은 Host 헤더 검증 결함으로, 원시 요청 경로와 재구성된 request.url.path 사이에 차이가 발생할 수 있습니다. NVD에 따르면 Starlette 1.0.1 이전 버전은 HTTP Host 헤더를 검증하지 않고 URL을 재구성했습니다. :contentReference[oaicite:6]{index=6}

이 체인에서는 인증 메커니즘을 우회하고, 유효한 자격 증명 없이도 취약한 MCP 테스트 엔드포인트에 접근할 수 있게 됩니다. 위험 프로파일이 크게 바뀝니다:

  • 단독 CVE‑2026‑42271: 인증된 사용자에 한정된 명령어 주입
  • CVE‑2026‑42271 + CVE‑2026‑48710 연계: 인증되지 않은 원격 코드 실행

경고: LiteLLM 배포에 취약한 Starlette 의존성이 포함되고 해당 라우트가 외부에 노출되어 있다면, 이는 치명적인 인증되지 않은 RCE 위험으로 간주하십시오.

AI 게이트웨이의 중요성

AI 게이트웨이는 이제 프로덕션 인프라의 일부분입니다. LLM 제공자 접근 관리, 라우팅 로직 적용, API 키 저장, 사용자 요청 처리, 프롬프트·응답 로깅, 내부 애플리케이션과 외부 AI 서비스 연결 등을 담당합니다. 따라서 공격자에게 매력적인 표적이 됩니다.

침해된 AI 게이트웨이는 하나 이상의 애플리케이션을 노출시킬 수 있습니다. 여러 모델 제공자, 내부 API, 비밀 정보, 하위 시스템에 대한 접근 권한을 제공할 수 있으며, 특히 고객 지원 자동화, 문서 처리, 코드 생성, 에이전트 오케스트레이션, 내부 지식 검색 등 민감한 워크플로와 가까이 배치된 경우 위험이 더욱 커집니다.

따라서 AI 게이트웨이 취약점은 인증 시스템, API 게이트웨이, CI/CD 시스템, 비밀 관리 인프라의 취약점과 동일하게 다루어야 합니다. 이제는 단순한 개발자 도구가 아닙니다.

버전 확인 방법

pip show litellm

설치된 패키지 확인:

pip freeze | grep -i litellm
pip freeze | grep -i starlette

requirements.txt 사용 시:

grep -i "litellm\|starlette" requirements.txt

Poetry 사용 시:

poetry show litellm
poetry show starlette

Docker 기반 배포라면 레포지토리뿐 아니라 실제 이미지에서도 확인:

docker run --rm your-litellm-image pip show litellm
docker run --rm your-litellm-image pip show starlette

또한 다음 엔드포인트가 신뢰할 수 없는 네트워크에서 접근 가능한지 점검하십시오:

  • /mcp-rest/test/connection
  • /mcp-rest/test/tools/list

프로덕션 환경에서 악용을 테스트하지 마세요. 대신 라우팅, 인증, 리버스 프록시 규칙, 로그 등을 안전하게 검증하십시오.

기본 해결책: 업그레이드

pip install --upgrade "litellm>=1.83.7"

Starlette도 의존성 트리에 포함돼 있다면 업그레이드:

pip install --upgrade "starlette>=1.0.1"

업그레이드 후 버전 확인:

pip show litellm
pip
0 조회
Back to Blog

관련 글

더 보기 »