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

• 널리 사용되는 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에 매핑되지 않는 고유 기능 존재