Wiz: 노출된 LiteLLM 게이트웨이 중 거의 10곳 중 1곳이 예시 관리자 키 sk-1234를 허용한다

2026년 9월 9일 Wiz Research는 애플리케이션과 애플리케이션이 비용을 지불하는 모델 제공자 사이에 위치한 오픈소스 AI 게이트웨이 LiteLLM에 관한 연구를 발표했으며, 공개 인터넷에서 접근할 수 있었던 LiteLLM 배포 3,074개 중 294개 — 9.6%, 거의 10개 중 1개 — 가 sk-1234, 프로젝트 자체 설치 문서에 인쇄된 예시 마스터 키를 받아들였거나 자격 증명이 전혀 필요하지 않았다고 보고했다. 그 문자열은 평범한 API 키가 아니다. LiteLLM에서 그것은 관리자 자격 증명이자 인증을 켜는 스위치이므로, 그것을 제시하는 사람은 게이트웨이에 저장된 모든 모델 제공자 키를 읽고, 게이트웨이를 통과하는 모든 프롬프트와 완성 결과를 지켜보며, Model Context Protocol을 통해 연결된 모든 도구 서버에 접근할 수 있다. Wiz의 공동 저자 Amitai Cohen과 Yaara Shriki는 그 접근 권한을 루트 수준 코드 실행과 호스트의 클라우드 IAM 자격 증명 탈취로 이어지게 했다. 이 설명은 Wiz의 보고서, LiteLLM 자체의 보안 권고문, 그리고 뒤이은 CISA Known Exploited Vulnerabilities 목록에 근거하며, AI 사고 아카이브는 이 기록을 인접 기록들과 함께 보관하고, 각 기록에는 자체 출처, 심각도 및 신뢰 등급이 있다.

기록에 담긴 날짜는 발행일 하나뿐이며, 그것은 발행일이다. 헤드라인의 근거가 된 스캔은 2026년 2월에 수행되었다. Wiz가 설명한 두 가지 코드 결함은 늦어도 5월 중순까지 수정판이 배포되었는데, 프로젝트 자체 기록에는 해당 릴리스가 3월과 5월로 기재되어 있다. CVE 식별자는 7월에 발급되었고, 카탈로그 등재는 9월에 이루어졌다. 보고서에 담긴 거의 모든 내용은 인쇄될 무렵 이미 오래된 것이었으며, 이는 이 보고서가 주장하는 바의 상당 부분을 차지한다.

{{1}}9.6%{{/1}}는 단일 스캔 결과이며, Wiz는 자사의 8월 후속 조사가 그것과 비교될 수 없다고 밝혔다.

측정은 단순하며, Wiz는 자사의 방식을 명확히 밝힌다: 2026년 2월 Shodan을 통해 발견된 인터넷에 노출된 LiteLLM 프록시 3,074개를 대상으로, 각각이 문서에 제시된 예시 키로 인증되는지 시험했다. 그중 294개가 인증에 성공했다. 이 그룹 안에서 191개는 마스터 키가 전혀 설정되어 있지 않아 제공되는 아무 문자열이나 받아들였을 것이고, 나머지는 설치 가이드의 자리 표시자를 그대로 남겨두었다. 두 가지 실패 유형 모두 소프트웨어 버그를 필요로 하지 않는다. 둘 다 게이트웨이의 주소와 프로젝트 자체의 README에 인쇄된 값만 있으면 된다.

이는 또한 단일 공급업체의 스캔 결과이기도 하다. Wiz의 수치는 9월 10일 클라우드 보안 연합(Cloud Security Alliance)의 AI 안전 이니셔티브와 같은 날 The Hacker News에 의해 반복 보도되었지만, 두 매체 모두 출처를 밝혀 인용했을 뿐이며, 이 기사 작성 과정에서 3,074라는 수치에 대한 독립적인 재현 사례는 확인되지 않았다. Wiz는 2026년 8월에 두 번째 스캔을 실시해 85,000개 이상의 인스턴스를 발견했는데, 이는 2월 집계의 약 27배에 해당한다. 회사 측은 그중 대부분이 허니팟이나 테스트 배포로 보이며 두 집계는 비교할 수 없다고 말한다. 현재의 노출 수치는 존재하지 않으며, 어떤 기사든 하나의 수치를 인용하고 있다면 그것은 2월 수치를 인용하는 것이다.

보고서에 나오는 또 하나의 수치는 스캔이 아니라 Wiz 자체의 텔레메트리입니다. 이 회사는 자사가 관찰하는 클라우드 환경의 약 3분의 1에 LiteLLM이 존재한다고 말합니다. 이는 자사 고객 기반에 대한 한 공급업체의 시각이므로 거리를 두고 받아들일 만하지만, 연구자들이 게이트웨이 구성 오류를 애플리케이션 문제가 아니라 클라우드 문제로 취급한 이유를 설명해 줍니다.

마스터 키는 관리자 자격 증명이자 인증을 켜는 스위치입니다.

LiteLLM의 설계는 하나의 비밀 값에 두 가지 역할을 부여합니다. 마스터 키는 관리자 요청을 인증하며, 마스터 키의 존재 자체가 인증을 가능하게 하는 요소입니다. 마스터 키도 없고 JWT나 OAuth2 구성도 없으면 프록시는 개방된 상태로 실행되어 모든 요청을 수락합니다. Wiz는 Anthropic의 Claude Code로 코드베이스를 살펴보며 사용자가 제어하는 입력을 받아 실행 컨텍스트로 전달하는 기능을 찾았고, 인증 핸들러는 Wiz가 표시한 세 가지 표면 중 하나였습니다.

v1.82.0-stable 이전에는 그 두 번째 작업의 결과가 오픈 프록시보다 더 심각했습니다. Wiz는 마스터 키가 설정되지 않은 경우 인증 핸들러가 들어오는 모든 요청에 PROXY_ADMIN 역할을 부여했으며, 따라서 인증되지 않은 호출자가 단순히 허용되는 데 그치지 않고 관리자로서 허용되었다는 사실을 발견했습니다. 보고서에서 인용된 풀 리퀘스트 #22095는 기본 역할을 INTERNAL_USER로 변경하고 가드레일 엔드포인트에 관리자 확인 절차를 추가했습니다.

게이트웨이에 대한 관리자 접근 권한은 좁은 특권이 아니다. 해당 인스턴스는 라우팅하는 모든 제공자에 대한 API 키를 보유하므로 LLMjacking, 즉 피해자의 비용으로 모델 워크로드를 실행하는 공격의 표적이 된다. 이는 프롬프트와 완료 결과를 본다. 또한 외부의 MCP 도구 서버로 연결되는데, 내부 배포에서는 이러한 서버에 이슈 트래커, 채팅, 데이터베이스, 배포 파이프라인이 포함될 가능성이 높다.

Wiz는 또한 해당 관리자 권한에서 호스트의 클라우드 아이덴티티로 이어지는 경로를 시연했습니다. LiteLLM을 사용하면 관리자가 모든 대상 URL에 대한 패스스루 경로를 등록할 수 있으며, 대상은 사설 주소 범위, localhost 또는 클라우드 메타데이터 주소에 대해 검사되지 않습니다. 경로를 인스턴스 메타데이터 서비스로 지정하면 워크로드가 실행되는 IAM 자격 증명이 반환됩니다. 일반적으로 별도로 획득한 세션 토큰을 요구하여 이러한 종류의 요청 위조를 방지하는 IMDSv2로 메타데이터 서비스를 전환해도 도움이 되지 않습니다: LiteLLM은 접두사가 x-pass-인 모든 헤더를 접두사를 제거한 채 대상으로 전달하므로, 토큰 헤더를 몰래 통과시킬 수 있습니다. Wiz는 이 기능이 관리자를 신뢰하는 위협 모델에서 의도대로 작동하는 것으로 볼 수 있으며, 따라서 CVE도 수정도 없다고 말합니다.

그 마지막 문단은 관찰된 공격이 아니라 시연이다. 9월 10일 이 연구를 보도한 Hacker News는 어떤 출처도 실제 배포 환경을 대상으로 누군가 이를 실행했다고 보고하지 않으며, 먼저 관리자 접근 권한이 필요하다고 밝힌다. Wiz의 설명 방식도 같다. 패스스루는 설계 속성이며, 관리자 자격 증명이 문서에 나온 문자열일 때에만 취약점이 된다.

8.8과 2.1은 서로 다른 출발점에서 같은 체인을 평가하고 있다.

두 CVE가 기술적 발견 사항을 담고 있으며, 공개된 점수는 사실상 최대한 벌어져 있다.

CVE-2026-59822은 MCP 인증 우회 취약점이며, LiteLLM의 보안 권고에서는 이를 High로 평가하고 CVSS 4.0 기준 8.8점으로 책정했습니다. 권한 필요 없음, 사용자 상호작용 없음, 공격 요구 사항 없음입니다. MCP 엔드포인트에는 자체 인증 핸들러가 있으며, LiteLLM 키 또는 업스트림 도구 서버로 향하는 OAuth2 토큰 중 하나를 허용하도록 만들어졌습니다. 토큰이 LiteLLM 검증을 통과하지 못하면 핸들러가 401을 잡아 요청을 거부하는 대신 빈 인증 객체로 대체했습니다. 따라서 어떤 Bearer 토큰이든, 단 한 글자라도 유효한 MCP 세션을 생성했습니다. Wiz의 개념 증명은 한 글자짜리 Bearer 토큰을 보내고 세션 식별자를 돌려받습니다. 이 결함은 1.84.0에서 수정되었습니다.

CVE-2026-59821은 가드레일 결함이며, 같은 프로젝트의 권고문은 이를 Low, 2.1로 평가합니다. 높은 권한이 필요하고 공격 요구사항이 존재합니다. 사용자 정의 코드 가드레일 기능을 사용하면 관리자가 서버가 컴파일하고 실행하는 Python을 제출할 수 있습니다. 웹 UI의 테스트 엔드포인트는 코드를 금지 패턴 목록에 대해 검증하고 실행 전에 빌트인을 제거했습니다. 프로덕션 create 및 update 엔드포인트는 둘 다 하지 않았습니다. Python은 빌트인이 없으면 이를 다시 채우므로, 제출된 코드가 표준 라이브러리에 도달했습니다. Wiz의 개념 증명은 등록 시점에 — 어떤 모델 요청보다도 먼저 — 셸 명령을 실행하는 가드레일을 등록하고 명령의 출력을 차단 사유로 반환하는데, 해당 테스트에서는 root로 반환되었습니다. 이 결함은 v1.82.0-stable에서 수정되었습니다.

두 설명은 서로 양립 가능하며, 이를 조정하는 문장은 권고문 자체에 있습니다. LiteLLM은 마스터 키가 구성되지 않은 배포에서는 호출자가 프록시 관리자로 취급될 수 있다고 언급하는데, 바로 이것이 가드레일 엔드포인트에 접근할 수 있게 된 이유입니다. A 2.1은 권한 있는 사용자를 가정합니다. Wiz의 체인은 기본 키로 인해 모든 호출자가 권한을 갖게 될 때 벌어지는 일입니다. 어느 점수도 자신의 출발 전제에 대해 틀리지 않으며, 그 전제가 얼마나 자주 별도 권한 없이 성립하는지에 대해서만 서로 다릅니다.

Wiz의 주장, 즉 1.82.0 이후 기본 키를 보유한 공격자는 샌드박스 내부에서만 코드를 실행할 수 있다는 주장에는 한 가지 주의할 점이 있습니다. Hacker News는 별도의 2026년 5월 권고문인 CVE-2026-40217을 지목하는데, 이 권고문은 1.81.8부터 1.83.10 미만 버전에서 바이트코드 기법을 통해 해당 샌드박스를 탈출하는 방법을 설명하며, 그 대상은 권고문에 따르면 기본 컨테이너 이미지에서 root로 실행되는 프록시 프로세스 내부입니다. 그 엔드포인트에 도달하려면 프록시 관리자 자격 증명이 필요하며, 바로 그것이 마스터 키입니다.

8.8도 보편적이지 않다. 클라우드 보안 연합(Cloud Security Alliance)의 연구 노트는 GitLab의 권고문이 동일한 취약점에 대해 기본 점수 8.2를 제시하며 두 방법론 중 어느 쪽이 맞는지 판정하지 않고, 두 점수 모두 ‘높음’ 범위에 있다는 점만 언급한다고 지적한다. 기록상의 심각도 ‘높음’은 어떤 숫자가 사용되는지에 좌우되지 않는다.

CVE 하나가 실제 공격에 악용되었으며, 기본 키 노출 건에는 피해자로 지목된 대상이 없습니다

CISA는 2026년 9월 2일 CVE-2026-59822를 Known Exploited Vulnerabilities 카탈로그에 추가하고 연방 민간 기관을 대상으로 2026년 9월 16일까지의 해결 기한을 설정했다. 카탈로그 항목에는 CWE-287과 CWE-306, 즉 부적절한 인증과 인증 누락이 포함되어 있다. Cloud Security Alliance의 노트는 업계 추적기들이 이 취약점을 해당 목록에서 최초의 MCP 특화 결함이라고 설명해 왔다고 보고한다. Wiz는 자사가 관찰한 익스플로잇을 공개했다. 2026년 7월 7일부터 Wiz의 허니팟은 한 글자짜리 베어러 토큰을 포함한 요청이 모델 목록 엔드포인트를 탐색하는 것을 기록했으며, Wiz는 이 결함의 다른 사용 정황은 설명하지 않는다.

기본 키에 대해서는 이에 비견할 만한 사례가 존재하지 않습니다. 피해자는 지목되지 않았고, sk-1234를 통해 장악된 것으로 확인된 게이트웨이도 없으며, 294개 호스트가 사용되고 있음을 보여 주는 텔레메트리도 없습니다. 아카이브 항목은 실제 피해를 기록하지 않는데, 이는 메커니즘에 관한 진술이라기보다 증거에 관한 진술입니다: 노출은 측정되었지만, 사용되는 것이 목격된 것은 아닙니다.

다른 두 항목은 종종 이것들과 함께 분류되지만 같은 것은 아니다. 두 개의 MCP 테스트 엔드포인트를 통한 명령 실행인 CVE-2026-42271은 공격자들이 실제로 코드를 실행하는 데 사용한 LiteLLM 취약점이다. Wiz의 허니팟은 그것이 암호화폐 채굴기를 설치하는 것을 기록했다. Microsoft가 공개한 2026년 8월 사례에서는 침입자가 게이트웨이 컨테이너의 환경 변수를 읽고 마스터 키, 공급자 키, 데이터베이스 연결 문자열을 복구한 뒤 LiteLLM의 모델 및 가상 키 테이블에서 레코드를 복사했는데, 이는 새로운 침입 경로라기보다 침해된 게이트웨이의 가치가 얼마인지를 보여준다. The Hacker News는 Microsoft가 진입점을 CVE-2026-42271 체인으로 평가한다고 보도했다.

유지 관리자들의 입장은 마스터 키가 없는 것은 취약점이 아니라 설정 실수라는 것입니다.

LiteLLM의 보안 정책은 명확합니다. 이 정책은 범위 밖 이슈 중 "설정 시 오구성(예: 프록시 구성에서 master_key를 설정하지 않음)이 필요한 공격"을 나열하며, 이러한 문제는 명시적으로 범위에 포함되지 않고 취약한 것으로 간주되지 않는다고 명시합니다. Wiz는 패스스루 동작을 두고 논란의 여지는 있지만 의도된 대로 작동하는 것이라고 표현하면서 다른 방향에서 양립 가능한 결론에 도달합니다.

그 입장은 공개적으로 검증되었다. 2026년 8월 15일 한 연구자가 GitHub 이슈 #37054를 제출하여, LITELLM_MASTER_KEY가 설정되지 않은 프록시가 어떤 키 값이든 인증하며 배포되는 docker-compose 파일에는 해당 키가 설정되어 있지 않다고 보고했다. 이슈는 30분 후 닫혔고, 유일한 댓글은 동일한 계정이 작성한 것이다. 그 댓글은 보고가 공개 이슈가 아닌 비공개 취약점 보고를 통해 이루어져야 한다는 보안 정책의 지침을 인용하고, 공개적으로 제출한 점을 사과하며, 전체 보고서는 대신 권고 경로를 통해 제출 중이라고 밝혔다. 스레드에는 유지관리자의 답변이 나타나지 않으므로, 기록상으로는 프로젝트가 그 보고에 응답한 것이 아니라 보고자가 공개 보고를 철회한 것으로 나타난다. 비공개 제출이 어떻게 되었는지는 공개적으로 기록된 바가 없다.

이 기사에서는 9월 보고서에 대한 해당 입장을 옹호하거나 수정하는 BerriAI의 공개 성명을 찾을 수 없었다. 회사의 가시적인 대응은 산문이 아니라 릴리스 노트와 구성 파일에 나타나 있다.

단속은 보고서 이후 24일째인 10월 3일에 도착했다

두 코드 결함은 보고서보다 훨씬 이전에 수정되었다. Wiz의 공개 타임라인에는 2026년 2월 18일에 보고되어 2월 25일 v1.82.0에서 수정된 가드레일 코드 실행, 4월 25일 v1.84.0에서 수정된 MCP 우회, 7월 7일에 관찰된 악용, 7월 8일에 게시된 CVE 식별자, 9월 2일의 카탈로그 등재가 기록되어 있다. 릴리스 아티팩트에는 수정보다 더 늦은 날짜가 찍혀 있다. 패키지 인덱스에는 v1.82.0이 2026년 3월 1일, v1.84.0이 5월 14일로 표시되는데, 이는 각 수정이 반영된 시점이 아니라 설치 가능해진 시점을 나타낸다. 자사 릴리스 기록 두 건은 동일한 수정에 해당 타임라인보다 늦은 날짜를 부여한다. GitHub의 v1.82.0-stable 릴리스에는 2026년 3월 11일이, PyPI의 1.82.0 패키지에는 3월 1일이 적혀 있으며, v1.84.0은 두 곳 모두 2026년 5월 14일로 날짜가 표시된다. 공개된 어떤 것도 이 격차를 설명하지 않으며, 그 모든 날짜가 9월 보고서보다 몇 달 앞서기 때문에 논증에는 중요하지 않다. 두 GitHub 권고문은 또 하나의 날짜를 추가한다. 즉, 이들은 2026년 6월 30일에 게시되었으며, 이는 Wiz가 7월 8일에 나갔다고 말하는 CVE 식별자보다 3주 앞선다.

그 릴리스들 중 어느 것도 해결하지 못한 것은 기본값이었다. Wiz는 9월 9일 기준으로 Docker Compose나 pip install을 통해 LiteLLM을 설치할 때 마스터 키가 여전히 sk-1234로 설정되어 있다고 보고했으며, The Hacker News는 그날까지도 설정 가이드가 여전히 해당 값을 사용하고 있음을 확인했다. 변경은 2026년 10월 3일 Python Package Index에 업로드된 v1.104.0과 함께 이루어졌으며, 해당 릴리스 노트는 이를 호환성을 깨뜨리는 변경으로 명시한다. 이제 프록시는 마스터 키가 설정되지 않았거나 비어 있거나 공개적으로 알려진 경우 시작을 거부하며, 시작 오류에 잘못된 값의 출처를 명시하고 안전한 키를 생성하는 명령을 출력한다. 함께 제공되는 항목에는 배포되는 구성 및 예시에서 공개적으로 알려진 취약한 마스터 키 값을 더 이상 제시하지 않도록 하는 변경이 기록되어 있으며, 프로젝트의 메인 브랜치에 있는 docker-compose 파일은 더 이상 키를 전혀 설정하지 않는다.

그것이 지켜둘 만한 순서다. 코드는 봄에 패치되었다. 그 패치들을 불충분하게 만든 값은 10월까지 설치 지침에 남아 있었고, 그제서야 소프트웨어가 그 값을 거부하기 시작했다. 두 수정 중 어느 것도 다른 하나가 기다릴 필요가 없었다.

변하지 않은 것은 인스턴스 메타데이터 서비스로 향하는 패스스루 경로입니다. 이 경로에는 여전히 CVE도, 수정 사항도 없습니다. 프로젝트가 관리자를 신뢰된 존재로 취급하기 때문입니다. 따라서 Wiz의 해결 목록은 대부분 운영자 작업입니다. 강력하고 고유한 마스터 키, 등록된 가드레일을 검토한 뒤 메모리에 유지된 코드를 지우기 위한 프로세스 재시작, 컨테이너 이그레스가 제한된 패스스루 엔드포인트 감사, 최소 권한 IAM 역할이 그것입니다. 이 네 가지 중 어느 것도 업그레이드만으로는 해결되지 않습니다.

기록이 입증하지 못하는 것

• 3,074개 호스트 스캔을 독립적으로 재현한 사례는 발견되지 않았습니다. 9.6%는 Wiz의 측정치이며, 이를 다룬 다른 모든 보도는 해당 수치를 출처를 밝혀 인용하는 방식으로 반복하고 있을 뿐입니다.

• 현재 노출 수치는 존재하지 않습니다. 8월 후속 조사에서는 85,000개 이상의 인스턴스가 발견되었는데, Wiz에 따르면 이는 대부분 허니팟이나 테스트 배포 환경이어서 2월 집계와 비교할 수 없습니다.

• 피해자는 없습니다. 기록 어디에도 기본 키를 통해 침해된 게이트웨이, 운영자 또는 클라우드 계정이 명시되어 있지 않으며, Wiz가 문서화한 공격은 sk-1234가 아니라 MCP 우회를 대상으로 한 것입니다.

• 294개 호스트가 사용되었다는 증거는 없습니다. 해당 스캔은 그 호스트들이 인증을 통과할 수 있는지를 테스트한 것으로, 누군가 실제로 그렇게 했다는 것을 보여주는 것보다 약한 주장입니다.

• 가드레일 결함에 대해 확정된 심각도는 없습니다. Wiz와 유지관리자들은 동일한 동작을 설명하면서도 매우 다르게 평가하는데, 그 차이는 각자가 공격자가 이미 보유하고 있다고 가정하는 권한에 관한 것입니다.

Wiz는 또한 이러한 유형의 노출을 탐지하는 기능을 판매하는 클라우드 보안 업체이며, 보고서는 자사 제품이 LiteLLM 배포와 취약한 버전, 섀도 인스턴스를 어떻게 식별하는지 다루는 섹션으로 마무리된다. 이는 교정 섹션을 읽는 데 필요한 맥락일 뿐, 유지관리자 자신의 권고문이 기술적 세부 사항을 뒷받침하는 측정 결과를 평가절하할 이유는 아니다.

LiteLLM 너머로 전달되는 기록의 일부는 두 날짜 사이의 간격이다. 그 취약점은 봄에 해결되었다. 그 취약점이 외부인에게 문제가 되도록 만든 기본값은 9월에도 설치 안내서에 여전히 인쇄되고 있었고, 소프트웨어는 10월에야 비로소 그 값을 거부하기 시작했다. 문자열을 변경한 운영자들은 그중 어느 것도 기다릴 필요가 없었다.