LiteLLM의 공개 배포 과정이 침해돼 악성 코드가 든 패키지와 격리 실행 환경을 담은 파일인 컨테이너 이미지가 일정 시간 배포됐다. 해당 시간에 이를 설치하거나 실행한 사용자는 환경을 정리하고, 호스트가 접근할 수 있던 비밀값을 바꿔야 한다. 기업 고객용 비공개 배포는 이번 영향 대상이 아니라고 회사는 밝혔다.
1. 오염된 패키지와 이미지의 범위
회사가 2026년 10월 21일 공개한 보고서에 따르면, PyPI의 LiteLLM 1.107.0 설치용 패키지인 wheel, 파이썬 설치용 압축 배포 파일 7개가 모두 오염됐다. 악성 코드는 시스템 접근을 증명하는 정보인 자격 증명을 훔치고, 네트워크 너머에서 코드를 실행하는 원격 코드 실행 도구를 불러오는 기능을 담고 있었다. 회사는 이전 버전은 안전하며 영향받은 배포물을 회수했다고 밝혔다.
컨테이너에서는 Docker Hub와 GHCR의 v1.107.0과 latest 태그가 영향을 받았다. 태그는 내려받을 이미지를 가리키는 이름표다.
main-latest와 main-stable 태그도 오염된 이미지를 가리켰다.
GHCR에서는 기본 이미지 외에 litellm-database와 litellm-non_root 이미지도 영향 대상이었다.
공식 GitHub의 1.107.0 소스 태그에는 악성 파일이 없었고, 오염된 배포물은 공격자가 통제한 별도 저장소에서 만들어졌다.
2. 저장소별 노출 시간으로 설치 이력 확인
회사 보고서의 시각은 모두 2026년 10월 21일 UTC, 세계 표준시 기준이다.
표: 저장소별 오염 배포물의 게시·제거 또는 확인 시각
조건: 2026년 10월 21일, 영향받은 패키지와 이미지 태그 기준
단위: UTC 시각
| 저장소 | 게시 시작 | 제거 또는 확인 시각 | 종료 시각의 의미 |
|---|---|---|---|
| PyPI | 11:39:51 | 13:23 | 해당 시각까지 문제 버전 제거 |
| Docker Hub | 11:46:56 | 14:20 | 영향 태그와 이미지 변형을 제거하거나 검증된 정상 배포물로 재연결 완료 |
| GHCR | 11:46:56 | 13:51 | 영향 태그의 이용 불가를 확인한 시각이며 실제 제거 시각은 아님 |
저장소별로 정리된 시점이 달라 사용한 배포물의 설치·실행 이력을 각각 대조해야 하며, GHCR의 확인 시각을 확정된 노출 종료 시각으로 삼아서는 안 된다.
회사는 버전을 고정하지 않고 11:39~13:23에 설치한 이용자에게 영향을 확인하도록 안내했다.
회사는 PyPI의 11:39:51~13:23 시간대에 문제 버전을 설치했거나, Docker Hub의 11:46:56~14:20 시간대에 오염된 이미지를 실행했다면 환경이 침해된 것으로 간주하라고 권고했다. GHCR의 영향 태그는 13:51에 이용 불가가 확인됐지만 실제 제거 시각은 확인되지 않았다. 당분간은 1.106.2 또는 그보다 앞서 공개된 명시적 버전으로 고정하라는 안내다.
3. 파이썬을 다시 켜기 전에 악성 파일 제거
복구는 셸에서 악성 파일을 지우는 일부터 시작한다. 영향받은 환경에서 파이썬이 시작되면 악성 코드가 다시 실행될 수 있고, pip 실행도 파이썬을 시작하기 때문이다.
회사 권고에 따라 영향받은 각 설치 디렉터리에서 cook.pth와 cook.py를 제거한다.
sitecustomize.py와 관련 바이트코드 캐시, 파이썬 코드를 변환해 저장한 파일도 삭제한다.
이어서 /tmp/remote_code_loader.lock을 잡고 별도로 실행 중인 파이썬 프로세스를 종료한다. 정리를 마친 뒤 설치 버전을 확인하는 명령은 다음과 같다.
pip show litellm그 뒤 1.106.2로 고정해 재설치한다. 회사는 이미지와 가상 환경은 처음부터 다시 만드는 편이 낫다고 권고했다.
문제 버전이 외부 통신 가능한 호스트, 네트워크에 연결된 컴퓨터에 설치됐다면 회사는 정보 유출이 성공한 것으로 간주하라고 했다. 그 호스트가 접근할 수 있던 인스턴스·작업 역할 자격 증명(서버나 실행 작업에 부여된 접근 권한을 사용하는 인증 정보), 프록시 데이터베이스의 제공자 키와 관리·가상 키, 데이터베이스 연결 비밀번호와 프로세스 환경의 비밀값을 교체해야 한다.
회사는 클라우드 활동 기록 서비스인 CloudTrail에서 설치 시점 전후에 호출자의 신원을 확인하는 GetCallerIdentity 호출이 있었는지 확인하라고 안내했다. 이어 해당 역할의 자격 증명이 이용자 인프라 바깥에서 사용됐는지 살피라고 권고했다.
4. 탈취한 권한으로 정상 게시 절차 악용
회사는 3월 사고 뒤 릴리스 저장소, 배포 파일을 관리하는 공간을 비공개로 옮기고, 정해진 작업 흐름과 신뢰된 게시 기능을 도입했다. 이미지 태그를 변경할 수 없게 하고 이미지에 서명하는 조치도 취했다. 정상 절차는 테스트를 통과한 커밋, 코드 변경을 묶어 기록한 단위에서 배포물을 만든 뒤 별도 작업으로 게시하는 방식이었다.
하지만 월요일에 고객 버그 수정판 배포를 위해 내부 엔지니어 두 명의 권한을 임시로 확대했다. 공격자는 개발자 세 계정의 GitHub CLI 자격 증명을 확보했으며, 그중 조직 소유자의 토큰으로 보호 설정을 끄고 작업 흐름을 바꿨다고 회사는 밝혔다.
공격자는 게시 작업이 정상 저장소 BerriAI/litellm 대신 유사한 이름의 Berri-AI/litellm을 참조하도록 했다. 회사 타임라인에 따르면 두 번째 개발자 계정의 자격 증명은 운영 배포 승인 단계를 통과하는 데 쓰였다. 탈취된 인증 정보가 소스 변경뿐 아니라 게시 승인 단계에도 쓰인 것이다. 변조된 작업 흐름은 오염된 배포물에 서명하고 게시했다. 서명이 붙는 단계 앞에서 제작 경로가 바뀐 셈이다.
회사는 특정 상황에서 Claude Code 응답에 사용자의 GitHub CLI OAuth 토큰, 앱 접근 권한을 위임하는 인증값이 포함되고, 응답을 기록하면 사내 서비스 로그에도 남을 수 있다고 밝혔다. 공격자가 인터넷에 노출된 사내 배포 환경에 접근해 로그에서 토큰을 얻은 것으로 회사는 보고 있다.
5. 배포물 회수 뒤에도 남는 이용자 복구 작업
배포물 회수와 정상 이미지 재연결은 새로 내려받는 경로를 정리하는 조치다. 회사는 조사 중 유지 관리자 자격 증명을 필요한 최소 수준으로 회수했다. 이용자는 그와 별도로 설치·실행 환경을 정리하고 재구성하며, 접근 가능한 비밀값을 추적해 교체하는 작업을 맡게 됐다.
회사는 최초 사내 접근 경로를 아직 확정하지 못했으며 최근 패치한 취약점을 의심하고 있다고 밝혔다. 또한 컨테이너나 임시 파일 정리로 흔적이 사라질 수 있어, 악성 파일이나 유출 흔적 파일이 없다는 사실만으로 환경이 안전하다고 판단할 수 없다.
이번 사고의 사용자 대응은 배포물 회수 여부보다 노출 시간대의 설치·실행 이력과 접근 가능한 비밀값을 끝까지 추적하는 데 달려 있다.