📅 2026.03.29 기준 / LiteLLM v1.82.7·v1.82.8 기준
LiteLLM 공급망 공격,
설치만 해도 털립니다
2026년 3월 24일, 월 9,500만 다운로드 Python 패키지 LiteLLM에 악성코드가 심어졌습니다. pip install litellm 한 줄이면 SSH 키, 클라우드 자격증명, 암호화폐 지갑이 전부 외부로 빠져나갑니다. 공식 보안 리포트 4건을 직접 확인해 정리했습니다.
Wiz: 전체 클라우드 환경 36% 노출 추정
TeamPCP 캠페인 5단계 중 4번째
결론부터 — 지금 당장 확인해야 할 것
결론부터 말씀드리면, 2026년 3월 24일 10:39 UTC에서 16:00 UTC 사이에 pip install litellm을 실행했거나, 버전을 고정하지 않고 사용 중이었다면 즉각 점검이 필요합니다. LiteLLM 공식 보안 업데이트(docs.litellm.ai, 2026.03.27)에 따르면 영향 버전은 v1.82.7과 v1.82.8 두 가지입니다.
🚨 즉시 실행 체크리스트
① 설치 버전 확인: 터미널에서 pip show litellm 실행 → Version이 1.82.7 또는 1.82.8이면 영향 범위에 해당
② 악성 파일 존재 여부: find /usr/lib/python3 -name "litellm_init.pth" — 파일이 존재하면 즉시 삭제 후 상위 단계 대응 필요
③ 외부 통신 이력: models.litellm[.]cloud 또는 checkmarx[.]zone으로 나간 네트워크 트래픽 확인
④ 모든 자격증명 즉시 교체: SSH 키, 클라우드 액세스 키, .env 파일 내 모든 시크릿, Kubernetes 토큰 포함
안전한 버전은 v1.82.6 이하입니다. LiteLLM 공식팀은 v1.78.0~v1.82.6 전 버전의 SHA-256 해시를 검증해 공개했습니다 (출처: LiteLLM 공식 보안 업데이트, 2026.03.27).
설치만 해도 실행되는 버전이 따로 있습니다
두 버전이 같아 보여도 실제 위험 수준이 다릅니다. Datadog Security Labs 분석(securitylabs.datadoghq.com, 2026.03.27)에 따르면 v1.82.7은 proxy_server.py에 악성 코드가 주입돼 있어 해당 모듈을 import할 때 실행됩니다.
💡 공식 분석 문서와 기술 구조를 같이 놓고 보니 이런 차이가 보였습니다
v1.82.8은 차원이 다릅니다. litellm_init.pth라는 파일이 패키지 안에 포함돼 있는데, Python의 site 모듈 명세에 따라 .pth 파일은 Python 인터프리터가 시작될 때 자동으로 실행됩니다. import도, 실행도 하지 않아도 됩니다. 설치만 돼 있으면 다음에 파이썬을 켜는 순간 악성코드가 작동합니다.
Upwind Security 분석(upwind.io, 2026.03.25)은 작동 순서를 이렇게 정리했습니다. 먼저 AES-256 세션 키로 탈취 데이터를 암호화하고, RSA-4096 공개키로 세션 키를 한번 더 암호화한 뒤, models.litellm[.]cloud로 POST 전송합니다. 공격자만 가진 RSA 개인키 없이는 복호화가 불가능한 구조입니다. 암호화를 탄탄하게 설계한 공격입니다.
⏱️ 탐지 우회를 위한 50분 대기
악성코드에 설치된 C2 에이전트는 checkmarx[.]zone/raw를 약 50분 간격으로 폴링합니다. Sonatype 수석 보안 연구원 Adam Reynolds는 The Record Media 인터뷰(2026.03.25)에서 “샌드박스 환경은 보통 이보다 짧은 시간 동안 샘플을 실행하기 때문에 탐지를 피하려는 의도로 보인다”고 밝혔습니다. 실제로 C2 서버가 반응 없이 YouTube 링크만 반환한 사례도 있었는데, 이는 연구자와 진짜 타깃을 구별하는 목적으로 분석됩니다.
재부팅해도 살아남는 구조도 있습니다. ~/.config/systemd/user/sysmon.service로 systemd 서비스를 등록해 10초마다 자동 재시작합니다.
악성코드가 노리는 것 목록 — 예상보다 훨씬 깁니다
Upwind Security의 페이로드 분석에 따르면 탈취 대상이 상당히 광범위합니다. 단순 API 키 수집이 아니라 시스템 전체를 훑도록 설계돼 있습니다.
| 카테고리 | 탈취 대상 | 비고 |
|---|---|---|
| 클라우드 자격증명 | AWS, GCP, Azure 전체 | IMDS v2, Secrets Manager 포함 |
| SSH 키 | RSA, Ed25519, ECDSA, DSA 전체 | authorized_keys, known_hosts 포함 |
| Kubernetes | 서비스 계정 토큰, 전 네임스페이스 시크릿 | 클러스터 전파 코드 포함 |
| 암호화폐 지갑 | Bitcoin, Ethereum, Solana 외 9종 | validator 키페어 포함 |
| CI/CD 시크릿 | GitLab CI, Travis, Jenkins, Drone | Terraform tfvars, Helm 포함 |
| 애플리케이션 시크릿 | .env 전체, DB 자격증명, Slack 웹훅 | HashiCorp Vault 토큰 포함 |
| 셸 히스토리 | bash, zsh, MySQL, psql, Redis CLI 히스토리 | /etc/passwd, /etc/shadow 포함 |
Kubernetes 환경은 특히 심각합니다. 서비스 계정 토큰에 충분한 RBAC 권한이 있으면, 악성코드가 모든 노드에 node-setup-<노드명> 특권 파드를 배포합니다. 이 파드는 호스트 루트 파일시스템을 마운트해 백도어를 노드 자체에 심습니다. 파드 하나가 감염되면 클러스터 전체가 감염되는 구조입니다.
Wiz Research는 이 패키지가 전체 클라우드 환경 중 약 36%에 설치돼 있다고 추정했습니다 (출처: Wiz Research 블로그, 2026.03.25). 잠재 피해 범위가 한두 팀의 문제가 아닙니다.
Docker 공식 이미지 쓴 사람은 다릅니다
“LiteLLM 쓰는데 나도 걱정해야 하나?”라는 질문을 먼저 분리해야 합니다. LiteLLM 공식 보안 업데이트는 이 부분을 명확히 구분합니다.
💡 공식 발표문과 배포 구조를 함께 보니 이런 차이가 드러납니다
✅ 안전한 케이스: ghcr.io/berriai/litellm 공식 Docker 이미지를 사용한 경우 — 이 이미지는 requirements.txt에 의존성을 고정해 PyPI에서 직접 가져오지 않습니다.
⚠️ 위험한 케이스: pip install litellm을 버전 고정 없이 실행했거나, AI 에이전트 프레임워크·MCP 서버·LLM 오케스트레이션 도구가 LiteLLM을 전이 의존성(transitive dependency)으로 가져온 경우 — 본인이 직접 설치하지 않았어도 걸릴 수 있습니다.
전이 의존성 문제가 핵심입니다. 본인이 pip install litellm을 직접 친 적이 없어도, 쓰고 있는 AI 프레임워크가 LiteLLM을 내부에서 끌어올 수 있습니다. LiteLLM Cloud(litellm.ai)를 SaaS 형태로 사용한 경우는 영향 없습니다.
LiteLLM 팀은 현재 Google Mandiant 팀과 함께 빌드·배포 파이프라인 전체를 포렌식 분석 중이며, 분석이 완료되기 전까지 신규 릴리스를 중단했습니다 (출처: LiteLLM 공식 보안 업데이트, 2026.03.27).
이 사건이 혼자 일어난 게 아닌 이유
LiteLLM 사건을 단독 해킹 사고로 보면 전체 그림을 놓칩니다. Datadog Security Labs 분석은 이것이 TeamPCP라는 공격 그룹의 연쇄 캠페인 4번째 단계임을 밝혔습니다.
📆 TeamPCP 공급망 공격 도미노 타임라인
Trivy 취약점 스캐너 감염 — 컴프로마이즈된 자격증명으로 v0.69.4 악성 릴리스, GitHub Actions 태그 76개 강제 푸시. CI/CD 러너 메모리를 덤프해 자격증명 탈취 후 다음 단계로 재사용.
npm 자가 증식 웜(CanisterWorm) — 28개 @EmilGroup 패키지 등 47개 npm 패키지 감염. 탈취한 npm 토큰으로 새 버전을 자동 배포하며 스스로 확산. 이란 시스템에선 호스트 파일시스템 삭제, 비이란 환경엔 백도어 설치.
Checkmarx KICS·OpenVSX 감염 — GitHub Actions 감염, VS Code 확장 2개(ast-results v2.53.0, cx-dev-assist v1.7.0) 백도어 삽입.
LiteLLM PyPI 감염 — 월 9,500만 다운로드 AI 패키지 공격. 이전 단계에서 탈취한 자격증명이 LiteLLM 배포 파이프라인에 접근하는 데 사용된 것으로 추정.
Telnyx PyPI 감염 — 전화 SDK. WAV 파일 안에 2단계 페이로드를 숨긴 새로운 기법 사용. 같은 RSA 공개키로 탈취 데이터 암호화.
Wiz Research의 Ben Read는 “이것은 단순 자격증명 탈취가 아닙니다. 널리 쓰이는 도구들 사이를 이동하면서 눈덩이처럼 피해가 커지는 구조입니다”라고 The Record Media에 말했습니다 (2026.03.25). 캠페인이 진행형임을 감안하면, 이후에도 새로운 패키지가 타깃이 될 가능성이 있습니다.
AI 도구 생태계가 특히 위험한 구조적 이유
이번 사건에서 LiteLLM이 타깃이 된 건 우연이 아닙니다. LiteLLM은 100개 이상의 LLM 프로바이더 API를 단일 인터페이스로 호출하는 프록시 라이브러리입니다. GitHub Stars 4만 개, 월 9,500만 다운로드 — 이 숫자가 왜 문제인지를 구조적으로 보면 다른 그림이 나옵니다.
💡 AI 오케스트레이션 레이어가 왜 공격의 핵심 통로가 되는지 보입니다
LiteLLM 같은 중간 레이어 패키지는 API 키를 한 곳에 모아서 관리하도록 설계돼 있습니다. OpenAI, Anthropic, Google, AWS Bedrock 키를 모두 하나의 프록시에 집중시키는 구조이기 때문에, 이 레이어가 감염되면 개별 서비스를 하나씩 털 필요 없이 한 번에 모든 LLM 프로바이더 자격증명이 빠져나갑니다. AI 인프라가 복잡해질수록 이런 중간 레이어의 보안이 더 중요해집니다.
LiteLLM 공식 보안 업데이트(2026.03.27)에 따르면 감염 경로에는 “MCP 서버, AI 에이전트 프레임워크, LLM 오케스트레이션 도구를 통한 전이 의존성”이 명시돼 있습니다. 즉, LiteLLM을 직접 쓰지 않는 팀도 연결된 프레임워크가 LiteLLM을 내부적으로 사용하고 있으면 영향권에 들어갑니다.
Sonatype은 악성 버전이 PyPI에 올라온 두 시간 동안, 하루 300만 다운로드 수준의 패키지 특성상 상당한 수의 피해자가 발생했을 것으로 분석했습니다 (출처: The Record Media, 2026.03.25). 두 시간이라는 짧은 노출 시간이 안도할 이유가 아닙니다.
📌 개인적인 생각
AI 도구를 쓰는 팀이라면 패키지 버전 고정(pinning)을 귀찮은 관행이 아니라 필수 보안 조치로 다시 봐야 할 시점입니다. 특히 LiteLLM처럼 API 키가 집중되는 레이어 패키지는 더욱 그렇습니다. “부지런히 업데이트하는 것”이 항상 안전한 게 아니라, 검증된 버전으로 고정하고 업데이트 전 해시를 확인하는 방향이 실질적인 방어가 됩니다.
Q&A 5가지
Q
LiteLLM을 쓰고 있는데, Docker 이미지로 배포했다면 안전한가요?
ghcr.io/berriai/litellm 공식 Docker 이미지를 사용한 경우 영향 없습니다. 이 이미지는 requirements.txt로 의존성을 고정해 PyPI 직접 설치 흐름을 사용하지 않습니다. 단, 자체 Dockerfile에서 pip install litellm을 버전 고정 없이 실행했다면 별개 케이스입니다.
Q
악성 패키지를 설치했지만 실행하지 않았다면 괜찮나요?
v1.82.7만 설치된 경우라면 proxy 모듈을 import하지 않았다면 실행 안 됩니다. 그러나 v1.82.8이 설치된 경우 litellm_init.pth가 Python 인터프리터 시작 시 자동 실행됩니다. “설치했지만 import 안 했다”는 v1.82.8에 통하지 않습니다. 설치 이력을 정확히 확인해야 합니다.
Q
패키지를 삭제하고 최신 버전으로 업데이트하면 끝인가요?
아닙니다. Datadog 분석은 명확하게 “패키지 복구를 완전한 복구로 봐서는 안 된다”고 강조합니다. 감염이 이미 발생했다면 시스템에 백도어(~/.config/sysmon/sysmon.service)가 남아 재부팅 후에도 활성화됩니다. 패키지 삭제, 백도어 파일 제거, 모든 자격증명 교체, 감염 환경에서 빌드된 아티팩트 재검토가 함께 이뤄져야 합니다.
Q
내가 LiteLLM을 직접 설치하지 않았는데도 걱정해야 하나요?
LiteLLM 공식 보안 업데이트는 “AI 에이전트 프레임워크, MCP 서버, LLM 오케스트레이션 도구를 통한 전이 의존성”을 위험 경로로 명시합니다. 사용 중인 AI 관련 패키지가 LiteLLM을 내부 의존성으로 포함하고 있다면 해당됩니다. pip show litellm으로 설치 여부부터 확인해야 합니다.
Q
앞으로 안전하게 LiteLLM을 사용하려면 어떻게 해야 하나요?
LiteLLM 팀은 Google Mandiant와 포렌식 분석을 완료하기 전까지 신규 릴리스를 중단했습니다. 재개 이후에는 공식 안전 버전 목록의 SHA-256 해시를 직접 대조한 뒤 사용하는 것이 가장 확실합니다. 또한 패키지 버전을 고정해 의도치 않은 업데이트를 막는 것을 기본 원칙으로 가져가야 합니다.
마치며
이번 사건은 “내가 조심하면 괜찮다”는 개인 보안 감각이 더 이상 충분하지 않다는 걸 보여줍니다. 본인이 신뢰하는 패키지를, 공신력 있는 관리자 계정으로, 정상적인 버전 번호로 배포된 악성코드를 사전에 걸러내는 건 매우 어렵습니다.
TeamPCP는 아직 진행 중입니다. Trivy → npm → Checkmarx → LiteLLM → Telnyx로 이어진 도미노는 더 확장될 수 있습니다. 당장 해야 할 것은 복잡한 보안 솔루션 도입보다, pip show litellm 한 줄로 설치 버전을 확인하고, 1.82.7~1.82.8이면 즉시 자격증명을 교체하는 것입니다.
LiteLLM 팀은 v1.82.6 이하 전 버전의 SHA-256을 공개했고, 공식 조사는 현재도 진행 중입니다. 빠른 대응이 손해를 줄이는 가장 확실한 방법입니다.
📚 본 포스팅 참고 자료
- LiteLLM 공식 보안 업데이트 — Security Update: Suspected Supply Chain Incident (2026.03.27)
- Datadog Security Labs — LiteLLM compromised on PyPI: Tracing the March 2026 TeamPCP supply chain campaign (2026.03.27)
- Upwind Security — LiteLLM Supply Chain Breakdown (2026.03.25)
- The Record Media — Supply chain attack hits widely-used AI package (2026.03.25)
- 나무위키 — 2026년 LiteLLM 공급망 공격 사건
본 포스팅은 2026년 3월 29일 기준으로 공개된 공식 보안 리포트를 바탕으로 작성되었습니다. 본 포스팅 작성 이후 서비스 정책·보안 권고·UI·기능이 변경될 수 있습니다. 보안 사고 대응 관련 최종 판단은 반드시 공식 문서 및 전문 보안팀과 함께 이행하시기 바랍니다.
댓글 남기기