"LiteLLM을 최근에 업데이트했는데 괜찮을까요?" 여러 AI 모델을 한 통로로 연결하는 AI 게이트웨이 LiteLLM을 쓰는 팀이라면 지금 확인해야 할 질문입니다. 결론부터 말하면, 공식 배포 버전 1.107.0에 계정정보 탈취와 백도어 기능을 가진 악성코드가 들어 있었습니다. 영향을 받는 것은 10월 21일(UTC) 특정 시간대에 설치한 경우이고, 원인 조사 과정에서 클로드 코드 응답에 깃허브 토큰이 섞여 로그에 남았을 가능성이 거론됐습니다.
LiteLLM 1.107.0 악성코드 정리｜설치 시간대 확인, 클로드 코드 토큰 노출 의혹과 대응 5단계
목차 (8)
✅ 이 글에서 얻을 수 있는 것
1. 영향받는 설치 시간대 (한국 시간 포함)
2. 공격이 정상 배포 절차를 통과한 과정
3. 확인 명령어와 대응 5단계
사건 한눈에
| 항목 | 내용 |
|---|---|
| 대상 | LiteLLM 1.107.0 (PyPI, 도커 허브) |
| 악성 기능 | 계정정보 탈취, 리눅스·맥OS 백도어 |
| pip 영향 시간 | UTC 10월 21일 11:39~13:23 (한국 오후 8:39~10:23), 버전 미지정 설치 |
| 도커 영향 시간 | UTC 10월 21일 11:46~14:20 (한국 오후 8:46~11:20) |
| 탈취된 깃허브 CLI 인증정보 | 3개 (1개는 워크플로 실행 권한 포함) |
| 이후 정황 | 탈취 약 4시간 30분 뒤 AWS 인증정보로 베드록 모델 목록 조회 (위즈) |
| 피해 규모 | 설치 수·피해자 수 미공개 |
공격은 이렇게 진행됐다
- 출발점: LiteLLM은 외부 인터넷에 노출된 내부 배포 환경을 의심합니다. 그 시스템에서 일반 사용자처럼 보이는 수상한 계정이 발견됐습니다.
- 토큰 확보: 공격자가 이 환경의 로그에서 개발자들의 깃허브 CLI 토큰을 얻었을 가능성이 있습니다. 노출 경로와 실제 접근 여부는 아직 확인 중입니다.
- 보호 해제: 깃허브 조직 소유자 토큰으로 브랜치 보호를 끄고 악성 코드를 강제로 반영했습니다.
- 비슷한 저장소 이름: 정식
BerriAI/litellm이 아니라 하이픈을 넣은Berri-AI/litellm을 대상으로 배포 자동화를 실행했습니다. - 서명까지 통과: 악성 패키지가 서명 절차를 거쳐 공개됐습니다.
- 클라우드 악용 시도: 감염된 CI 서버와 쿠버네티스 노드에서 얻은 AWS 인증정보로 베드록 모델 목록을 조회했습니다. 남의 클라우드로 AI 모델을 몰래 돌리는 'LLM재킹'과 비슷한 수법으로 분석되지만, 실제 모델 실행까지는 입증되지 않았습니다.
LiteLLM은 3월 비슷한 사고 이후 배포 체계를 강화했지만, 10월 19일 일일 버그 수정 버전 배포를 위해 엔지니어 2명의 배포 권한을 일시적으로 넓힌 상태였습니다.
클로드 코드는 왜 거론됐나
LiteLLM은 특정 조건에서 클로드 코드가 깃허브 CLI 인증 토큰을 응답 본문에 포함하는 현상을 관찰했다고 밝혔습니다. AI 응답을 저장하도록 설정된 시스템이라면 그 토큰이 로그에 그대로 남을 수 있다는 설명입니다.
다만 이 현상이 이번 유출로 실제 이어졌는지는 조사 단계입니다. 확정된 원인이 아니라는 점을 기억하세요. 그래도 교훈은 분명합니다. AI 코딩 도구의 입출력을 저장하는 로그는 비밀 값이 섞일 수 있는 민감 데이터로 다뤄야 합니다.
📌 함께 보면 좋은 가이드: 가짜 클로드 코드 확장, 커서에서 최대 5,000명 설치 — 같은 시기 AI 개발 도구를 노린 또 다른 공급망 공격입니다.
내 환경 확인하기
1. 설치된 버전 확인
pip show litellm | grep -i version
2. 악성 파일 흔적 검색 (site-packages 경로에서)
python -c "import site; print('\n'.join(site.getsitepackages()))"
# 위에서 나온 경로마다 아래 파일이 있는지 확인
ls <site-packages 경로> | grep -E "cook\.pth|cook\.py|sitecustomize\.py"
3. 도커 이미지 확인: 해당 시간대에 태그 없이(latest 등) 이미지를 받은 서버가 있는지 배포 기록을 봅니다.
대응 5단계
- 삭제·격리: 1.107.0을 지우고 설치된 시스템을 네트워크에서 분리합니다.
- 악성 파일 확인:
cook.pth,cook.py,sitecustomize.py가 있는지 봅니다. - 도메인 차단: 악성코드와 연관된
litellm[.]dev접근을 막습니다. - 인증정보 교체: 그 시스템에서 접근할 수 있던 모든 키·토큰(AWS, 깃허브, AI API 키 등)을 새로 발급합니다.
- 재구축: 흔적이 남았을 수 있으면 시스템을 다시 만듭니다.
재발을 막는 습관
| 습관 | 이유 |
|---|---|
버전·해시 고정 설치 (pip install --require-hashes) |
버전 미지정 설치가 이번 영향 조건 |
| AI 도구 로그에서 비밀 값 마스킹 | 응답 속 토큰이 로그로 남을 수 있음 |
| 배포 권한은 최소·한시적으로, 회수 확인 | 일시 확대한 권한이 공격 직전 상태였음 |
| 저장소 이름까지 검증 | BerriAI와 Berri-AI처럼 한 글자 차이 |
| 빌드 산출물 검증 | 소스가 안전해도 배포 파일은 다를 수 있음 (제이프로그 지적) |
클로드 코드를 쓴다면 권한 설정으로 민감한 명령과 파일 접근을 제한해 두는 것도 도움이 됩니다.
맺음말
- LiteLLM 1.107.0에 계정정보 탈취·백도어 악성코드가 들어 있었고, UTC 10월 21일 특정 시간대 설치자가 영향권입니다.
- 공격자는 탈취한 토큰으로 브랜치 보호를 끄고 서명까지 거쳐 배포했습니다. 클로드 코드 응답 속 토큰 노출은 조사 중인 가능성입니다.
- 설치했다면 삭제·격리 → 파일 확인 → 도메인 차단 → 인증정보 교체 → 재구축 순서로 대응하세요.
공식 자료
👉 다음에 읽을 글
- 챗GPT 공유 링크 취약점 정리 — 같은 주에 수정된 AI 서비스 보안 결함입니다.
- 구글 OAuth DPoP 지원 — 토큰 탈취를 막는 인증 방식입니다.
자주 묻는 질문
- 어떤 경우에 영향을 받나요?
- 협정세계시(UTC) 10월 21일 11시 39분부터 13시 23분 사이 버전을 지정하지 않고 pip로 LiteLLM을 설치했거나, 같은 날 11시 46분부터 14시 20분 사이 도커 이미지를 받은 경우입니다. 한국 시간으로는 10월 21일 오후 8시 39분~10시 23분(pip), 오후 8시 46분~11시 20분(도커)입니다.
- 악성코드는 무엇을 하나요?
- 계정정보를 탈취하고, 리눅스·맥OS에서 외부 공격자가 시스템에 접근할 수 있는 백도어 기능을 합니다. 위즈(Wiz)는 공격자가 탈취 약 4시간 30분 뒤 AWS 인증정보로 베드록(Bedrock) 모델 목록을 조회한 정황을 확인했습니다.
- 클로드 코드가 원인인가요?
- 확정되지 않았습니다. LiteLLM은 특정 조건에서 클로드 코드가 깃허브 CLI 인증 토큰을 응답 본문에 포함하는 현상을 관찰했고, 응답을 저장하는 시스템에서는 토큰이 로그에 남을 수 있다고 밝혔습니다. 이것이 이번 유출로 이어졌는지는 조사 중입니다.
- 설치했다면 무엇부터 해야 하나요?
- 1.107.0을 삭제하고 시스템을 격리한 뒤 cook.pth, cook.py, sitecustomize.py 파일이 있는지 확인합니다. litellm[.]dev 도메인 접근을 막고, 그 시스템에서 접근할 수 있던 인증정보를 모두 교체하세요. 필요하면 시스템을 다시 구축합니다.
- 서명된 패키지인데 왜 막지 못했나요?
- 공격자가 깃허브 조직 소유자 토큰으로 브랜치 보호를 끄고, 이름이 비슷한 저장소(Berri-AI/litellm)로 배포 자동화를 실행해 정상 절차와 서명을 거쳐 공개했기 때문입니다. 서명만으로 설치 파일의 안전을 보장할 수 없다는 점이 드러났습니다.
