▲

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

 (github.com/BerriAI)
2P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 널리 사용되는 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에 매핑되지 않는 고유 기능 존재
▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • LiteLLM의 메인테이너임. 현재 상황은 아직 조사 중이지만, 지금까지 파악된 내용은 다음과 같음

    1. 문제는 CI/CD에서 사용된 trivy에서 비롯된 것으로 보임 (관련 검색 링크, 분석 글)
    2. proxy docker를 사용하는 경우 영향 없음. requirements.txt에서 버전을 고정했기 때문임
    3. PyPI에서 해당 패키지를 격리 조치하여 다운로드가 차단됨
      현재 원인 분석과 보안 강화 방안을 검토 중이며, 불편을 끼쳐 죄송함
    • 영향을 받은 버전(v1.82.7, v1.82.8)은 PyPI에서 삭제했음. 모든 maintainer 계정과 키(GitHub, Docker, CircleCI, pip)를 교체함. 여전히 프로젝트 전체를 스캔 중이며, 보안 전문가의 도움을 환영함 (연락: krrish@berri.ai)
    • 누군가 내 개인 GitHub 계정도 침해된 것 같다고 함. 검색 결과에서 관련 흔적이 보인다고 함
    • “미안하다”는 내 표현이 인간적이었다고 말해줘서 고마움. 형식적인 사과문 대신 진심을 담은 대응이 낫다는 피드백이 힘이 됨
    • 왜 자격 증명 회전이 즉시 이루어지지 않았는지 묻는 질문이 있었음. 짧은 시간 내에 인지하지 못한 이유를 설명해야 할 듯함
    • 누군가 자신의 시스템에서 설치된 litellm 버전을 찾는 간단한 스크립트를 만들어 공유함 (스크립트 링크). 완벽하진 않지만 conda, .venv, uv, 시스템 환경을 빠르게 스캔할 수 있다고 함

  • 우리는 여전히 의존성과 개발 환경을 신뢰할 수 없음. dev container는 격리가 부족하고 사용성도 떨어짐. 이제는 sandbox 기반의 개발 환경으로 전환해야 함. VM 수준의 격리, egress 필터, seccomp, gVisor 같은 방어 계층을 갖춘 환경이 필요함. 이런 환경이라면 침해가 발생해도 컨테이너가 바로 종료되고, 문제를 쉽게 식별할 수 있음

    • 지난 50년간의 보안 단축 습관이 결국 부메랑이 되어 돌아온 것 같음. 이제는 신뢰 기반의 개발 문화가 끝나가고 있음. 단순한 샌드박싱을 넘어 보안 모델 자체의 재설계가 필요함
    • 이제는 “예전처럼”이라는 말이 통하지 않음. 암호학적으로 검증 가능한 안전성이 필수임. Red Hat의 DISA STIG처럼 외부 저장소 사용을 금지하는 방향으로 가야 함
    • 자격 증명을 컨테이너로부터 격리하는 내 프로젝트에 대한 의견을 구함 (tightbeam, airlock)
    • 나는 smolvm이라는 오픈소스 프로젝트를 개발 중임 (링크). VM 수준의 격리와 컨테이너 지원을 결합한 기술로, 완전한 가상 머신 단위 배포를 목표로 함. 함께 협력할 사람을 찾고 있음
    • 최근의 공급망 공격 중 dev container 탈출이 실제로 있었는지 궁금하다는 질문이 나옴

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

  • 최근 몇 주간의 TeamPCP 활동과 관련된 사건임. 내가 정리한 타임라인이 도움이 될 것 같음

    • 훌륭한 정리라는 피드백을 받음. 다만 “플레이리스트”가 인상적이었다는 농담도 있었음
    • 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 방식으로 해결책이 제시된 바 있음. 하지만 공급망 공격은 여전히 어려운 과제임. 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을 활용한 자동화 공격일 가능성이 높음

    • 공격자가 왜 봇 댓글을 달아 이슈를 도배하는지 궁금하다는 질문이 있었음. 아마도 혼란 유발과 대응 지연이 목적일 것 같음
답변달기