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

2026년 3월 24일 오전, AI 개발자라면 대부분 한 번쯤 설치해봤을 Python 라이브러리 LiteLLM이 악성코드와 함께 배포됐습니다. 하루 340만 건 다운로드, 클라우드 환경 36%에 설치된 패키지가 단 3시간 만에 수만 개 시스템의 SSH 키·클라우드 인증 정보·API 키를 통째로 유출하는 도구가 됐습니다. 그것도 코드베이스 자체가 뚫린 게 아니라, 보안 스캐너가 문을 열어줬습니다.

LiteLLM이 뭔지 모르면 이 사건을 절반만 이해합니다

LiteLLM은 미국 스타트업 BerriAI가 만든 오픈소스 Python 라이브러리입니다. OpenAI, Anthropic, Google, AWS Bedrock, Azure 등 100개 이상의 LLM API를 하나의 인터페이스로 묶어주는 프록시 게이트웨이 역할을 하는데, GitHub 스타 수 40,700개 이상을 기록하며 스탠퍼드 DSPy, CrewAI, Google ADK, MLflow, Netflix, Stripe 같은 곳에서 의존성으로 사용해왔습니다. (출처: BerriAI 공식 보안 업데이트, 2026.03.24)

여기서 구조적 문제가 하나 있습니다. LiteLLM은 여러 LLM 제공업체의 API 키를 한곳에 모아 관리하는 구조입니다. 개발자 입장에선 편리하지만, 공격자 입장에선 이 라이브러리 하나만 뚫으면 사용자의 모든 LLM API 키를 한꺼번에 가져갈 수 있다는 뜻이기도 합니다. Sonatype은 이를 두고 “AI 스택의 중앙 게이트웨이를 노리는 공격”이라고 표현했습니다. (출처: Sonatype 보안 분석 리포트, 2026.03.24)

▲ 목차로 돌아가기

보안 스캐너가 오히려 공격의 문을 열었습니다

이번 사건이 특별한 이유는 LiteLLM 코드 자체가 해킹된 게 아니라는 점입니다. 침투 경로는 LiteLLM의 CI/CD 파이프라인이 보안 스캔에 사용하던 오픈소스 스캐너 Trivy였습니다. 해킹 그룹 TeamPCP는 3월 19일 Trivy 저장소의 GitHub Actions 워크플로우 취약점을 악용해 Trivy의 태그 76개를 악성 버전으로 통째로 교체해버렸고, LiteLLM 팀이 정기 빌드를 돌리는 순간 오염된 Trivy가 실행되며 PyPI 배포 토큰이 공격자 손에 넘어갔습니다. (출처: Datadog Security Research, 2026.03.24)

더 문제였던 건 LiteLLM이 Trivy를 버전 고정 없이 사용하고 있었다는 점입니다. CI/CD 스크립트(ci_cd/security_scans.sh)에서 apt-get install -y trivy로 항상 최신 버전을 당겨오는 방식이었는데, 변조된 Trivy가 그대로 실행될 수밖에 없는 구조였습니다. (출처: 나무위키 2026년 LiteLLM 공급망 공격 사건 문서, 2026.03.27)

TeamPCP 연쇄 공격 타임라인 — LiteLLM은 마지막 표적이었습니다

출처: Datadog Security Research Labs, 2026.03.24

보안 스캐너가 공격의 진입로가 된 셈입니다. CI/CD에서 쓰는 도구도 잠재적 공격 벡터가 될 수 있다는 사실을 이번 사건이 정면으로 보여줬습니다.

▲ 목차로 돌아가기

악성코드가 설치되면 정확히 무슨 일이 벌어지나요

페이로드는 수집 → 암호화 → 유출 → 백도어 설치 순서로 동작합니다. 수집 대상이 방대한데, SSH 키 전 유형, AWS/GCP/Azure 인증 정보, Kubernetes 토큰, 데이터베이스 비밀번호, 암호화폐 지갑 키, CI/CD 파이프라인 시크릿, 셸 히스토리, Docker 레지스트리 인증 정보까지 시스템에 있는 민감 정보를 사실상 전부 긁어갑니다. 수집된 데이터는 AES-256-CBC로 암호화한 뒤, 세션 키를 RSA-4096 공개키로 한 번 더 감싸 models.litellm.cloud로 전송됩니다. (출처: FutureSearch 기술 분석 블로그, 2026.03.24)

v1.82.8이 더 위험한 이유 — import 없이도 실행됩니다

v1.82.7은 import litellm.proxy를 실행하는 시점에 페이로드가 동작합니다. 그런데 v1.82.8은 달랐습니다. litellm_init.pth라는 파일이 추가됐는데, Python의 .pth 파일은 site-packages 디렉터리에 위치하면 Python 인터프리터가 시작될 때마다 자동으로 실행됩니다. 즉, 코드에서 litellm을 import하지 않아도, 해당 Python 환경에서 무언가를 실행하기만 하면 악성코드가 돌아가는 구조입니다. (출처: Datadog Security Research Labs, 2026.03.24)

백도어도 심어집니다. ~/.config/systemd/user/sysmon.service라는 이름의 systemd 서비스가 등록되어 약 50분마다 checkmarx.zone/raw에서 추가 페이로드를 받아 실행합니다. Kubernetes 환경에서는 node-setup-* 이름의 파드를 클러스터 전체에 배포해 횡적 이동을 시도합니다. 패키지 제거만으로는 완전한 복구가 안 됩니다.

▲ 목차로 돌아가기

3시간이 짧다고 생각하면 안 되는 이유가 있습니다

악성 버전이 PyPI에 올라가 있던 시간은 약 3시간입니다. v1.82.7은 UTC 10:39에, v1.82.8은 10:52에 업로드됐고, PyPI 격리 조치는 13:38에 이뤄졌습니다. (출처: BerriAI 공식 보안 업데이트, 2026.03.24) 얼핏 짧아 보이지만, LiteLLM의 하루 다운로드 수가 340만 건입니다. 시간당으로 나누면 약 14만 건인데, 3시간이면 최대 42만 건의 설치가 이뤄졌을 수 있다는 계산이 나옵니다. 보안 기업 Wiz Research는 “클라우드 환경의 36%에 LiteLLM이 설치돼 있다”는 수치를 내놨습니다. (출처: Wiz Research 분석 리포트, 2026.03.24) 설치 기반 자체가 방대하니 3시간도 충분한 피해 범위를 만들어냅니다.

하류 프로젝트들도 즉각 영향을 받았습니다

LiteLLM을 의존성으로 쓰던 프레임워크들이 연쇄 피해를 입었습니다. DSPy(스탠퍼드 NLP)는 litellm>=1.64.0으로 느슨하게 의존성을 잡아뒀다가 감염 버전이 딸려 들어왔고, 당일 긴급 PR로 <=1.82.6으로 고정했습니다. CrewAI는 LiteLLM을 제거하고 네이티브 SDK로 전환하겠다고 선언했으며, Google ADK도 의존성 유지 여부를 재검토하기 시작했습니다. (출처: 나무위키 2026년 LiteLLM 공급망 공격 사건 문서, 2026.03.27) >= 형태로 의존성을 잡는 것이 어떤 위험인지 실시간으로 보여준 사례입니다.

▲ 목차로 돌아가기

SOC2 인증이 있어도 이건 못 막습니다

LiteLLM은 사건 전까지 웹사이트에 SOC2와 ISO 27001 인증을 게시해왔습니다. 그런데 이번 공급망 공격은 그 인증으로 전혀 막을 수 없는 유형이었습니다. SOC2나 ISO 27001은 기업이 보안 정책과 프로세스를 적절하게 갖추고 있는지를 확인하는 인증이지, 신뢰받는 외부 도구(Trivy)의 빌드 파이프라인이 오염되는 사태를 방어하는 기준이 아닙니다. (출처: 와우테일 보도, 2026.03.27)

한 가지 더 짚을 지점이 있습니다. 이번 사건에서 LiteLLM의 인증을 담당했던 곳은 AI 컴플라이언스 자동화 스타트업 Delve였는데, Delve는 3월 22일 전 고객의 폭로로 “실제로는 구현하지 않은 보안 조치를 이행했다고 허위 인증해줬다”는 의혹을 받고 있습니다. (출처: TechCrunch, 2026.03.22) 두 가지가 겹치면서 “보안 인증 = 실제 보안”이라는 등식이 얼마나 허술한지가 드러났습니다.

AI 편의 중심 설계가 만들어낸 구조적 취약점

수십 개 LLM 제공업체의 API 키를 하나의 라이브러리에서 관리하는 구조는 편리하지만, 공격자에게는 올인원 탈취 기회를 줍니다. Sonatype은 이 구조에 대해 “AI 스택의 중앙 게이트웨이 패키지들이 공격자의 새로운 표적이 되고 있다”고 경고했습니다. (출처: Sonatype 보안 분석 리포트, 2026.03.24) 사건 이후 Go 기반의 Bifrost, Rust 기반의 TensorZero, Cloudflare AI Gateway 같은 대안이 거론되기 시작한 것도 이런 배경에서입니다.

▲ 목차로 돌아가기

지금 감염 여부를 직접 확인하는 방법

2026년 3월 24일 UTC 10:39~16:00 사이에 pip install litellm을 실행했거나, 버전 고정 없이 LiteLLM을 의존성으로 당겨오는 프로젝트를 빌드했다면 아래를 확인해야 합니다. Docker 공식 이미지 사용자는 requirements.txt에 버전이 고정돼 있어 영향을 받지 않았고, LiteLLM Cloud 사용자도 마찬가지입니다. (출처: BerriAI 공식 보안 업데이트, 2026.03.24)

버전 및 악성 파일 확인:

# 설치된 버전 확인 (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

감염이 확인됐을 때 해야 할 일:

감염이 확인된 경우 패키지 제거(pip uninstall litellm)와 캐시 삭제(pip cache purge)를 먼저 하고, 백도어 서비스를 비활성화해야 합니다. 그리고 가장 중요한 건 해당 시스템에서 접근 가능했던 모든 인증 정보를 교체하는 것입니다. SSH 키 재생성, 클라우드 인증 정보 회전, API 키 전수 교체, DB 비밀번호 변경, Kubernetes 토큰 재발급까지 포함됩니다. BerriAI는 이를 “사실상 전부 갈아엎어야 하는 수준”이라고 표현했습니다. 패키지를 지우는 것만으로는 충분하지 않습니다. (출처: BerriAI 공식 보안 업데이트 / Datadog Security Research, 2026.03.24)

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

솔직히 말하면, 이번 사건에서 가장 불편한 부분은 LiteLLM 자체의 보안이 허술했다는 게 아닙니다. 보안 스캐너(Trivy)가 공격의 진입로가 됐고, SOC2 인증이 있었어도 아무 소용이 없었으며, 악성코드를 발견한 건 보안 팀이 아니라 컴퓨터가 갑자기 꺼진 연구자였다는 사실입니다.

AI 개발 생태계가 빠르게 커지면서 LiteLLM 같은 “중앙 게이트웨이” 역할을 하는 라이브러리들이 더 많아질 텐데, 이 구조 자체가 다음 공격의 표적이 될 가능성을 이번 사건이 보여줬습니다. 편의성과 보안 사이의 트레이드오프를 다시 생각해봐야 할 시점입니다.

당장 3월 24일 전후에 LiteLLM을 설치한 환경이 있다면, 위에 정리한 확인 절차를 먼저 돌려보시길 권합니다. 패키지 제거만으로는 충분하지 않고, 인증 정보 교체까지 가야 합니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. BerriAI 공식 보안 업데이트 — https://docs.litellm.ai/blog/security-update-march-2026
2. Datadog Security Research Labs 분석 — https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/
3. Sonatype 보안 분석 리포트 — https://www.sonatype.com/blog/compromised-litellm-pypi-package-delivers-multi-stage-credential-stealer
4. FutureSearch 기술 분석 블로그 — https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/
5. 나무위키 2026년 LiteLLM 공급망 공격 사건 — namu.wiki