LiteLLM SQL 인젝션 취약점 (CVE-2026-42208)

1. 취약점

[사진 1] CVE-2026-42208 [1]

- 프록시 API 키 확인 시 사용되는 데이터베이스 쿼리에서 키 값이 쿼리 텍스트에 직접 삽입되어 발생하는 SQL 인젝션 취약점 (CVSS: 9.8)

> 취약점 공개 36시간 만에 악용 사례 발생 [2]

> 자격 증명 없이도 모든 LLM API 경로(/v1/chat/completions , /v1/completions , /v1/messages , /v1/embeddings)를 통해 악용 가능

 

- get_data() 함수가 table_name과 query_type이 각각 combined_view, find_unique로 지정되어 호출될 경우 SQL Query를 실행 [3]

> 이때, 매개변수 바인딩 없이 사용자 제어 값 token을 쿼리 텍스트에 직접 삽입하여 취약점이 발생

litellm/proxy/utils.py [4]

sql_query = f"""
   SELECT v.*, t.spend AS team_spend, t.max_budget AS team_max_budget, ... 
   FROM "LiteLLM_VerificationToken" AS v 
   LEFT JOIN "LiteLLM_TeamTable" AS t ON v.team_id = t.team_id 
   LEFT JOIN "LiteLLM_TeamMembership" AS tm ON v.team_id = tm.team_id AND tm.user_id = v.user_id 
   LEFT JOIN "LiteLLM_BudgetTable" AS b ON v.budget_id = b.budget_id 
   LEFT JOIN "LiteLLM_OrganizationTable" AS o ON v.organization_id = o.organization_id 
   LEFT JOIN "LiteLLM_BudgetTable" AS b2 ON o.budget_id = b2.budget_id 
   WHERE v.token = '{token}' 
"""

response = await self._query_first_with_cached_plan_fallback(sql_query)

 

- 시스템으로 들어오는 모든 API 키가 올바른 형식(sk-로 시작)인지 assert문으로 검증

litellm/proxy/auth/user_api_key_auth.py [6]

assert api_key.startswith(
	"sk-"
), "LiteLLM Virtual Key expected. Received={}, expected to start with 'sk-'.".format(
	_masked_key
) # prevent token hashes from being used
...
	if api_key.startswith("sk-"):
		api_key = hash_token(token=api_key)
...
try:
	valid_token = await get_key_object(
	hashed_token=api_key,
	prisma_client=prisma_client,
	user_api_key_cache=user_api_key_cache,
	parent_otel_span=parent_otel_span,
	proxy_logging_obj=proxy_logging_obj,
	)
...

 

> 그러나, 해당 검증을 우회하는 2가지 경우가 존재

구분	설명
경우 1	- Python 최적화 옵션(-O 또는 환경변수 PYTHONOPTIMIZE를 1로 설정)을 사용 > 최적화 옵션일 경우 assert 문과 __debug__ 변수가 재거되므로, 조작된 token을 get_key_object()를 통해 SQL 싱크로 직접 전달 [7][8]
경우 2	- assert문이 정상 작동하여 AssertionError를 발생 > 발생한 에러를 처리 및 로깅하는 후속 과정에서 전달된 원시 토큰이 get_key_object()를 통해 SQL 싱크로 전달

 

- PoC [9][10]

$ time curl -X POST https://TARGET/v1/chat/completions \ 
 -H "Authorization: Bearer ' OR (SELECT pg_sleep(6)) IS NULL --" \ 
 -H "Content-Type: application/json" \ 
 -d '{"model":"x","messages":[{"role":"user","content":"x"}]}' 
 
...omitted for brevity... 
0.00s user 0.01s system 0% cpu 6.058 total

3. 대응방안

- 벤더사 제공 업데이트 적용 [11]

> token 값을 직접 사용하지 않고 매개변수 바인딩을 통해 사용

> 즉각 업데이트 적용이 불가할 경우 general_settings 하위에 disable_error_logs: true 설정해 취약한 쿼리에 도달하는 경로 차단

취약점	제품명	영향받는 버전	해결 버전
CVE-2026-42208	LiteLLM	>=1.81.16, <1.83.7	>=1.83.7

 

- LiteLLM 인스턴스의 인터넷 노출 여부 점검

- LiteLLM이 관리하는 모든 API 키 및 IAM 자격증명 교체

- 비정상적인 인증 헤더가 있는지 로그 모니터링

4. 참고

[1] https://nvd.nist.gov/vuln/detail/CVE-2026-42208
[2] https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure
[3] https://bishopfox.com/blog/cve-2026-42208-pre-authentication-sql-injection-in-litellm-proxy
[4] https://github.com/BerriAI/litellm/blob/4d2fab49a7b947f329288c696101d1a678e49ede/litellm/proxy/utils.py#L2812
[5] https://github.com/BerriAI/litellm/blob/4d2fab49a7b947f329288c696101d1a678e49ede/litellm/proxy/utils.py#L4378
[6] https://github.com/BerriAI/litellm/blob/4d2fab49a7b947f329288c696101d1a678e49ede/litellm/proxy/auth/user_api_key_auth.py#L997
[7] https://docs.python.org/ko/3.8/using/cmdline.html#cmdoption-o
[8] https://docs.python.org/ko/3.8/using/cmdline.html#envvar-PYTHONOPTIMIZE
[9] https://github.com/imjdl/CVE-2026-42208_lab
[10] https://github.com/0xBlackash/CVE-2026-42208
[11] https://docs.litellm.ai/blog/cve-2026-42208-litellm-proxy-sql-injection
[12] https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc
[13] https://www.miggo.io/post/rce-in-litellm-cve-2026-42208-how-two-vulnerabilities-and-36-hours-turn-an-ai-gateway-into-a-backdoor