LiteLLM 프록시 서버 SQL 인젝션 취약점 (CVE-2026-42208) 긴급 보안 권고
실무자 핵심 요약 (Executive Summary)
SECOPS ASSESSMENTLiteLLM 버전 1.81.16 이상 1.83.7 미만을 사용하는 AI 게이트웨이 및 프록시 서버 환경
인증되지 않은 공격자가 조작된 Authorization 헤더를 전송하여 데이터베이스 정보를 탈취하거나 수정하고, 프록시 관리자 권한 및 API 자격 증명을 획득할 수 있음
즉시 LiteLLM 버전을 1.83.7 이상으로 업데이트하고, 패치 적용 전까지 WAF 규칙을 통해 비정상적인 Authorization 헤더 요청을 차단할 것
영향받는 제품 및 버전 범위
권장 패치 및 임시 완화(Workaround) 가이드
PATCH & WORKAROUND1. 공식 보안 패치 적용
가장 확실한 해결책은 취약점이 해결된 최신 안정 버전(v1.83.7 이상)으로 패키지를 업그레이드하는 것입니다.
# pip를 사용하는 경우
pip install --upgrade litellm>=1.83.7
# Poetry를 사용하는 경우
poetry add litellm@latest2. 임시 완화 조치 (WAF 및 입력값 검증)
즉각적인 패치가 어려운 경우, 웹 애플리케이션 방화벽(WAF) 또는 리버스 프록시(Nginx, Kong 등)에서 Authorization 헤더에 SQL 인젝션 특수문자(예: ', --, UNION, SELECT 등)가 포함된 요청을 차단하도록 규칙을 설정하십시오.
Nginx 설정 예시:
server {
listen 80;
server_name litellm.internal;
location / {
# Authorization 헤더에 SQL 인젝션 패턴이 존재하는지 검사
if ($http_authorization ~* "[\';\-\-]|union|select|insert|update|delete") {
return 403 "Invalid Authorization Header";
}
proxy_pass http://localhost:4000;
}
}코드 수정 전에도 가상 패치(Virtual Patching)로 웹 공격을 즉시 차단하세요
서버 재시작이나 긴급 패치가 어려운 운영 환경이라면 클라우드 WAF 관리형 룰셋을 활성화하여 SQLi, RCE, XSS 익스플로잇 페이로드를 엣지에서 1분 만에 차단할 수 있습니다.
취약점 발생 원리 및 공격 메커니즘
LiteLLM은 다양한 LLM API를 OpenAI 규격으로 통합하여 호출할 수 있게 해주는 오픈소스 AI 게이트웨이 프록시 서버입니다.
본 취약점(CVE-2026-42208)은 LiteLLM의 API 키 검증 로직에서 발생하는 SQL 인젝션(CWE-89) 취약점입니다. 프록시 API 키를 검증하는 데이터베이스 쿼리 수행 과정에서, 호출자가 제공한 키 값을 매개변수화된 쿼리(Parameterized Query)로 처리하지 않고 쿼리 텍스트에 직접 결합(String Concatenation)하여 발생합니다.
인증되지 않은 외부 공격자는 /chat/completions와 같은 임의의 LLM API 라우트에 악의적으로 조작된 Authorization 헤더를 전송할 수 있습니다. 이 요청이 프록시의 에러 핸들링 경로(Error-handling path)를 통과할 때 조작된 SQL 구문이 데이터베이스 엔진에서 그대로 실행됩니다. 이를 통해 공격자는 데이터베이스 내의 민감한 정보(타사 API 키, 사용자 자격 증명 등)를 무단으로 조회하거나 수정하여 시스템 전체를 장악할 수 있습니다.
본 취약점은 CVSS 9.8의 치명적(Critical) 등급으로 평가되었으며, 실제 공격에 악용된 이력이 확인되어 CISA KEV(Known Exploited Vulnerabilities) 목록에 등재되었습니다.
공식 보안 권고문 및 참조 링크
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.81.16 to before version 1.83.7, a database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a specially crafted Authorization header to any LLM API route (for example POST /chat/completions) and reach this query through the proxy's error-handling path. An attacker could read data from the proxy's database and may be able to modify it, leading to unauthorised access to the proxy and the credentials it manages. This issue has been patched in version 1.83.7.
일간 취약점 브리핑 및 긴급 Zero-Day 경보 구독
보안 실무자와 인프라·백엔드 엔지니어를 위해 매일 아침 주요 취약점과 패치 우선순위를 요약해 발송합니다.