LiteLLM SQL Injection KEV 등재

CVE-2026-42208은 BerriAI LiteLLM proxy의 API key 검증 경로에서 발생한 pre-auth SQL Injection이다. 영향 버전은 litellm >=1.81.16, <1.83.7이며, 1.83.7에서 caller-supplied token을 SQL text가 아니라 bound parameter로 넘기도록 수정됐다.

2026-05-08 # cve

요약

CVE-2026-42208은 BerriAI LiteLLM proxy의 API key 검증 경로에서 발생한 pre-auth SQL Injection이다. 영향 버전은 litellm >=1.81.16, <1.83.7이며, 1.83.7에서 caller-supplied token을 SQL text가 아니라 bound parameter로 넘기도록 수정됐다.

CISA는 2026-05-08 이 취약점을 KEV에 추가했고 조치 기한은 2026-05-11로 잡았다. Sysdig는 GitHub Advisory Database 색인 후 약 36시간 뒤인 2026-04-26 04:24 UTC에 실제 exploit 시도를 관측했다.

운영 판단

LiteLLM proxy가 취약 버전으로 외부, 파트너망, 또는 넓은 사내망에 노출돼 있었다면 patch만으로 끝내지 않는다. LiteLLM virtual key, master key, provider API key, cloud credential, DB credential의 노출 가능성을 같이 본다.

항목	내용
CVE	CVE-2026-42208
유형	CWE-89 SQL Injection
대상	BerriAI LiteLLM `>=1.81.16, <1.83.7`
patch	`1.83.7` 이상
patch 배포	2026-04-19, `v1.83.7-stable`
GitHub advisory	2026-04-20
GitHub Advisory Database 색인	2026-04-24 16:17 UTC
실제 exploit 관측	2026-04-26 04:24 UTC
NVD 게시	2026-05-08
KEV 등재	2026-05-08
CISA 조치 기한	2026-05-11
주요 조건	network reachable LiteLLM LLM API route, pre-auth
주요 영향	proxy database read, 구성에 따라 write 가능성

취약 지점

취약 경로는 LiteLLM proxy의 API key verification이다. 공격자가 LLM API route에 Authorization: Bearer header를 보내면, proxy가 bearer token을 검증하는 과정에서 litellm/proxy/utils.py의 PrismaClient.get_data()가 table_name="combined_view" 조회를 수행한다.

취약 버전의 핵심 sink는 combined_view token lookup이다. token 값이 PostgreSQL query 문자열에 직접 들어갔다.

- WHERE v.token = '{token}'
+ WHERE v.token = $1

- response = await self._query_first_with_cached_plan_fallback(sql_query)
+ response = await self._query_first_with_cached_plan_fallback(sql_query, hashed_token)

패치는 단순 필터링이 아니다. exploit primitive는 Authorization header의 bearer 값이 token lookup SQL 문맥으로 이동하는 것이고, 수정 버전은 그 값을 SQL text에서 분리해 positional parameter로 넘긴다. _query_first_with_cached_plan_fallback()도 *args를 받아 primary query와 cached-plan fallback retry 모두에 같은 parameter를 전달하도록 바뀌었다.

Bishop Fox 분석 기준으로 도달 경로는 두 갈래다. 기본 구성에서는 sk- prefix 검증 실패가 error-handling path로 넘어가고, failure metadata enrichment가 raw bearer 값을 다시 key lookup에 넣는다. Python assert가 -O 또는 PYTHONOPTIMIZE=1로 제거되는 구성에서는 guard가 사라져 raw bearer가 더 직접적으로 sink에 도달할 수 있다. GitHub advisory의 workaround인 disable_error_logs: true는 기본 error path를 줄이는 임시 조치에 가깝다.

요청 형태는 다음 수준으로만 이해하면 된다.

POST /v1/chat/completions
Authorization: Bearer <crafted token reaching SQL string context>
Content-Type: application/json

영향 범위

영향 대상은 LiteLLM proxy를 배포하고 LLM API route를 네트워크에서 호출 가능하게 둔 환경이다. advisory와 NVD 기준 공격 전 인증은 필요 없고 user interaction도 필요 없다.

취약 query는 "LiteLLM_VerificationToken"을 기준으로 team, membership, model, budget, organization 관련 테이블을 join하는 combined_view 조회다. Sysdig가 관측한 exploit 시도는 범용 SQLmap spray가 아니라 LiteLLM schema를 겨냥한 형태였고, LiteLLM_VerificationToken, litellm_credentials, litellm_config 같은 credential·configuration 관련 테이블을 우선 노렸다.

LiteLLM은 여러 LLM provider credential, virtual key, budget, routing policy를 한 proxy database에 모으는 구조다. 따라서 DB read가 가능했던 취약점은 단순 애플리케이션 데이터 조회보다 넓게 본다. OpenAI, Anthropic, Azure OpenAI, Bedrock 같은 backend provider credential이 LiteLLM에 저장돼 있었다면 provider-side 사용량과 billing 로그까지 같이 확인한다.

자산 식별

먼저 LiteLLM 실행 위치와 버전을 찾는다. Python package, container image, Helm/Kubernetes 배포가 섞여 있을 수 있다.

python -m pip show litellm

docker image ls --format '{{.Repository}}:{{.Tag}}' | grep -i litellm

helm list -A | grep -i litellm

kubectl get deploy,statefulset -A -o wide | grep -i litellm
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i litellm

1.81.16 이상 1.83.7 미만이면 영향권이다. 1.83.7 이상으로 올렸더라도 취약 기간에 internet-facing 또는 partner-facing proxy로 운영했다면 로그 검토와 credential rotation 범위를 따로 잡는다.

탐지 포인트

네트워크

다음 값은 단독으로 확정 증거가 아니라 우선순위 신호다. Sysdig가 관측한 IP는 rented VPS나 proxy일 수 있다.

항목	확인값
Source IP	`65.111.27.132`, `65.111.25.67`
User-Agent	`Python/3.12 aiohttp/3.9.1`
Header	비정상적으로 길거나 SQL metacharacter가 포함된 `Authorization: Bearer`
Keyword	`'`, `--`, `UNION`, `SELECT`, `FROM`, `OR 1=1`, `pg_sleep`

로그 검색은 header 저장 범위에 맞춰 조정한다.

grep -Ei "Authorization: Bearer .*(\'|--|UNION|SELECT|FROM|OR 1=1|pg_sleep)" access.log
grep -Ei "Python/3\.12 aiohttp/3\.9\.1" access.log

엔드포인트

LLM route에서 인증 실패와 DB error가 같이 증가했는지 본다.

엔드포인트	확인 포인트
`/chat/completions`	비정상 bearer header를 동반한 `401`, `403`, `500` 증가
`/v1/chat/completions`	같은 source에서 반복되는 auth failure
`/v1/completions`	짧은 body와 긴 bearer header 조합
`/v1/messages`	provider 호출 전 단계에서 실패한 요청
`/v1/embeddings`	일반 client 오동작과 다른 SQL keyword 포함 header
`/key/generate`, `/key/info`	unauthenticated probe 또는 auth failure 반복

서버

LiteLLM application log에서는 API key 검증 실패 직후의 DB lookup error, assertion failure, error logging callback 호출을 본다. PostgreSQL audit log가 있으면 WHERE v.token = 주변에 bearer 값이 직접 들어간 query text가 남았는지 확인한다.

provider 콘솔도 같이 본다. LiteLLM DB에서 provider credential이 노출됐을 가능성이 있으면 OpenAI, Anthropic, Azure OpenAI, Bedrock의 지역, 시간대, 호출량, billing spike가 더 직접적인 후속 사용 흔적일 수 있다.

대응

litellm을 최소 1.83.7 이상으로 올린다. 이 버전은 combined_view token lookup을 PostgreSQL placeholder 기반 parameterized query로 바꾸고, 관련 deprecated-token lookup도 Prisma typed API 경로로 정리한다.

즉시 올릴 수 없으면 임시로 general_settings 아래 disable_error_logs: true를 설정한다.

general_settings:
  disable_error_logs: true

이 설정은 공개 advisory의 workaround지만 patch 대체물이 아니다. error-handling path를 줄이는 조치이며, Python assert가 제거된 런타임 구성까지 포괄하는 근본 수정은 1.83.7 이상 배포다.

취약 기간에 노출된 proxy는 credential 작업을 별도 트랙으로 처리한다.

LiteLLM master key와 virtual key를 폐기하고 재발급한다.
litellm_credentials에 저장된 provider API key와 cloud credential을 회전한다.
litellm_config나 환경 변수에 DB DSN, callback secret, cache credential이 있었다면 같이 교체한다.
provider별 usage와 billing을 취약 기간 이후로 재검토한다.
LiteLLM DB 계정이 PostgreSQL superuser 또는 과도한 권한을 가진 경우 최소 권한으로 줄인다.

네트워크 노출도 줄인다. LiteLLM proxy는 OpenAI-compatible API처럼 보여 공개 API gateway 뒤에 놓이기 쉽다. 운영 client CIDR, VPN, mTLS reverse proxy, service mesh, private endpoint 뒤로 이동시키고, 외부 호출이 필요하면 WAF보다 인증과 접근제어를 먼저 강제한다.