# LiteLLM 1.82.7 및 1.82.8 PyPI 패키지 침해 사건

> Clean Markdown view of GeekNews topic #27819. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27819](https://news.hada.io/topic?id=27819)
- GeekNews Markdown: [https://news.hada.io/topic/27819.md](https://news.hada.io/topic/27819.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-03-25T09:25:07+09:00
- Updated: 2026-03-25T09:25:07+09:00
- Original source: [github.com/BerriAI](https://github.com/BerriAI/litellm/issues/24512)
- Points: 2
- Comments: 1

## Topic Body

- 널리 사용되는 LLM 통합 라이브러리 **LiteLLM**의 PyPI 패키지 두 버전(1.82.7, 1.82.8)에 **악성 페이로드가 삽입**되어 배포되었으며, 설치 시 시스템 인증 정보를 탈취하는 공격이 발생  
- 공격 원인은 CI/CD 보안 스캐닝 도구 **Trivy의 공급망 침해**에서 비롯되었으며, CircleCI 인증 정보가 유출되어 PyPI 퍼블리시 토큰과 GitHub PAT가 탈취됨  
- 공식 LiteLLM **Proxy Docker 이미지** 사용자는 requirements.txt에 버전 고정이 되어 있어 영향을 받지 않았으나, PyPI에서 직접 pip install한 환경은 즉각적인 점검 필요  
- GitHub 이슈 스레드에 수백 개의 **봇 스팸 댓글**이 쏟아져 실질적 논의를 방해했으며, 이는 공격자가 의도적으로 대응 커뮤니케이션을 교란한 것으로 확인  
- **DSPy, CrewAI** 등 LiteLLM을 의존성으로 사용하는 다수 프로젝트에도 파급 영향이 있어, 소프트웨어 **공급망 보안의 근본적 취약성**을 다시 한 번 부각  
  
---  
  
### 사건 개요 및 발견 경위  
  
- 새 프로젝트 설정 중 시스템이 비정상적으로 동작하며 **RAM이 소진**되고 포크봄 형태의 프로세스가 실행됨  
- 조사 결과 `proxy_server.py`에 **base64로 인코딩된 악성 블롭**이 추가되어 있었고, 이를 디코딩하여 별도 파일을 생성한 뒤 실행하는 구조  
- 1.82.7 버전은 `litellm/proxy/proxy_server.py`에 페이로드가 포함되어 **`import litellm.proxy` 시 실행**  
- 1.82.8 버전은 추가로 `litellm_init.pth` 파일을 포함하여, 패키지가 설치만 되어도 Python 시작 시 **자동으로 악성코드 실행**  
  - `.pth` 파일은 Python의 `site` 모듈이 시작 시 자동 실행하는 메커니즘으로, `import` 키워드 뒤에 임의 코드 실행 가능  
  - 이 메커니즘은 Python **2.1부터** 존재했으며, 별도 PEP 없이 도입됨  
- FutureSearch 팀이 최초 피해를 보고: **uvx가 자동으로 최신 litellm(버전 미고정)을 설치**한 뒤, Cursor가 로컬 MCP 서버를 자동 로드하면서 감염 발생  
  
### 공격 경로 및 TeamPCP 연관  
  
- 공격은 최근 Trivy를 침해한 **TeamPCP** 그룹과 동일한 공격자로 확인  
- 침해 경로: **Trivy 해킹** → CircleCI 인증 정보 전체 유출 → PyPI 퍼블리시 토큰 + GitHub PAT 탈취 → 악성 패키지 배포  
- LiteLLM CEO/CTO의 **GitHub 계정도 완전히 탈취**되어, 개인 저장소 설명이 모두 "teampcp owns BerriAI"로 변경되었고 이슈가 닫히는 등의 행위 발생  
- PYPI_PUBLISH 토큰이 GitHub 프로젝트의 **환경 변수로 저장**되어 있었고, 이것이 Trivy를 통해 유출됨  
  - 계정에는 **2FA가 설정**되어 있었으나, 토큰 자체가 탈취되어 우회됨  
- 공격자는 GitHub 이슈에 수백 개의 **봇 계정**으로 동일 문구를 반복 게시하여 실질적 논의를 방해  
  - Trivy 저장소에서도 동일한 패턴으로 **700개 이상의 스팸 댓글** 확인  
  - 스팸 계정 중 일부는 실제 기여 이력이 있는 GitHub 사용자로, 2월부터 "Update workflow configuration" 커밋으로 **CI 워크플로에 인증 정보 탈취기를 삽입**한 이력 확인  
- Trivy 침해는 **최소 5일 전**에 발생했으며, 최신 공격 공지가 바로 전날 나왔기 때문에 메인테이너가 인지하지 못한 상태에서 피해 발생 가능  
- 공격자는 **Internet Computer Protocol(ICP) Canisters**를 페이로드 전달에도 활용, DNS 차단만으로는 방어 불가  
  
### 악성 페이로드 동작 방식  
  
- 백그라운드 Python 프로세스를 생성하고 내장된 스테이지를 디코딩하여 실행  
- **인증 정보 수집기**가 실행되며, 데이터 수집 성공 시 공격자의 RSA 공개키로 AES 키를 암호화하고, 탈취 데이터를 **원격 호스트로 전송**  
- 악성코드에서 발견된 URL: `checkmarx.zone/raw`와 `models.litellm.cloud`  
- 주로 **`~/.git-credentials`의 SSH 키와 크립토 지갑 정보**를 탈취 대상으로 삼음  
- CPU 집약적 작업으로 인해 시스템이 과부하되어 오히려 발견이 용이했으며, 팬 소음으로 이상을 감지한 사례도 보고됨  
- Harbor 설치 시에도 동일한 증상 발생: `grep -r rpcuser\rpcpassword` 프로세스가 포크봄 형태로 실행되어 **크립토 지갑 탐색** 시도  
  
### LiteLLM 팀 대응  
  
- 영향받은 버전(v1.82.7, v1.82.8)은 **PyPI에서 삭제** 완료  
- 모든 메인테이너 계정의 **비밀번호 변경**, GitHub/Docker/CircleCI/pip의 모든 키 삭제 및 교체  
- 새 메인테이너 계정은 **@krrish-berri-2**와 **@ishaan-berri**로 교체  
- PyPI에서 전체 패키지가 일시 **격리(quarantine)** 처리되었다가, 감염 버전 제거 후 해제  
- 모든 신규 릴리스를 **중단**하고 공급망 전체 리뷰 완료 전까지 배포 동결  
- Google의 **Mandiant** 보안 팀과 협력하여 조사 및 복구 진행 중  
- Trivy는 마지막 안전 버전인 **v0.35.0**으로 고정 (초기 v0.69.3 고정에서 커뮤니티 피드백 반영하여 변경)  
- 향후 **Trusted Publishing(JWT 토큰 기반 OIDC)** 전환, 별도 PyPI 계정 사용 등 보안 강화 검토  
- 악성 버전의 **최초 게시 시각은 약 UTC 8:30**, PyPI 격리 처리는 약 **UTC 11:25**  
  
### 영향 범위 및 다운스트림 프로젝트  
  
- LiteLLM은 **DSPy**의 유일한 LLM 프로바이더 호출 라이브러리이며, **CrewAI**도 폴백으로 사용  
- **Airflow, Dagster, Unsloth.ai, Polar, nanobot** 등도 LiteLLM에 의존  
- GitHub 검색 기준, requirements.txt에 LiteLLM을 **버전 미고정으로 포함**한 프로젝트가 628건 이상 확인  
- 공식 Proxy Docker 배포 경로 사용자는 requirements.txt에 **버전 고정**이 되어 있어 영향 없음  
- Docker 배포의 경우, 호스트 파일시스템과 환경변수에 접근이 제한되어 상대적으로 안전하나, 마운트된 인증 정보는 여전히 위험  
  - 공격자의 주요 목표는 **개인 SSH 키**이며, LLM 키 접근은 부차적  
- Harbor, browser-use 등 LiteLLM을 의존성으로 자동 설치하는 도구 사용자도 **간접 피해** 보고  
- CrewAI는 litellm을 **1.82.6(마지막 안전 버전)으로 고정**했으나 커밋 메시지에 침해 관련 언급 없음  
- DSPy는 **공개적으로 이슈를 생성**하여 대응 중  
- LangChain은 자체 LLM 프로바이더 호출 레이어를 보유하고 있어 **이번 공급망 침해에 직접 영향 없음** (선택적 langchain-litellm 패키지 사용 시 제외)  
  
### 커뮤니티 논의: 공급망 보안 및 샌드박싱  
  
- 의존성과 개발 환경을 **더 이상 신뢰할 수 없으며**, VM 격리 + 컨테이너 프리미티브 + 허용 목록 + egress 필터 + seccomp + gVisor 등 **다층 방어(defense in depth)** 필요  
- 과거 50년간의 **보안 편의주의가 되돌아오는 상황**이며, 전체 보안 모델의 재설계 필요  
- **프로그래밍 언어 수준**에서 모듈별 샌드박싱 필요하다는 의견  
  - Java는 1990년대 v1.2부터 이 기능이 있었으나 사용성 문제로 폐기됨  
  - **Capability 기반 언어**의 개발 적기라는 의견  
  - Cloudflare의 **workerd** 런타임이 모듈 격리 가능한 기존 솔루션으로 언급  
- OpenBSD의 **pledge/unveil**, Linux의 chroot/namespace/cgroup, FreeBSD의 **Capsicum** 등 OS 수준 격리 도구가 이미 존재  
- Guix는 **몇 초 만에 격리된 컨테이너**를 생성하여 $HOME에 접근하지 않고 의존성 설치 가능  
- **Firejail과 bwrap** 등 사용자 공간 격리 도구의 적극 활용 필요  
- 모바일 앱의 **샌드박싱 + 권한 모델(Intents)** 이 이미 존재하지만, 데스크톱 환경에서는 일반 연산 제한에 대한 반감이 강함  
  - 이에 대해, Apple/Meta 등의 **앱 스토어 폐쇄성과 보안 샌드박싱은 별개** 문제이며, 사용자에게 제어권을 주면서도 보안을 확보하는 도구 구축 가능  
- macOS용 **canary/honeypot 도구** 공개 (github.com/dweinstein/canary): 가짜 시크릿을 WebDAV/NFS에 마운트하여 비정상 접근 탐지  
- **패키지 발행과 퍼블릭 저장소 사이에 벽을 세워야** 한다는 의견: 퍼블릭 저장소를 직접 Trusted Publisher로 설정하면 공격 표면이 넓어짐  
  - 반론으로, Trusted Publishing의 본래 목적은 **소스와 게시 아티팩트 간의 감사 가능한 연결**을 제공하는 것이므로 프라이빗 저장소 경유는 후퇴  
  
### 실무 보안 권고 사항  
  
- 의존성은 **SHA256 체크섬과 함께 버전 고정** 필수  
- 내부 **패키지 미러** 운영으로 최신 버전 직접 사용 방지  
- **빌드 아티팩트**를 사용하고 `uv run` 등으로 배포 시 즉석 설치에 의존하지 말 것  
  - PyPI 장애 시 시스템이 중단되는 구조적 위험도 제거  
  - 배포 가능한 아티팩트의 장점: **감사 가능성, 빠른 롤백**, 아웃바운드 네트워크의 위험 엔드포인트 차단 가능  
- uv의 `exclude-newer` 설정으로 **일정 기간 이내 신규 패키지 제외** 가능  
  - pyproject.toml에 `[tool.uv] exclude-newer = "5 days"` 설정 가능  
- CI/CD에서 퍼블리시 토큰은 **OIDC 기반 워크플로**로 전환하여 토큰 자체를 제거하는 것이 근본적 해결  
  - GitHub과 PyPI 모두 OIDC 지원: 퍼블리시 작업에만 OIDC 엔드포인트 접근 권한 부여하면 Trivy 작업에서 탈취할 토큰 자체가 없음  
- Trivy 등 보안 스캐닝 도구는 **퍼블리시 권한이 없는 별도 워커**에서 실행해야 함  
- **lockfile 관리** 및 주간 단위 업데이트로 최신 버전 즉시 채택 회피  
- Python의 `.pth` 파일은 **자동 코드 실행**이 가능하므로, `-S` 옵션으로 site import를 억제할 수 있으나 호환성 문제 있음  
- osv-scanner 등을 활용한 **프로젝트 전체 의존성 스캔** 권장  
- 감염 여부 확인 명령어:  
  - `find / -name "litellm_init.pth" -type f 2>/dev/null`  
  - `find / -path '*/litellm-1.82.*.dist-info/METADATA' -exec grep -l 'Version: 1.82.[78]' {} \; 2>/dev/null`  
- 패키지 매니저 생태계 전체의 **인증 정보 일괄 교체(credential rotation)** 필요성도 제기됨  
  
### SOC2 감사 및 신뢰성 문제  
  
- LiteLLM의 SOC2 감사 업체가 최근 논란이 된 **Delve**였다는 점이 지적됨  
- SOC2는 "문서화된 프로세스를 실제로 따르고 있는지"를 확인하는 것일 뿐, **보안 수준 자체를 보장하지 않음**  
- 적절한 SOC2라도 이번 공급망 공격을 예방했을지는 불확실  
  
### LiteLLM 대안 프로젝트  
  
- **Bifrost** (github.com/maximhq/bifrost): Rust 기반 대안, 무료 오픈소스 인스턴스에서도 가상 키 설정 가능  
- **Portkey** (portkey.ai): 프록시 서비스, 무료 플랜 제공, LiteLLM보다 빠르다는 평가  
- **pydantic-ai**: Python 기반 대안  
- **any-llm** (github.com/mozilla-ai/any-llm): Mozilla 프로젝트  
- **LLM Gateway** (llmgateway.io): LiteLLM 마이그레이션 가이드 제공  
- **InferXgate** (github.com/jasmedia/InferXgate): 신규 프로젝트, 지원 프로바이더 제한적  
- 일부 개발자는 LLM 프로바이더 API가 실질적으로 **OpenAI와 Anthropic 두 종류**뿐이므로 직접 `requests.post()`로 호출하는 것이 더 안전하다는 입장  
  - 반론으로, Anthropic의 OpenAI 호환 API는 **장기적/프로덕션 솔루션으로 권장되지 않으며**, 벤더별 네이티브 API에는 OpenAI API에 매핑되지 않는 고유 기능 존재

## Comments



### Comment 53760

- Author: neo
- Created: 2026-03-25T09:25:07+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47501426) 
- LiteLLM의 **메인테이너**임. 현재 상황은 아직 조사 중이지만, 지금까지 파악된 내용은 다음과 같음  
  1. 문제는 CI/CD에서 사용된 **trivy**에서 비롯된 것으로 보임 ([관련 검색 링크](https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy), [분석 글](https://ramimac.me/trivy-teampcp/#phase-09))  
  2. proxy docker를 사용하는 경우 영향 없음. requirements.txt에서 버전을 고정했기 때문임  
  3. PyPI에서 해당 패키지를 **격리 조치**하여 다운로드가 차단됨  
  현재 원인 분석과 보안 강화 방안을 검토 중이며, 불편을 끼쳐 죄송함  
  - 영향을 받은 버전(v1.82.7, v1.82.8)은 PyPI에서 삭제했음. 모든 **maintainer 계정과 키**(GitHub, Docker, CircleCI, pip)를 교체함. 여전히 프로젝트 전체를 스캔 중이며, 보안 전문가의 도움을 환영함 (연락: krrish@berri.ai)
  - 누군가 내 개인 GitHub 계정도 **침해된 것** 같다고 함. [검색 결과](https://github.com/search?q=%22teampcp+owns%22)에서 관련 흔적이 보인다고 함
  - “미안하다”는 내 표현이 인간적이었다고 말해줘서 고마움. 형식적인 사과문 대신 진심을 담은 대응이 낫다는 피드백이 힘이 됨
  - 왜 **자격 증명 회전**이 즉시 이루어지지 않았는지 묻는 질문이 있었음. 짧은 시간 내에 인지하지 못한 이유를 설명해야 할 듯함
  - 누군가 자신의 시스템에서 설치된 litellm 버전을 찾는 간단한 스크립트를 만들어 공유함 ([스크립트 링크](https://github.com/kinchahoy/uvpowered-tools/blob/main/inven...)). 완벽하진 않지만 conda, .venv, uv, 시스템 환경을 빠르게 스캔할 수 있다고 함  

- 우리는 여전히 **의존성과 개발 환경**을 신뢰할 수 없음. dev container는 격리가 부족하고 사용성도 떨어짐. 이제는 **sandbox 기반의 개발 환경**으로 전환해야 함. VM 수준의 격리, egress 필터, seccomp, gVisor 같은 방어 계층을 갖춘 환경이 필요함. 이런 환경이라면 침해가 발생해도 컨테이너가 바로 종료되고, 문제를 쉽게 식별할 수 있음  
  - 지난 50년간의 **보안 단축 습관**이 결국 부메랑이 되어 돌아온 것 같음. 이제는 신뢰 기반의 개발 문화가 끝나가고 있음. 단순한 샌드박싱을 넘어 **보안 모델 자체의 재설계**가 필요함  
  - 이제는 “예전처럼”이라는 말이 통하지 않음. **암호학적으로 검증 가능한 안전성**이 필수임. Red Hat의 DISA STIG처럼 외부 저장소 사용을 금지하는 방향으로 가야 함  
  - 자격 증명을 컨테이너로부터 격리하는 내 프로젝트에 대한 의견을 구함 ([tightbeam](https://github.com/calebfaruki/tightbeam), [airlock](https://github.com/calebfaruki/airlock))  
  - 나는 **smolvm**이라는 오픈소스 프로젝트를 개발 중임 ([링크](https://github.com/smol-machines/smolvm)). VM 수준의 격리와 컨테이너 지원을 결합한 기술로, 완전한 **가상 머신 단위 배포**를 목표로 함. 함께 협력할 사람을 찾고 있음  
  - 최근의 공급망 공격 중 **dev container 탈출**이 실제로 있었는지 궁금하다는 질문이 나옴  

- macOS용으로 만든 **canary** 도구를 소개함 ([링크](https://github.com/dweinstein/canary)). 패키지가 접근해서는 안 될 파일을 탐지하는 간단한 Go 바이너리임. WebDAV나 NFS로 가짜 비밀 정보를 노출하고, 접근 시 알림을 보냄. **honeypot 접근법**으로 이상 행위를 감지할 수 있음  

- 최근 몇 주간의 **TeamPCP 활동**과 관련된 사건임. 내가 정리한 [타임라인](https://ramimac.me/trivy-teampcp/#phase-09)이 도움이 될 것 같음  
  - 훌륭한 정리라는 피드백을 받음. 다만 “플레이리스트”가 인상적이었다는 농담도 있었음  
  - TeamPCP 이름은 여러 곳에서 봤지만, 이렇게 한눈에 정리된 건 처음이라는 반응이 있었음  
  - 업데이트를 이렇게 빠르게 유지하는 방법이 궁금하다는 질문이 있었음  

- GitHub의 **스팸 탐지 시스템**이 너무 약하다는 지적이 있었음. litellm 이슈에 170개 이상의 스팸 댓글이 달렸다고 함  
  - 며칠 전 **trivy 저장소**에서도 같은 일이 있었음. 해킹 관련 토론이 닫히자 700개 이상의 스팸 댓글이 달림. 일부는 실제 활동 이력이 있는 계정이었음. **자격 증명 탈취형 공격**이 광범위하게 퍼진 것 같음. 여러 계정이 2월에 “Update workflow configuration”이라는 커밋으로 **CI에 credential stealer**를 심은 흔적이 있음  
  - GitHub에서 스팸을 신고하려면 여러 단계를 거쳐야 해서 **비효율적**이라는 불만이 있었음  
  - 일부는 단순한 **봇 계정**일 가능성도 언급됨  

- 이런 일이 언젠가 일어날 거라 예상했음. **의존성 버전 고정**을 통해 방어하려 했지만, 그마저도 완벽하지 않음. 오픈소스의 **공급망 복잡성** 때문에 모든 코드를 검증하는 건 불가능함. LLM 덕분에 악성 코드가 대량으로 퍼질 위험이 100배는 커졌음  
  - Rust 생태계는 **의존성 트리**가 너무 깊어서 검증이 어렵다는 의견이 있었음. Rust, Node, Python 모두 비슷한 문제를 겪고 있음. 반면 C/C++은 시스템 패키지 매니저를 쓰기 때문에 의존성 추가 비용이 높아 상대적으로 안전함  

- 만약 AI가 작성한 코드가 **LLVM이나 Linux**에 침투한다면, 우리는 진정으로 “trusting trust” 문제를 마주하게 될 것임  
  - “Trusting Trust” 문제는 이미 [Diverse Double-Compiling](https://arxiv.org/abs/1004.5534) 방식으로 해결책이 제시된 바 있음. 하지만 공급망 공격은 여전히 어려운 과제임. AI는 단지 **공격의 규모를 키우는 도구**일 뿐임  
  - 이제는 모든 것이 불안함. **airgap 환경**만이 안전할지도 모름. 하지만 대부분의 데이터는 클라우드에 있고, 우리는 그 백업조차 통제할 수 없음  
  - **결정적 빌드 체인**을 통해 완전히 검증 가능한 소프트웨어를 만드는 시도가 진행 중임. Debian의 93% 패키지가 재현 가능한 빌드임. 하지만 여전히 많은 개발자가 “curl | bash”를 아무렇지 않게 실행함. **XZ 백도어 사건**은 이런 현실을 일깨워준 사례였음  
  - LLM이 커널 코드를 학습하지 못하도록 **내부 API를 자주 변경**하는 것이 유일한 방어책이라는 의견도 있었음  
  - 만약 이런 공격이 현실화된다면, **정부 서버나 클라우드 인프라**가 대규모 피해를 입을 수 있음. 특히 국가 단위의 해킹이 결합되면 피해 규모는 수조 달러에 이를 수 있음. 그래도 Linux는 상대적으로 안전하다고 생각함  

- LiteLLM의 **SOC2 감사기관이 Delve**였다는 사실이 언급됨.  
  - 하지만 SOC2 인증이 이런 공격을 막을 수 있었을지는 의문임. 실제로 SOC2는 완전한 방패가 되지 못한다는 경험담이 공유됨  

- Harbor를 설치했더니 CPU가 100%로 치솟으며 시스템이 멈췄음. `grep -r rpcuser\rpcpassword` 프로세스가 **암호화폐 지갑 탐색**을 시도한 것으로 보임. 다행히 백도어는 설치되지 않았음  
  - browser-use에서도 같은 경험을 했다는 사람이 있었음. litellm이 종속성으로 설치되었고, 시스템이 멈췄음. GitHub과 HuggingFace 토큰을 무효화했지만, **OS 재설치가 필요할지** 물어봄  
  - “프로세스를 어떻게 그렇게 빨리 확인했냐”는 질문이 있었음. Activity Monitor를 항상 켜두는지 궁금하다고 함  
  - “Harness가 뭐냐”는 질문도 나옴  

- 이번 사건은 **Trivy를 해킹한 TeamPCP**와 동일한 공격 그룹의 소행으로 보임. 이슈에 봇 댓글이 넘쳐나는 것도 같은 패턴임. **LLM을 활용한 자동화 공격**일 가능성이 높음  
  - 공격자가 왜 봇 댓글을 달아 이슈를 도배하는지 궁금하다는 질문이 있었음. 아마도 **혼란 유발과 대응 지연**이 목적일 것 같음