LiteLLM v1.82.7 · v1.82.8
⚠️ 즉시 대응 필요
LiteLLM 공급망 공격, 46분 만에
2,112개 패키지 뚫렸습니다
2026년 3월 24일 오전 10시 39분(UTC), 해킹 그룹 TeamPCP가 탈취한 PyPI 토큰으로 악성 LiteLLM을 등록했습니다. 불과 46분 동안 배포된 두 버전이 SSH 키·클라우드 API 키·쿠버네티스 토큰을 통째로 빼갔습니다. pip install litellm 한 줄이면 충분했습니다.
LiteLLM이 뭔데 이렇게 난리일까요
LiteLLM 공급망 공격이 유독 파장이 컸던 건 이 라이브러리의 위치 때문입니다. BerriAI가 개발한 오픈소스 Python 라이브러리로, OpenAI·Anthropic·Google·AWS Bedrock·Azure 등 100여 개 LLM 제공업체 API를 하나의 인터페이스로 묶어주는 프록시 게이트웨이 역할을 합니다. GitHub 스타 40,700개 이상, 월간 다운로드 약 9,700만 건—그냥 인기 있는 패키지가 아니라 AI 인프라의 허브입니다. (출처: Wiz Research, 2026.03.24)
구조를 보면 왜 해커들이 노렸는지 바로 보입니다. LiteLLM은 여러 LLM 제공업체의 API 키를 한 곳에 모아 관리합니다. 이걸 하나만 뚫으면 OpenAI 키, Anthropic 키, AWS 키를 한꺼번에 가져갈 수 있는 구조입니다. 스탠퍼드 DSPy, CrewAI, Google ADK, browser-use 같은 주요 AI 프레임워크가 LiteLLM을 의존성으로 사용하고 있었기 때문에, LiteLLM 하나가 뚫리는 순간 2,112개 패키지가 줄줄이 노출됩니다. (출처: Blockchain News / PyPA Advisory PYSEC-2026-2, 2026.03.24)
AI 도구의 편의성이 곧 보안 취약점으로 연결된 사례입니다.
Trivy 하나가 뚫렸는데 LiteLLM까지 감염된 이유
사건 배경을 알면 이게 단순한 해킹이 아니라는 게 보입니다. TeamPCP는 2026년 2월 28일부터 약 한 달에 걸쳐 연쇄 공격을 펼쳤습니다. 시작은 Aqua Security의 보안 스캐너 Trivy였습니다. 3월 19일, TeamPCP는 Trivy 저장소의 pull_request_target GitHub Actions 워크플로우 취약점을 악용해 PyPI 배포 토큰을 포함한 조직 전체 인증 정보를 탈취했고, Trivy GitHub Actions 태그 76개를 악성 버전으로 일괄 교체했습니다. (출처: Datadog Security Labs, 2026.03.28)
💡 보안 스캐너가 공격 경로가 됐다는 게 이 사건의 핵심 아이러니입니다
LiteLLM은 CI/CD 파이프라인에서 보안 스캔을 위해 Trivy를 사용하고 있었습니다. 그런데 버전을 고정하지 않고 apt-get install -y trivy처럼 최신 버전을 자동으로 받아 쓰는 방식이었습니다. 변조된 Trivy가 실행되면서 LiteLLM의 PyPI 배포 토큰이 공격자에게 고스란히 넘어간 것입니다. 보안을 위해 깔아둔 도구가 오히려 공격의 문을 열어준 셈입니다. (출처: LiteLLM 공식 보안 업데이트, docs.litellm.ai, 2026.03.27)
TeamPCP는 3월 20~22일 npm 패키지 28개 이상을 추가로 탈취하고, 3월 23일에는 Checkmarx KICS GitHub Action까지 침해했습니다. LiteLLM은 이 연쇄 공격의 마지막 단계였습니다. 하나의 보안 도구가 뚫리면서 생태계 전체가 도미노처럼 쓰러진 구조입니다.
| 날짜 (UTC) | 공격 대상 | 규모 |
|---|---|---|
| 2026.02.28 | Trivy 저장소 침투 | 토큰 탈취 |
| 2026.03.19 | Trivy GitHub Actions 태그 | 76개 일괄 변조 |
| 2026.03.20 | npm 패키지 | 28개 이상 탈취 |
| 2026.03.21 | Checkmarx KICS GitHub Action | 침해 |
| 2026.03.24 | LiteLLM PyPI 패키지 | v1.82.7 · v1.82.8 감염 |
출처: Datadog Security Labs (2026.03.28)
악성 코드가 실제로 뭘 훔쳐갔는지 봤습니다
v1.82.7에는 litellm/proxy/proxy_server.py에 악성 페이로드가 삽입됐습니다. v1.82.8에는 여기에 더해 litellm_init.pth 파일이 추가됐습니다. Python의 .pth 파일은 site-packages에 있으면 인터프리터가 시작될 때 자동으로 실행됩니다. import litellm조차 없어도, 그냥 Python을 켜기만 해도 악성 코드가 작동하는 구조입니다. (출처: Datadog Security Labs, 2026.03.28)
34,628바이트 짜리 .pth 파일은 한 줄짜리 코드였지만, Base64 이중 인코딩으로 난독화되어 있어 단순 grep으로는 발견이 어렵습니다. 내부는 332줄짜리 인증 정보 수집 스크립트였습니다. 수집 → AES-256-CBC 암호화 → RSA-4096 세션 키 추가 → 유출의 순서로 동작합니다.
💡 공식 발표문과 실제 코드 구조를 같이 놓고 보니 이런 차이가 보였습니다
유출 엔드포인트 models.litellm.cloud는 공격 하루 전인 3월 23일에 등록된 도메인입니다. 공식 LiteLLM 도메인은 litellm.ai로, 오탈자 도메인 전략을 썼습니다. 이걸 알아야 방화벽 로그에서 탐지할 수 있습니다. (출처: LiteLLM 공식 보안 업데이트, docs.litellm.ai, 2026.03.27)
수집 대상 목록입니다. (출처: LiteLLM 공식 보안 업데이트 · Datadog Security Labs)
- SSH 키 전 유형(RSA·Ed25519·ECDSA·DSA) 및 authorized_keys, known_hosts
- AWS·GCP·Azure 클라우드 인증 정보(인스턴스 메타데이터 서비스 포함)
- 쿠버네티스 서비스 계정 토큰 및 모든 네임스페이스 시크릿
- Docker 레지스트리 인증 정보 (~/.docker/config.json)
- GitLab CI·Jenkins·CircleCI 설정 파일, npm/PyPI 토큰
- 암호화폐 지갑 키페어
- 셸 히스토리 (.bash_history, .zsh_history) 및 환경 변수 전체
여기에 더해 ~/.config/systemd/user/sysmon.service라는 이름의 백도어를 설치해 약 50분마다 추가 페이로드를 받아 실행합니다. 쿠버네티스 환경에서는 node-setup-* 파드를 클러스터 전체 노드에 배포해 횡적 이동을 시도합니다. 단순 자격 증명 탈취가 아니라 지속적 거점 확보까지 노린 설계입니다.
Docker 사용자는 왜 멀쩡했는지, 진짜 이유가 있습니다
💡 “Docker 쓰면 안전하다”는 게 아닙니다—정확히 어느 조건에서만 안전한지가 중요합니다
공식 LiteLLM Proxy Docker 이미지(ghcr.io/berriai/litellm)는 requirements.txt에 의존성 버전이 고정되어 있어 감염을 피했습니다. 사건 당시 최신 Docker 이미지의 LiteLLM 버전은 1.82.3이었습니다. 반면 직접 pip install litellm을 Dockerfile에 넣어 빌드한 환경은 감염됐을 수 있습니다. (출처: LiteLLM 공식 보안 업데이트, docs.litellm.ai, 2026.03.27)
결국 핵심은 버전 고정(pinning)입니다. pip install litellm처럼 버전 지정 없이 설치하면 자동으로 최신 버전이 설치되고, 이번 사건처럼 악성 버전이 PyPI에 올라와 있는 46분 사이에 설치하면 감염됩니다. 반면 litellm==1.82.6처럼 특정 버전으로 고정해 뒀다면 악성 버전이 딸려 들어오지 않습니다.
DSPy는 litellm>=1.64.0처럼 느슨하게 잡혀 있어 감염 버전이 그대로 설치될 수 있었고, 긴급 PR로 <=1.82.6으로 즉시 고정했습니다. CrewAI는 당일 LiteLLM 제거 가이드를 내고 네이티브 SDK 전환을 선언했습니다. (출처: Datadog Security Labs, 2026.03.28)
감염을 발견한 건 공격자 실수였습니다
FutureSearch.ai의 Callum McMahon이 Cursor MCP 플러그인을 테스트하다가 LiteLLM이 간접 의존성으로 설치됐습니다. v1.82.8 설치 직후 머신이 다운됐고, 조사해보니 .pth 파일이 Python 시작 시마다 자식 프로세스를 생성하고 그 자식이 다시 .pth를 실행하는 포크 폭탄 구조가 됐습니다. (출처: HeroDev 블로그, 2026.03.26)
💡 버그가 없었다면 발견이 훨씬 늦었을 겁니다
공격자가 의도한 동작은 아니었습니다. .pth 파일의 자동 실행 특성에서 비롯된 실수였고, 이 버그가 있어 머신이 다운되지 않았다면 조용히 자격 증명을 빼가는 코드가 훨씬 오래 살아남았을 수 있습니다. Andrej Karpathy는 이를 두고 "software horror"라고 했습니다. (출처: Andrej Karpathy X/Twitter, 2026.03.24)
McMahon이 2026년 3월 24일 11시 48분(UTC)에 GitHub 이슈를 등록하자, 1시간 뒤 73개 봇 계정이 102초 동안 88개의 스팸 댓글을 이슈에 쏟아냈습니다. 탈취된 관리자 계정으로 이슈를 "not planned"로 강제 종료하기까지 했습니다. 하지만 이미 Hacker News에 스레드가 올라간 뒤였고 은폐 시도는 실패했습니다. 13시 38분(UTC) PyPI가 LiteLLM 패키지 전체를 격리했고, 20시 15분에 악성 버전이 완전 삭제됐습니다. (출처: 나무위키 '2026년 LiteLLM 공급망 공격 사건', 2026.03.27)
지금 당장 해야 할 것들, 순서대로 정리했습니다
① 감염 버전 확인
# 설치된 버전 확인 — 1.82.7 또는 1.82.8이면 즉시 조치
pip show litellm | grep Version
# .pth 파일 존재 여부
find / -name "litellm_init.pth" 2>/dev/null
# 백도어 확인
ls ~/.config/sysmon/sysmon.py 2>/dev/null
ls ~/.config/systemd/user/sysmon.service 2>/dev/null
# Kubernetes 환경
kubectl get pods -n kube-system | grep node-setup② 아웃바운드 트래픽 확인
아래 두 도메인으로 나가는 트래픽이 로그에 있으면 즉시 대응이 필요합니다.
models.litellm.cloud— 자격 증명 유출 엔드포인트 (공식 LiteLLM 도메인 아님)checkmarx.zone/raw— 추가 페이로드 수신 C2 서버 (공식 Checkmarx 도메인 아님)
③ 모든 자격 증명 즉시 교체
1.82.7 또는 1.82.8을 설치한 적 있다면, 해당 환경에서 접근 가능했던 자격 증명을 전부 교체해야 합니다. LiteLLM 공식 문서는 "Treat any credentials present on the affected systems as compromised"라고 명시합니다. (출처: docs.litellm.ai, 2026.03.27)
교체 대상 목록입니다.
- LLM API 키 (OpenAI·Anthropic·Google 등 전부)
- AWS Access Key / GCP 서비스 계정 / Azure 인증 정보
- SSH 키 쌍 재생성
- 쿠버네티스 서비스 계정 토큰
- GitHub·GitLab·CircleCI·Jenkins 토큰
- DB 비밀번호
④ 안전한 버전으로 고정
# 안전한 버전으로 직접 지정해 설치
pip install "litellm<=1.82.6"
# requirements.txt에서 버전 고정 예시
litellm==1.82.6v1.82.6 이하 버전은 BerriAI가 SHA-256 체크섬으로 전수 검증했습니다. (출처: docs.litellm.ai, 2026.03.27)
이번 사건이 AI 개발 관행을 흔드는 이유
이번 LiteLLM 공급망 공격이 다른 보안 사건과 다른 점은 AI 개발 구조 자체의 취약점을 드러냈다는 데 있습니다. 여러 LLM API 키를 하나의 라이브러리로 집중 관리하는 방식은 편리하지만, 뚫리는 순간 OpenAI·Anthropic·AWS·GCP의 키를 동시에 잃는 구조입니다. 편의성과 보안이 정면으로 충돌하는 지점입니다.
CrewAI는 사건 당일 LiteLLM을 걷어내고 네이티브 SDK 전환을 선언했고, Google ADK는 LiteLLM 의존성 유지 여부를 재검토하기 시작했습니다. Go 기반 Bifrost, Rust 기반 TensorZero, Cloudflare AI Gateway 같은 대안이 언급되는 것도 이때부터입니다. 사건이 특정 패키지 하나의 문제가 아니라 AI 인프라 설계 철학에 대한 질문이 됐습니다. (출처: Datadog Security Labs, 2026.03.28)
💡 이 사건에서 AI를 이용해 AI 인프라를 공격한 장면이 있었습니다
TeamPCP는 hackerbot-claw라는 AI 에이전트를 공격 타겟팅에 활용했습니다. 약 47,000개의 저장소를 스캔하며 취약한 GitHub Actions 워크플로우를 자동으로 찾아냈다고 알려져 있습니다. AI 도구가 AI 인프라를 해킹하는 데 쓰인 사례입니다. 이유는 아직 공개되지 않았습니다. (출처: 나무위키 '2026년 LiteLLM 공급망 공격 사건', 2026.03.27)
보안 커뮤니티에서 나오는 실질적 조언은 세 가지입니다. 첫째, 의존성 버전은 반드시 고정(pin)할 것. 둘째, CI/CD 파이프라인에서 사용하는 보안 도구 자체도 신뢰 대상이 아닌 검증 대상으로 볼 것. 셋째, LLM API 키는 환경 변수보다 전용 시크릿 관리 서비스(AWS Secrets Manager, GCP Secret Manager 등)로 격리할 것. 74% 이상의 악성 패키지가 정상 설치 경로를 통해 배포된다는 연구 결과를 생각하면, 설치 전 검증이 습관이 되어야 합니다. (출처: HeroDev 블로그, 2026.03.26)
Q&A
Q1. 현재 LiteLLM을 쓰고 있는데 안전한가요?
감염된 버전은 1.82.7과 1.82.8뿐입니다. pip show litellm | grep Version으로 버전을 확인하고, 1.82.6 이하면 안전합니다. 단, BerriAI가 공급망 전체 검토가 끝날 때까지 신규 릴리스를 중단한다고 밝혔으므로, 1.82.6에 고정해 두는 게 가장 안전합니다. (출처: docs.litellm.ai, 2026.03.27)
Q2. LiteLLM을 직접 쓰지 않는데도 영향받을 수 있나요?
있습니다. DSPy·CrewAI·Open Interpreter·MLflow·PraisonAI·langchain-litellm 등 2,112개 패키지가 LiteLLM을 간접 의존성으로 사용합니다. 이 중 1,403개는 버전 범위를 느슨하게 잡아두어 감염 버전이 자동으로 딸려올 수 있었습니다. pip show litellm으로 설치 여부 자체를 먼저 확인해야 합니다. (출처: PyPA Advisory PYSEC-2026-2)
Q3. Docker로 LiteLLM을 쓰고 있어서 안전하다고 봐도 되나요?
공식 Docker 이미지(ghcr.io/berriai/litellm)를 그대로 쓴 경우라면 안전합니다. 해당 이미지는 requirements.txt에 의존성이 고정되어 있어 감염 버전이 딸려 들어오지 않았습니다. 하지만 Dockerfile에 pip install litellm을 직접 넣어서 빌드한 환경이라면, 3월 24일 10:39~16:00(UTC) 사이에 빌드했다면 감염됐을 수 있습니다. (출처: docs.litellm.ai, 2026.03.27)
Q4. CVE 번호로 검색하면 나오나요?
전통적인 CVE는 할당되지 않았습니다. 코드 자체의 취약점이 아니라 인증 정보 탈취를 통한 공급망 침해이기 때문입니다. 대신 PyPA Advisory PYSEC-2026-2와 Snyk Advisory SNYK-PYTHON-LITELLM-15762713으로 추적할 수 있습니다. (출처: 나무위키 '2026년 LiteLLM 공급망 공격 사건', 2026.03.27)
Q5. 앞으로 LiteLLM을 계속 써도 될까요?
BerriAI는 Google Mandiant 보안팀을 투입해 포렌식 분석 중이고, 공급망 전체 검토가 끝날 때까지 신규 릴리스를 중단한다고 밝혔습니다. CrewAI처럼 LiteLLM을 아예 걷어내는 선택도 있고, v1.82.6에 버전을 고정한 채 유지하는 선택도 있습니다. 어느 쪽이든 버전 고정과 아웃바운드 트래픽 모니터링은 기본입니다. (출처: docs.litellm.ai · Datadog Security Labs, 2026.03.28)
마치며 — 솔직한 총평
이번 LiteLLM 공급망 공격에서 제일 섬뜩했던 건 "보안을 위해 쓰는 도구(Trivy)가 공격의 문을 열었다"는 사실입니다. 우리가 신뢰하는 것의 목록에는 이미 잠재적 위험이 포함돼 있는데, 그걸 무조건 믿고 쓴다는 게 지금 AI 개발 생태계의 현실입니다.
46분이라는 짧은 시간에도 피해가 날 수 있었던 건 하루 340만 건 이상의 다운로드 수 때문입니다. 더 무서운 건, 공격자의 버그(포크 폭탄)가 없었다면 이 조용한 자격 증명 도둑질이 훨씬 오래 지속됐을 수도 있다는 점입니다. 운 좋게 발견된 겁니다.
결론부터 말하면 의존성 버전 고정, CI/CD 파이프라인 도구 검증, LLM API 키 격리 관리—이 세 가지가 이번 사건이 개발자에게 남긴 실질적인 과제입니다. AI 도구를 많이 쓸수록 공격 표면이 넓어진다는 걸 이제는 체감할 수 있는 시대입니다.
📚 본 포스팅 참고 자료
- LiteLLM 공식 보안 업데이트 — https://docs.litellm.ai/blog/security-update-march-2026
- Datadog Security Labs 분석 보고서 — https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/
- PyPA Advisory PYSEC-2026-2 — https://github.com/pypa/advisory-database/blob/main/vulns/litellm/PYSEC-2026-2.yaml
- 나무위키 '2026년 LiteLLM 공급망 공격 사건' — https://namu.wiki/w/2026년_LiteLLM_공급망_공격_사건
- HeroDev 분석 블로그 — https://www.herodevs.com/blog-posts/the-litellm-supply-chain-attack
본 포스팅은 2026년 3월 29일 기준으로 공개된 공식 문서와 보안 연구 자료를 바탕으로 작성되었습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 보안 사건의 특성상 추가 피해 사례나 공격자 신원 정보가 이후 공개될 수 있으며, 최신 정보는 LiteLLM 공식 채널(docs.litellm.ai)과 PyPA Advisory 데이터베이스를 통해 직접 확인하시기 바랍니다.
댓글 남기기