LiteLLM 공급망 공격, 3시간에 클라우드 36%가 위험했습니다

2026년 3월 24일 오전, 월 9,700만 건이 다운로드되는 AI 개발 도구 LiteLLM의 PyPI 패키지에 인증 정보 탈취 악성코드가 심어졌습니다. 악성 버전이 배포된 시간은 딱 3시간. 그 사이에 SSH 키, 클라우드 API 키, 암호화폐 지갑까지 수집해 외부로 유출하도록 설계된 코드였습니다. LiteLLM 공급망 공격의 전말과 지금 당장 해야 할 것을 정리했습니다.

LiteLLM이 어떤 도구였는지 먼저 알아야 합니다

LiteLLM은 미국 스타트업 BerriAI가 만든 오픈소스 Python 라이브러리입니다. OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure 등 100개 이상의 LLM API를 하나의 통일된 인터페이스로 묶어주는 프록시 게이트웨이 역할을 합니다. 개발자 입장에서는 모델을 바꿔도 코드를 거의 손대지 않아도 되니까 꽤 편한 도구입니다.

그런데 여기서 주목할 점이 있습니다. LiteLLM은 구조상 여러 LLM 제공업체의 API 키를 한 곳에 모아서 관리하는 방식으로 설계되어 있습니다. 해커 입장에서 보면, 이 하나만 뚫으면 사용자의 OpenAI 키, Anthropic 키, AWS 자격 증명을 한꺼번에 가져갈 수 있다는 뜻입니다.

PyPI Stats 기준 월간 약 9,700만 건의 다운로드를 기록하던 패키지였고 (출처: pypistats.org/packages/litellm, 2026.03.25 기준), GitHub 스타 수는 40,700개 이상이었습니다. 스탠퍼드의 DSPy, CrewAI, Google ADK 같은 주요 AI 프레임워크도 LiteLLM을 의존성으로 사용하고 있었습니다. 이게 왜 중요한지는 뒤에서 다시 나옵니다.

▲ 목차로 돌아가기

보안 스캐너가 공격의 시작점이 됐습니다

이번 사건은 단독으로 발생한 것이 아니었습니다. TeamPCP라는 해킹 그룹이 2026년 2월 말부터 시작한 연쇄 공급망 공격 캠페인의 일부였습니다 (출처: Datadog Security Labs, 2026.03.27).

시작은 Aqua Security의 보안 취약점 스캐너 Trivy였습니다. TeamPCP는 Trivy 저장소의 GitHub Actions 워크플로우 취약점을 악용해 조직 전체의 GitHub 개인 액세스 토큰을 탈취했고, 3월 19일에는 Trivy의 GitHub Actions 태그 76개를 통째로 악성 버전으로 바꿨습니다. 보안을 검사하라고 넣어둔 도구가 오히려 공격 경로가 된 것입니다.

LiteLLM도 CI/CD 보안 스캔에 Trivy를 사용하고 있었는데, 버전을 고정하지 않고 최신 버전을 자동으로 받아 쓰는 방식이었습니다 (출처: LiteLLM 공식 보안 업데이트, docs.litellm.ai, 2026.03.27). 변조된 Trivy가 실행되면서 LiteLLM의 PyPI 배포 토큰이 공격자 손에 넘어간 것입니다. Trivy 하나가 뚫린 것이 LiteLLM 침해로 이어진 셈입니다.

▲ 목차로 돌아가기

악성코드가 노린 것들: SSH 키부터 암호화폐까지

2026년 3월 24일 10시 39분(UTC), 공격자는 탈취한 PyPI 토큰으로 LiteLLM v1.82.7을 올렸습니다. 13분 뒤인 10시 52분에는 한층 업그레이드된 v1.82.8이 추가됐습니다 (출처: Datadog Security Labs, 2026.03.27).

두 버전에 심어진 악성코드는 332줄 분량의 인증 정보 수집 스크립트였습니다. 수집 → 암호화 → 유출 → 백도어 설치 순서로 동작합니다.

수집된 데이터는 AES-256-CBC로 암호화한 뒤, 세션 키를 RSA-4096 공개키로 한 번 더 감싸서 tpcp.tar.gz로 묶어 models.litellm.cloud로 전송했습니다. 이 도메인은 공격 하루 전인 3월 23일에 등록된 위장 도메인입니다. LiteLLM의 공식 도메인은 litellm.ai입니다.

v1.82.8은 특히 더 위험했습니다. 이 버전에는 litellm_init.pth라는 파일이 추가됐습니다. Python의 .pth 파일은 site-packages 디렉터리에 위치하면 Python 인터프리터가 시작될 때 자동으로 실행됩니다 (출처: Python 공식 site 모듈 문서, docs.python.org). import litellm 같은 명시적 호출 없이도, 같은 Python 환경에서 어떤 스크립트를 실행하기만 해도 악성코드가 돌아가는 구조입니다. 설치만 해도 이미 감염된 셈입니다.

감염 시스템에는 백도어도 설치됐습니다. ~/.config/systemd/user/sysmon.service라는 이름의 systemd 서비스가 등록되어 약 50분마다 checkmarx.zone에서 추가 페이로드를 받아 실행합니다. Kubernetes 환경에서는 node-setup-* 이름의 파드를 클러스터 전체에 뿌려 횡적 이동까지 시도합니다.

▲ 목차로 돌아가기

Docker 사용자가 무사했던 이유

많은 분들이 “LiteLLM 쓰는데 나도 위험한가?” 하고 걱정하셨을 겁니다. 결론부터 말씀드리면 공식 LiteLLM Proxy Docker 이미지 사용자는 이번 공격에 영향을 받지 않았습니다 (출처: LiteLLM 공식 보안 업데이트, 2026.03.27).

이유는 간단합니다. 공식 Docker 이미지는 requirements.txt에 의존성 버전이 고정되어 있습니다. 사건 당시 Docker 이미지가 사용하던 LiteLLM 버전은 v1.82.3이었습니다. 악성 버전인 v1.82.7, v1.82.8이 끼어들 자리 자체가 없었던 것입니다.

솔직히 말하면, 이번 사건이 보여준 건 “좋은 도구를 쓰느냐”의 문제가 아니라 “어떻게 관리하느냐”의 문제였습니다. pip로 버전 고정 없이 설치하는 방식과 Docker + 고정 버전으로 배포하는 방식의 보안 결과가 이번에 완전히 갈렸습니다.

▲ 목차로 돌아가기

공격자 실수가 사건을 터뜨렸습니다

악성 v1.82.8이 배포된 지 약 56분 뒤인 11시 48분, FutureSearch.ai의 개발자 Callum McMahon이 GitHub에 이슈를 등록했습니다. LiteLLM이 MCP 플러그인의 간접 의존성으로 설치됐는데, 그 직후 시스템 메모리가 급격히 고갈되고 머신이 다운됐다는 내용이었습니다 (출처: GitHub Issue #24512, 2026.03.24).

조사해보니 .pth 파일이 Python 시작 시마다 자식 프로세스를 생성하고, 그 자식 프로세스가 다시 .pth를 실행하는 포크 폭탄 구조가 되어버린 것이었습니다. 공격자가 의도한 동작이 아니었고, .pth 파일의 자동 실행 특성에서 비롯된 버그였습니다. 이 버그가 없었다면 발견이 훨씬 늦어졌을 수도 있습니다.

이슈가 올라온 지 약 1시간 뒤에는 더 황당한 일이 벌어졌습니다. 12시 44분부터 12시 46분까지 102초 동안 봇 계정 73개가 스팸 댓글 88개를 이슈에 쏟아부었습니다. 보안 신고를 스팸으로 묻어버리려는 시도였고, 12시 49분에는 탈취한 관리자 계정으로 이슈를 강제 종료하기까지 했습니다 (출처: 나무위키 2026년 LiteLLM 공급망 공격 사건, 2026.03.27).

하지만 그때는 이미 Hacker News에 관련 스레드가 올라가 있었습니다. 13시 38분에 PyPI가 패키지 전체를 격리했고, 15시 09분에 BerriAI가 인증 정보 교체를 완료했습니다. 20시 15분, 악성 버전이 완전히 삭제됐습니다. Andrej Karpathy는 이 사건을 X에서 “software horror”라고 표현했습니다.

▲ 목차로 돌아가기

지금 당장 해야 할 감염 확인 절차

LiteLLM을 직접 쓰든, AI 프레임워크를 통해 간접적으로 쓰든 아래 절차를 먼저 확인해야 합니다. 특히 CrewAI, DSPy, browser-use 같은 도구를 사용하고 있다면 필수입니다 (출처: LiteLLM 공식 보안 업데이트, 2026.03.27).

pip show litellm | grep Version
# Version: 1.82.7 또는 1.82.8 이면 즉시 조치 필요

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

kubectl get pods --all-namespaces | grep node-setup
# node-setup-* 파드가 있으면 클러스터 침해 가능성

▲ 목차로 돌아가기

이 사건이 AI 개발 생태계에 남긴 것

사건 이후 파장이 컸습니다. CrewAI는 LiteLLM 의존성을 걷어내고 네이티브 SDK로 전환하겠다고 발표했고, Google ADK도 LiteLLM 의존성 유지 여부를 재검토하기 시작했습니다. DSPy는 긴급 PR로 litellm<=1.82.6으로 버전을 고정했습니다 (출처: 나무위키 2026년 LiteLLM 공급망 공격 사건, 2026.03.27).

LiteLLM 구조 자체에 대한 의문도 제기됐습니다. 100개 이상의 LLM 제공업체 API 키를 한 곳에 모아 관리하는 편리한 구조가, 뚫렸을 때는 올인원으로 탈취가 가능하다는 점이 재조명됐습니다. Go 기반의 Bifrost, Rust 기반의 TensorZero, Cloudflare AI Gateway 같은 대안이 거론되기 시작한 것도 이때부터입니다.

한 가지 더 주목할 부분이 있습니다. TeamPCP는 hackerbot-claw라는 AI 에이전트로 약 47,000개의 GitHub 저장소를 자동 스캔하며 취약한 GitHub Actions 워크플로우를 찾아냈다고 알려져 있습니다 (출처: 나무위키 2026년 LiteLLM 공급망 공격 사건, 2026.03.27). AI를 이용해서 AI 인프라를 공격한 셈입니다. 공격의 탐색과 준비 단계 자체가 자동화된 AI 에이전트로 운영되기 시작했다면, 방어 방식도 달라져야 한다는 뜻이기도 합니다.

이번 사건에서 실제로 버텨낸 것은 결국 버전 고정이라는 아주 단순한 관행이었습니다. Docker 공식 이미지가 버전을 고정하고 있었다는 이유 하나로 사건을 비켜갔습니다. 새로운 보안 도구보다, 지금 당장 쓰고 있는 의존성 버전이 고정되어 있는지 확인하는 것이 더 실질적인 방어입니다.

▲ 목차로 돌아가기

Q&A — 많이 궁금해하는 것들

▲ 목차로 돌아가기

마치며

이번 LiteLLM 공급망 공격에서 가장 인상적이었던 건, 방어에 성공한 쪽이 새로운 보안 솔루션을 썼기 때문이 아니라는 점이었습니다. 의존성 버전을 고정했다는 이유 하나로 Docker 사용자들은 사건을 통째로 비켜갔습니다.

반대로 피해가 발생한 경로는 너무 익숙한 흐름이었습니다. pip install litellm, 버전 미고정 의존성, 최신 버전 자동 업데이트. 이 평소 같은 행위가 공격의 입구가 됐습니다.

지금 AI 프로젝트를 운영하고 있다면, 오늘 당장 의존성 파일을 열어보는 것이 가장 실질적인 보안 점검입니다. 화려한 보안 도구보다, ==와 <=가 지금 시점에서는 더 직접적인 방어입니다.

1. LiteLLM 공식 보안 업데이트 — docs.litellm.ai (2026.03.27)
2. Datadog Security Labs — LiteLLM compromised on PyPI: Tracing the March 2026 TeamPCP campaign (2026.03.27)
3. Python 공식 문서 — site 모듈 및 .pth 파일 동작 (docs.python.org)
4. 나무위키 — 2026년 LiteLLM 공급망 공격 사건 (2026.03.27)
5. PyPI Stats — litellm 다운로드 통계 (pypistats.org, 2026.03.25 기준)