CVE-2026-42271 BerriAI LiteLLM Command Injection Vulnerability

서론

AI 인프라의 보안 위협이 전통적인 웹 애플리케이션을 넘어 AI 게이트웨이로 확장되고 있다. 2026년 6월 8일, 미국 CISA(Cybersecurity and Infrastructure Security Agency)는 BerriAI LiteLLM의 명령 주입 취약점 CVE-2026-42271을 알려진 악용 취약점(KEV) 카탈로그에 등록하며, 야생에서 활발히 악용되고 있음을 확인했다.

LiteLLM은 다양한 LLM(Large Language Model) API를 OpenAI 호환 형식으로 통합하는 오픈소스 AI 게이트웨이로, 기업의 AI 인프라에서 중요한 역할을 담당한다. 이 취약점은 단순히 서버 하나의 제어권을 넘겨주는 것을 넘어, AI 서비스 공급망 전체를 위협할 수 있는 심각한 공격 경로를 제공한다.

특히 Horizon3.ai 연구진은 CVE-2026-42271과 CVE-2026-48710(Starlette 인증 우회)을 연계하여 인증 없는 원격 코드 실행(RCE)을 달성하는 익스플로잇 체인을 확인했다. 이는 공격자가 어떤 자격증명도 없이도 LiteLLM 인스턴스를 완전히 장악할 수 있음을 의미한다.

이 가이드는 국내 기업 운영 환경에서 즉시 수행해야 할 점검 항목, 패치/완화 전략, 탐지 룰, 장기 개선 방안을 실무형 체크리스트로 정리한다.

본론

취약점 개요

CVE ID: CVE-2026-42271
CVSS 점수: CVSS v4.0
CVSS 벡터: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:N/SA:N
CWE: CWE-77, CWE-78 (명령 주입)

영향 버전:
- 1.74.2 ≤ 버전 < 1.83.7

취약 엔드포인트:
- POST /mcp-rest/test/connection
- POST /mcp-rest/test/tools/list

취약점 설명:
LiteLLM의 Model Context Protocol(MCP) 서버 미리보기 엔드포인트 2곳이 사용자가 제공하는 서버 설정(command, args, env 필드)을 검증 없이 프로세스로 실행했다. 이 엔드포인트들은 프록시 API 키만으로 접근이 가능했으며, 역할 기반 접근 제어가 적용되지 않았다. 저권한 내부 사용자 키를 보유한 어떤 인증된 사용자도 호스트에서 임의 명령을 실행할 수 있었다.

기술적 세부사항:

POST /mcp-rest/test/connection
{
  "transport": "stdio",
  "command": "/bin/sh",
  "args": ["-c", "whoami"]
}

// LiteLLM이 사용자가 제공한 command를 검증 없이 실행

패치 내용 (v1.83.7):
- 두 테스트 엔드포인트에 PROXY_ADMIN 역할 요구 추가
- Starlette 의존성 업데이트 (CVE-2026-48710 대응)

연계 취약점: CVE-2026-48710

CVE ID: CVE-2026-48710
CVSS 점수: 6.5 (Medium)
대상: Starlette ≤ 1.0.0

취약점 설명:
Starlette은 LiteLLM이 사용하는 ASGI 프레임워크다. 1.0.0 이하 버전은 Host 헤더를 올바르게 검증하지 않아 인증 계층을 우회할 수 있는 "BadHost" 취약점이 존재한다.

연계 공격 시나리오:
1. 공격자가 조작된 Host 헤더로 요청 전송 (CVE-2026-48710)
2. LiteLLM 인증 계층 우회, 프록시 API 키 없이도 접근 성공
3. 취약한 MCP 테스트 엔드포인트에 명령 주입 페이로드 전송 (CVE-2026-42271)
4. 인증 없는 원격 코드 실행 달성

결합 CVSS 점수: 10.0 (Critical)

공급망 위협: 2026년 3월 PyPI 공급망 공격

LiteLLM은 2026년 3월 24일 또 다른 보안 사고를 겪었다. v1.82.7과 v1.82.8 버전이 악성 코드와 함께 PyPI에 게시되었고, 이 버전들은 크리덼셜 스틸러를 포함하고 있었다.

영향:
- 악성 버전은 약 40분 동안 PyPI에서 유통
- 환경 변수 스캔, SSH 키, 클라우드 공급자 자격증명, Kubernetes 토큰, 데이터베이스 비밀번호 수집
- models.litellm.cloud (비공식 도메인)로 데이터 전송

현재 취약점과의 관련성:
LiteLLM에 대한 공격자의 관심이 높아지고 있음을 보여준다. AI 게이트웨이가 크리덼셜 집계 지점으로서 공격자에게 매력적인 목표가 되고 있다.

실제 악용 현황

CISA KEV 등록:
- 등록일: 2026년 6월 8일
- 연방 기관 대응 기한: 2026년 6월 22일 (14일)
- 악용 상태: 확인됨 (Confirmed Exploitation)

랜섬웨어 연관성:
CISA KEV 카탈로그에서는 이 취약점의 랜섬웨어 활용 여부를 "Unknown(알 수 없음)"으로 표기하고 있다. 일부 보고서에서 Qilin 랜섬웨어 그룹과의 연관성을 언급하고 있으나, 현재까지 구체적인 악용 사례나 공식 확인은 이루어지지 않은 상태다.

타임라인:
- 2026년 4월 20일: CVE-2026-42271 공개
- 2026년 5월 8일: LiteLLM v1.83.7 패치 릴리스
- 2026년 5월 26일: CVE-2026-48710 공개
- 2026년 6월 1일: Horizon3.ai, 연계 익스플로잇 체인 확인
- 2026년 6월 8일: CISA KEV 카탈로그 등록

국내 기업 영향 분석

LiteLLM 사용 환경:
- AI 서비스 개발/운영 팀이 LLM API 통합 및 관리 용도로 사용
- 프록시 모드로 독립 배포되거나 Python SDK로 애플리케이션에 통합
- 다중 클라우드 환경에서 AWS Bedrock, Azure OpenAI, Google Vertex AI 등 통합

노출 지점:
1. 인터넷 노출 LiteLLM 인스턴스: 공격자가 직접 접근 가능
2. 내부 네트워크에서 외부 연결 가능한 인스턴스: 피해 시 공급망 침투 경로
3. 개발/테스트 환경: 보안 설정이 느슨할 가능성

위험 요소:
- AI API 키 (OpenAI, Anthropic, Cohere 등) 노출
- 클라우드 자격증명 (AWS, GCP, Azure) 노출
- 내부 네트워크로의 횡적 이동 가능성
- 연결된 AI 인프라 및 다운스트림 시스템 장악

즉시 조치 체크리스트 (24시간 이내)

1. 버전 확인

# Docker 환경
docker exec <container> pip show litellm

# Python 환경
pip show litellm

• [ ] LiteLLM 버전이 1.83.7 이상인지 확인
• [ ] Starlette 버전이 1.0.1 이상인지 확인

2. 즉시 완화 조치 (패치 전)

# 리버스 프록시/API 게이트웨이에서 엔드포인트 차단
# Nginx 예시
location /mcp-rest/test/ {
    deny all;
}

• [ ] POST /mcp-rest/test/connection 엔드포인트 차단
• [ ] POST /mcp-rest/test/tools/list 엔드포인트 차단
• [ ] 인터넷 노출 LiteLLM 인스턴스 확인
• [ ] 신뢰할 수 없는 네트워크 접근 제한

3. 로그 검토

• [ ] 최근 30일간 /mcp-rest/test/ 엔드포인트 접근 로그 확인
• [ ] 비정상적인 Host 헤더 활동 확인
• [ ] 예상치 못한 자식 프로세스 실행 이벤트 확인 (sh, bash, python, node, curl, wget, nc)
• [ ] 프록시 서브프로세스에서 비신뢰 목적지로의 아웃바운드 연결 확인

4. 크리덴셜 로테이션

• [ ] LiteLLM 프록시에 저장된 모든 API 키 로테이션
• [ ] 클라우드 공급자 자격증명 (AWS, GCP, Azure) 로테이션
• [ ] 데이터베이스 비밀번호 로테이션
• [ ] SSH 키 로테이션

5. 공급망 공격 영향 확인

# v1.82.7 또는 v1.82.8 설치 여부 확인
find /usr/lib/python3*/site-packages/ -name "litellm_init.pth"

# 비정상 도메인 연결 확인
# 모델 리테스름.cloud 또는 체크마르크.존 (오타가 난 도메인) 접속 로그 확인

• [ ] 2026년 3월 24일 10:39-16:00 UTC 사이에 LiteLLM 설치/업그레이드 이력 확인
• [ ] litellm_init.pth 파일 존재 여부 확인
• [ ] models.litellm.cloud 또는 checkmarx[.]zone으로의 아웃바운드 연결 확인
• [ ] 영향이 확인된 경우 자산 전체 포렌식 수행

패치/완화 전략 (72시간 이내)

1. 패치 적용

# Python 환경
pip install litellm>=1.83.7
pip install starlette>=1.0.1

# Docker 환경
docker pull ghcr.io/berriai/litellm:v1.83.7-stable

# Docker 이미지 서명 검증 (권장)
cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:v1.83.7-stable

• [ ] 모든 LiteLLM 인스턴스를 v1.83.7 이상으로 업그레이드
• [ ] Starlette를 v1.0.1 이상으로 업그레이드
• [ ] Docker 이미지 서명 검증 수행
• [ ] 패치 후 엔드포인트 차단 해제 (필요시)

2. 네트워크 세분화

• [ ] LiteLLM 인스턴스를 격리된 VPC/서브넷에 배치
• [ ] 신뢰할 수 있는 서브넷에서만 접근 허용
• [ ] 방화벽 규칙으로 아웃바운드 연결 제한

3. 역할 기반 접근 제어 강화

# LiteLLM config.yaml 예시
api_keys:
  sk-1234:  # 개발자용 저권한 키
    models:
      - gpt-4
      - claude-3
    max_budget: 100
    user_id: dev-team
    user_role: internal-user  # PROXY_ADMIN 아님

  sk-admin-5678:  # 관리자용 고권한 키
    models: ["*"]
    max_budget: 10000
    user_id: admin
    user_role: proxy-admin  # MCP 관리 권한

• [ ] MCP 관리용 별도 API 키 생성 및 관리자에게만 할당
• [ ] 내부 사용자 키에서 MCP 관리 기능 제거
• [ ] 최소 권한 원칙 적용

4. 보안 헤더 강화

# Starlette 미들웨어로 Host 헤더 검증
from starlette.middleware.base import BaseHTTPMiddleware
from starlette.requests import Request

class HostHeaderMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request: Request, call_next):
        allowed_hosts = ["litellm.example.com", "api.example.com"]
        host = request.headers.get("host", "").split(":")[0]
        if host not in allowed_hosts:
            return JSONResponse({"error": "Invalid Host"}, status_code=400)
        response = await call_next(request)
        return response

• [ ] 명시적 허용 목록으로 Host 헤더 검증
• [ ] 디폴트 거부 정책 적용

탐지 룰 (감시 및 경보)

1. SIEM/EDR 룰

// 아비르 (Security Event 관리) 룰 예시
Rule: LiteLLM 비정상 프로세스 생성
Condition: Process.ChildProcess.Name in ["sh", "bash", "python", "node", "curl", "wget", "nc"]
           AND Process.ParentProcess.Name contains "litellm"

Rule: LiteLLM 비신뢰 아웃바운드 연결
Condition: NetworkOutbound.DestPort == 80 or 443
           AND Process.Name contains "litellm"
           AND NetworkOutbound.DestDomain not in ["api.openai.com", "api.anthropic.com", ...]

• [ ] 비정상적인 자식 프로세스 생성 경보 설정
• [ ] 비신뢰 도메인으로의 아웃바운드 연결 경보 설정
• [ ] /mcp-rest/test/ 엔드포인트 접근 시도 경보 설정
• [ ] 비정상적인 Host 헤더 경보 설정

2. 로그 수집

# LiteLLM 액세스 로그 설정
# config.yaml
set_verbose: true
litellm_api_key_management: true
log_raw_request_response: true  # 개발 환경에서만 사용

• [ ] 액세스 로그 활성화
• [ ] 모든 API 키 사용 로그 수집
• [ ] MCP 관련 엔드포인트 접근 로그 별도 저장
• [ ] 90일 이상 로그 보관 (규정 준수 고려)

3. 취약점 스캐닝

• [ ] 정기적으로 LiteLLM 및 의존성 스캐닝 수행 (Trivy, Snyk 등)
• [ ] CISA KEV 카탈로그 통합 및 자동화된 취약점 확인
• [ ] CI/CD 파이프라인에 보안 스캐닝 단계 추가

장기 개선 항목 (1개월 이내)

1. 자산 관리 및 인벤토리

• [ ] AI 인프라 자산 인벤토리 구축
• [ ] LiteLLM 인스턴스 및 AI 게이트웨이 식별
• [ ] 모든 API 키 및 자격증명 중앙화된 자격증명 관리 시스템(HashiCorp Vault, AWS Secrets Manager 등)으로 이전
• [ ] 자동화된 자산 발견 및 분류 도구 도입

2. 개발 보안 (DevSecOps)

# requirements.txt 예시 - 버전 고정
litellm==1.83.7  # 최신 안정 버전으로 고정
starlette>=1.0.1

• [ ] 의존성 버전 고정 (requirements.txt/poetry.lock/pipenv.lock)
• [ ] PyPI 대신 프라이빗 패키지 레지스트리 사용 (조직 내)
• [ ] SCA(Software Composition Analysis) 도구 도입
• [ ] 보안 코드 리뷰 가이드라인 수립

3. 모니터링 및 응답

• [ ] AI 인프라 전용 보안 모니터링 대시보드 구축
• [ ] 자동화된 인시던트 응답 파이프라인 구축
• [ ] AI 서비스 중단 대비 DR(Disaster Recovery) 계획 수립
• [ ] 주기적인 보안 교육 및 훈련 (팀 전체)

4. 거버넌스 및 정책

• [ ] AI 인프라 보안 정책 수립
• [ ] AI API 키 관리 정책 수립
• [ ] AI 서비스 공급망 리스크 관리 프로세스 구축
• [ ] 보안 팀과 AI 개발 팀 간 협업 체계 구축

엔터프라이즈 환경에서의 실무적 제약 및 고려사항

1. 리소스 제약
- 패치 적용 전 반드시 테스트 환경에서 검증 필요
- 패치 기간 동안 서비스 가용성 고려 (롤링 업데이트 권장)
- 예방적 다운타임 계획 수립 필요

2. 규정 준수
- 개인정보보호법 및 정보통신망법 준수 필요
- AI 서비스 운영 시 데이터 국외 이동 제약 확인
- 로그 보관 기간 및 개인정보 포함 여부 검토

3. 협업 문화
- 보안 팀과 AI 개발 팀 간의 커뮤니케이션 채널 확보
- 긴급 패치 시 승인 프로세스 간소화
- 보안 이슈 전파 프로세스 구축

4. 공급망 보안
- 오픈소스 라이브러리 평가 기준 수립
- 공급자 보안 평가 (Vendor Security Assessment)
- SBOM(Software Bill of Materials) 관리

결론

CVE-2026-42271은 AI 인프라 보안의 중요성을 강조하는 중요한 케이스다. LiteLLM과 같은 AI 게이트웨이는 단순한 프록시가 아니라, 조직의 AI 서비스 공급막 전체를 제어하는 중요한 자산이다. 이 취약점은 다음과 같은 핵심 교훈을 제공한다.

첫째, AI 인프라는 보안 자산으로 관리해야 한다.
기존의 웹 애플리케이션 보안 관행을 AI 인프라에 그대로 적용할 수 없다. AI 게이트웨이는 수십 개의 API 키와 자격증명을 보관하는 크리덼셜 집계 지점으로서, 더 높은 보안 수준과 공급망 리스크 관리가 필요하다.

둘째, 연계 취약점을 고려한 종합적 방어가 필요하다.
CVE-2026-42271 단독으로도 위험하지만, CVE-2026-48710과 연계되면 인증 없는 RCE가 가능해진다. 개별 취약점 패치뿐만 아니라, 의존성 전체를 포함한 종합적 취약점 관리가 필요하다.

셋째, 공급망 보안은 선택이 아닌 필수다.
2026년 3월 LiteLLM 공급망 공격은 오픈소스 생태계의 취약성을 보여준다. 패키지 서명 검증, 프라이빗 레지스트리, SBOM 관리 등 공급망 보안 프로세스를 구축해야 한다.

즉시 대응 우선순위:
1. 24시간 이내: 버전 확인, 엔드포인트 차단, 로그 검토, 크리덴셜 로테이션
2. 72시간 이내: 패치 적용, 네트워크 세분화, RBAC 강화, 보안 헤더 강화
3. 1개월 이내: 자산 관리, DevSecOps 도입, 모니터링 강화, 거버넌스 구축

국내 기업들은 이 취약점을 계기로 AI 인프라 보안 체계를 재점검하고, 장기적인 AI 보안 전략을 수립해야 한다. AI의 성장과 보안은 상충하지 않는다. 오히려, 견고한 보안이 없는 AI 인프라는 성장의 발목을 잡을 수 있다.

대응 방안 체크리스트

참고자료

1. NVD - CVE-2026-42271
   https://nvd.nist.gov/vuln/detail/CVE-2026-42271

2. CVSS v4.0 벡터 제공 (GitHub CNA)

3. GitHub Security Advisory - BerriAI/litellm (GHSA-v4p8-mg3p-g94g)
   https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g

4. 공식 보안 권고문 및 패치 정보

5. CISA - Known Exploited Vulnerabilities Catalog
   https://www.cisa.gov/known-exploited-vulnerabilities-catalog

6. GitHub Release - LiteLLM v1.83.7-stable
   https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable

7. LiteLLM Security Update - March 2026 Supply Chain Incident
   https://docs.litellm.ai/blog/security-update-march-2026

8. The Hacker News - LiteLLM Flaw CVE-2026-42271 Exploited in the Wild
   https://thehackernews.com/2026/06/litellm-flaw-cve-2026-42271-exploited.html

9. Horizon3.ai - CVE-2026-42271: LiteLLM Unauthenticated RCE
   https://horizon3.ai/attack-research/vulnerabilities/cve-2026-42271-chained-with-cve-2026-48710/

10. CybelAngel - LiteLLM Vulnerability CVE-2026-42271: 7 Things to Know
    https://cybelangel.com/blog/itellm-vulnerability-cve-2026-42271/

11. Help Net Security - LiteLLM vulnerability under active attack
    https://www.helpnetsecurity.com/2026/06/09/litellm-vulnerability-under-active-attack-cisa-warns-cve-2026-42271/

본 콘텐츠는 AI 기술로 생성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하시면 댓글을 통해 소중한 의견 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.