공개된 LiteLLM 게이트웨이 10개 중 거의 1개꼴로 예시 관리자 키 "sk-1234" 수락

한 줄 요약

AI 모델 요청을 중계하는 오픈소스 소프트웨어 LiteLLM에서 심각한 보안 문제가 연달아 발견됐습니다. 2월 조사에서 인터넷에 노출된 LiteLLM 서버 약 10개 중 1개가 설정 안내서에 예시로 실린 기본 관리자 키(sk-1234)를 그대로 사용하고 있었으며, 이 키를 알면 서버에 저장된 모든 AI 서비스 API 키와 클라우드 계정 자격증명까지 탈취할 수 있습니다. 미국 사이버보안 당국(CISA)은 이미 두 개의 취약점을 실제 악용이 확인된 목록(KEV)에 등재했고, 실제 공격에서 암호화폐 채굴기 설치와 데이터베이스 탈취가 확인됐습니다. LiteLLM을 사용 중이라면 즉시 기본 키를 변경하고 버전 1.84.0 이상으로 업그레이드해야 합니다.

사건

인터넷에 노출된 LiteLLM AI 게이트웨이 서버 약 10%(294/3,074개)가 설정 안내서의 예시 관리자 키 sk-1234를 그대로 사용 중이었으며, 별도 키 미설정 서버 191개는 어떤 키든 수락했다. 동시에 인증 우회·명령 실행·샌드박스 탈출 등 4개의 CVE가 발견되었고, 이 중 두 개(CVE-2026-42271, CVE-2026-59822)는 CISA KEV에 등재됐다.

영향

관리자 키를 확보한 공격자는 서버에 저장된 모든 AI 공급자 API 키를 읽고, 클라우드 IAM 자격증명을 탈취하며, 게이트웨이 컨테이너 내에서 root 권한으로 코드를 실행할 수 있다. 실제 공격에서 암호화폐 채굴기 설치와 PostgreSQL 데이터베이스 내 모델·가상키 레코드 탈취가 확인됐다. 탈취한 API 키로 피해자 비용으로 AI 모델을 무단 사용하는 'LLMjacking' 피해도 발생한다.

원인

설정 가이드의 예시 키(sk-1234)를 운영 환경에서 교체하지 않은 운영 실수, 버전 1.82.0-stable 이전에는 마스터 키 미설정 시 모든 요청에 전체 관리자 권한이 부여되는 설계, 패스스루 엔드포인트가 내부 IP·localhost·클라우드 메타데이터 주소를 차단하지 않는 구조, 커스텀 코드 가드레일 엔드포인트의 샌드박스 적용 누락이 복합적으로 작용했다.

대응

CVE-2026-59821과 CVE-2026-40217은 각각 1.82.0-stable, 1.83.10에서 수정됐으며, CVE-2026-42271은 1.83.7, CVE-2026-59822는 1.84.0에서 패치됐다. CISA는 CVE-2026-59822와 CVE-2026-42271을 KEV에 등재했고, 연방 민간기관에 9월 16일까지 조치를 요구했다. Microsoft는 공격 사례를 분석해 'AI 게이트웨이를 Tier-0 시크릿 저장소로 취급하라'고 권고했다.

실무 포인트

LiteLLM을 사용 중이라면 즉시 마스터 키를 sk-1234에서 무작위 긴 값으로 교체(업그레이드 불필요)하고, 버전 1.84.0 이상으로 업그레이드해야 한다. 업그레이드 전에는 /mcp/, /guardrails/test_custom_code 등 위험 엔드포인트를 리버스 프록시에서 차단하고, 컨테이너의 아웃바운드 네트워크와 클라우드 IAM 권한을 최소화해야 한다. 공격자가 접근했을 가능성이 있다면 가드레일 목록 확인, 프로세스 재시작, 모든 자격증명 교체가 필요하다.

본문

Wiz Research가 2월에 스캔한 인터넷 연결 LiteLLM 서버 10개 중 거의 1개꼴로 sk-1234를 허용했습니다. 이 값은 LiteLLM 자체 설정 가이드에 실린 예시 관리자 키입니다.

LiteLLM은 오픈소스 AI 게이트웨이로, 기업이 자사 애플리케이션과 유료 모델 공급자 사이에 두는 소프트웨어입니다. 해당 키는 게이트웨이의 관리자 자격증명입니다.

이 키를 가진 사람은 서버에 저장된 모든 모델 공급자의 API 키를 읽을 수 있습니다. Wiz의 테스트에서는 게이트웨이가 실행되는 머신의 클라우드 IAM 자격증명에도 접근할 수 있었습니다.

키 변경에는 업그레이드가 필요 없으며, 이것만으로도 Wiz 보고서에서 키 보유를 전제로 하는 모든 공격 경로를 차단할 수 있습니다.

수치의 근거

Wiz는 단일 스캔을 실시했습니다. 2월에 Shodan에서 3,074개의 LiteLLM 게이트웨이를 발견했고, 그 중 294개가 해당 키를 수락했습니다.

294개 중 191개는 키 자체가 설정되어 있지 않아 어떤 값이든 수락했을 것입니다. 나머지는 설정 가이드의 값을 그대로 남겨둔 경우였습니다.

8월에 실시한 두 번째 스캔에서는 85,000개 이상의 인스턴스가 발견됐지만, Wiz는 대부분이 허니팟이나 테스트 시스템으로 보인다고 밝혀 두 수치는 단순 비교할 수 없습니다. 현재 시점의 수치는 없습니다.

9월 9일 기준으로 LiteLLM 설정 가이드는 여전히 sk-1234를 사용하고 있으며, 실제 운영 전에 긴 무작위 값으로 교체하라는 주석이 달려 있습니다.

키 하나가 이토록 중요한 이유

마스터 키는 두 가지 역할을 동시에 수행하며, 바로 이 점이 기본값을 심각한 문제로 만듭니다. 마스터 키는 관리자 자격증명이자 인증을 활성화하는 스위치입니다.

버전 1.82.0-stable 이전에는 마스터 키 없이 시작된 게이트웨이가 들어오는 모든 요청에 전체 관리자 권한을 부여했습니다.

이런 서버의 관리자는 상당히 많은 것에 접근할 수 있습니다. 게이트웨이는 라우팅하는 모든 공급자의 API 키를 보유할 수 있고, 통과하는 모든 프롬프트와 응답을 볼 수 있으며, MCP(Model Context Protocol)를 통해 내부 도구에 연결할 수 있습니다.

또한 대개 배포된 워크로드의 클라우드 권한으로 실행됩니다. 공급자 키만 탈취해도 공격자가 피해자 비용으로 모델 워크로드를 실행할 수 있으며, 이를 LLMjacking이라고 합니다.

키가 클라우드 계정에 도달하는 경로

LiteLLM은 관리자가 패스스루 엔드포인트를 생성할 수 있게 합니다. 이는 관리자가 지정한 임의의 URL로 요청을 전달하는 경로입니다.

대상 URL은 사설 주소 범위, localhost, 또는 클라우드 메타데이터 주소에 대한 검사를 거치지 않습니다. 따라서 관리자는 인스턴스 메타데이터 서비스를 가리키는 경로를 설정하고 반환되는 IAM 자격증명을 읽을 수 있습니다.

IMDSv2로 전환해도 이를 막을 수 없습니다. LiteLLM 문서에는 x-pass- 접두사와 함께 전송된 헤더가 접두사가 제거된 채 대상으로 전달된다고 나와 있으며, Wiz는 이를 이용해 IMDSv2에 필요한 헤더를 전송했습니다.

실제 배포 환경에서 이를 악용한 사례는 보고되지 않았습니다. 이는 시연이며, 먼저 관리자 접근이 필요합니다.

Wiz는 이 기능이 의도대로 작동하는 것으로 볼 수 있다고 밝혔는데, LiteLLM의 위협 모델이 관리자를 신뢰할 수 있는 존재로 간주하기 때문입니다. CVE도 없고 수정 사항도 없습니다.

프로젝트 측도 같은 맥락에서 이야기합니다. 공개된 보안 정책에는 마스터 키 미설정과 같은 설정 실수가 필요한 공격을 "명시적으로 범위 밖"으로 규정하고 취약점으로 다루지 않는다고 명시되어 있습니다.

가드레일 결함과 심각도 논란

Wiz 보고서에 포함된 코드 실행 결함은 CVE-2026-59821이며, 연구자와 유지관리자는 이를 매우 다르게 설명합니다.

Wiz는 이를 인증 후 root 수준의 코드 실행이라고 부르며, 게이트웨이 컨테이너 내에서 uid=0(root)를 반환하는 테스트를 보여줍니다. 동일한 CVE에 대한 LiteLLM 권고문은 이를 Low(CVSS 2.1)로 평가하며, 높은 권한 계정이 필요한 결함으로 설명합니다.

둘 다 동일한 동작을 설명합니다. 1.82.0-stable 이전에는 커스텀 코드 가드레일을 생성·업데이트하는 엔드포인트가 테스트 엔드포인트에 적용된 샌드박스와 패턴 검사를 건너뛰었기 때문에, 해당 엔드포인트에 접근할 수 있는 사람이라면 누구든 컨테이너 내에서 실행되는 Python 코드를 제출할 수 있었습니다.

권고문에는 마스터 키가 없는 배포에서 호출자를 프록시 관리자로 처리했으며, 이것이 해당 엔드포인트에 접근 가능하게 한 원인이라고 덧붙였습니다.

Wiz 보고서에는 1.82.0 이후 기본 키를 가진 공격자가 샌드박스 내에서만 코드를 실행할 수 있다고 나와 있습니다. LiteLLM 자체 기록은 모든 릴리스에서 이를 지지하지 않습니다.

5월에 공개된 별도의 권고문 CVE-2026-40217에 따르면, 프록시 프로세스 내에서 코드를 실행하는 바이트코드 기법으로 샌드박스를 탈출할 수 있었으며, 기본 Docker 이미지에서 프록시가 root로 실행된다고 권고문은 지적합니다.

이 취약점은 1.81.8 이상 1.83.10 미만 버전에 영향을 미치며, 엔드포인트에 접근하려면 proxy-admin 자격증명이 필요합니다. 마스터 키가 바로 그 자격증명입니다.

Wiz가 보고한 두 결함 모두 9월 9일 보고서가 나오기 수개월 전인 2월과 4월에 수정되었으며, CVE는 7월에 공개됐습니다.

별개 사안: 이미 악용되고 있는 LiteLLM 취약점들

이것들은 더 오래된 문제이며, 위에서 설명한 클라우드 자격증명 탈취 경로와는 다릅니다. 동일한 제품에 영향을 미치고 혼동하기 쉬우므로 여기에 함께 정리합니다.

CISA는 9월 2일 LiteLLM 취약점 하나를 Known Exploited Vulnerabilities(실제 악용 확인) 목록에 추가했습니다. 역시 Wiz가 발견한 CVE-2026-59822(CVSS 점수: 8.8)는 인증되지 않은 공격자가 한 글자짜리 Bearer 토큰을 포함한 모든 Bearer 토큰으로 유효한 MCP 세션을 열 수 있게 합니다. 연방 민간기관은 9월 16일까지 조치를 완료해야 합니다.

Wiz는 7월 7일부터 자체 허니팟에서 이 취약점을 악용하는 시도를 관찰했으며, 단일 문자 토큰으로 모델 목록 엔드포인트를 탐색하는 요청 형태였습니다. 다른 활용 사례는 보고되지 않았습니다.

이 취약점은 위에서 언급한 코드 실행이나 자격증명 탈취 경로에는 도달하지 않습니다. Wiz는 이 취약점이 "MCP 서버 접근만 허용한다"고 밝혔습니다. 실제로 접근 가능한 범위는 조직이 어떤 도구 서버를 연결해 두었는지에 따라 다릅니다.

공격자가 코드를 실행하는 데 사용한 LiteLLM 취약점은 별개입니다. CVE-2026-42271(CVSS 점수: 8.7)은 인증된 사용자라면 누구든 두 개의 MCP 테스트 엔드포인트를 통해 호스트에서 명령을 실행할 수 있게 했으며, Horizon3.ai는 6월에 이것이 Starlette 호스트 헤더 취약점인 CVE-2026-48710과 연계하면 자격증명 없이도 동일한 공격이 가능하다고 보고했습니다.

Wiz의 허니팟은 이 취약점을 이용한 암호화폐 채굴기 설치 시도를 기록했습니다.

Microsoft는 8월에 공격자들이 LiteLLM 게이트웨이 프로세스 내에서 명령을 실행하고, 컨테이너의 환경 변수에서 마스터 키·공급자 키·데이터베이스 연결 문자열을 읽은 뒤, 그 문자열로 PostgreSQL 데이터베이스에 접근해 LiteLLM의 모델 및 가상키 테이블에서 레코드를 복사한 사례를 분석해 발표했습니다.

Microsoft는 공격자들이 노출된 게이트웨이를 통해 접근했다고 높은 신뢰도로 평가하며, 진입 지점이 CVE-2026-42271과 CVE-2026-48710 체인과 일치한다고 밝혔습니다. Microsoft는 "AI 게이트웨이를 Tier-0 시크릿 저장소로 취급하라"고 권고했습니다.

지금 해야 할 일

1.84.0 이상으로 업그레이드하면 표의 모든 취약점이 해결됩니다. 버전 범위는 각 권고문에 명시된 대로입니다.

취약점 / 허용되는 행위 / 영향 버전 / 수정 버전 — CVE-2026-59822, MCP 인증 우회: 모든 Bearer 토큰으로 MCP 세션을 열어 해당 인스턴스에 구성된 MCP 도구에 접근 / 1.84.0 미만 / 1.84.0 — CVE-2026-42271, MCP 테스트 엔드포인트 명령 실행: 인증된 사용자가 호스트에서 명령 실행 / 1.74.2 이상 1.83.7 미만 / 1.83.7 — CVE-2026-59821, 커스텀 코드 가드레일 검사 우회: 게이트웨이 컨테이너 내 코드 실행 / 1.82.0-stable 미만 / 1.82.0-stable — CVE-2026-40217, 가드레일 샌드박스 탈출: 기본 컨테이너 이미지에서 root로 코드 실행 / 1.81.8 이상 1.83.10 미만 / 1.83.10 (단, 권고문 본문에는 1.83.11로 기재)

마스터 키를 sk-1234에서 긴 무작위 값으로 교체합니다. 업그레이드는 필요 없습니다. 먼저 별도의 솔트 키가 설정되어 있는지 확인하세요. 교체 절차가 다르며 잘못된 키를 사용하면 저장된 자격증명을 읽을 수 없게 될 수 있습니다.
1.84.0 이상으로 업그레이드합니다. 이 릴리스는 표의 모든 취약점의 수정 버전보다 상위입니다.
당장 업그레이드할 수 없다면, 리버스 프록시 또는 API 게이트웨이에서 /mcp/와 두 개의 MCP 테스트 엔드포인트인 POST /mcp-rest/test/connection 및 POST /mcp-rest/test/tools/list를 차단합니다.
추가로 차단할 항목: POST /guardrails/test_custom_code를 차단하고, POST /guardrails와 PUT /guardrails/{guardrail_id}는 관리자로만 제한합니다. 이는 LiteLLM 자체 권고문의 임시 대응 방법입니다.
게이트웨이의 패스스루 엔드포인트를 검토하고, 컨테이너의 아웃바운드 네트워크 접근을 제한하며, 워크로드에 최소한의 클라우드 IAM 역할만 부여합니다.
공격자가 접근했을 가능성이 있다면, 직접 생성하지 않은 가드레일 항목을 검토하고 프로세스를 재시작해 메모리에 남아 있는 코드를 제거한 뒤, 공급자 키·마스터 키·데이터베이스 자격증명을 교체합니다. 업그레이드해도 공격자가 등록한 가드레일이나 추가한 SSH 키는 제거되지 않습니다.