LiteLLM v1.82.7~1.82.8
보안 사고
LiteLLM 공급망 공격, 3시간에 이렇게 뚫렸습니다
월 9,500만 다운로드의 AI 라이브러리가 단 3시간 만에 뚫렸습니다. 2026년 3월 24일 오전, LiteLLM v1.82.7과 v1.82.8이 PyPI에 올라오면서 SSH 키·클라우드 자격증명·쿠버네티스 토큰이 한꺼번에 탈취됐습니다. CrewAI, DSPy, Browser-Use 등 주요 AI 프레임워크가 모두 이 라이브러리를 의존성으로 쓰고 있어 파급 범위가 상당합니다.
LiteLLM이 뭐길래 이게 문제인가
LiteLLM은 미국 스타트업 BerriAI가 만든 오픈소스 Python 라이브러리입니다. OpenAI, Anthropic, Google, AWS Bedrock, Azure 등 100개 이상의 LLM 공급자 API를 하나의 프록시 게이트웨이로 묶어주는 역할을 합니다. GitHub 스타 40,700개를 넘겼고, Stanford의 DSPy·CrewAI·Google ADK 같은 주요 AI 프레임워크들이 이 라이브러리를 직접 의존성으로 쓰고 있습니다. (출처: Datadog Security Research, 2026.03.25)
구조적으로 봤을 때 이 라이브러리가 위험한 이유가 있습니다. 여러 LLM 공급자의 API 키를 한 곳에 모아서 관리하는 구조이기 때문에, 여기 하나만 뚫리면 AWS·GCP·Azure·OpenAI·Anthropic 키가 한 번에 털릴 수 있습니다. 해커 입장에서는 최고의 타깃입니다.
💡 공식 발표문과 실제 의존성 구조를 같이 보니 이런 흐름이 보였습니다 — CrewAI(월 590만 다운로드), Browser-Use(월 420만 다운로드), DSPy(월 160만 다운로드) 등 주요 AI 에이전트 프레임워크들이 모두 LiteLLM을 의존성으로 가져가고 있어, 직접 LiteLLM을 설치하지 않은 프로젝트도 간접적으로 감염될 수 있었습니다.
Wiz Research의 분석에 따르면 LiteLLM이 전체 클라우드 환경의 36%에 설치돼 있습니다. (출처: Wiz Research, 2026.03.24) 하루 다운로드 수가 약 3,400만 건임을 감안하면, 3시간 노출만으로도 수백만 건 이상의 설치가 이뤄졌을 가능성이 있습니다.
공격은 Trivy에서 시작됐습니다
이번 LiteLLM 사고는 단독 사건이 아닙니다. TeamPCP라는 해킹 그룹이 2026년 2월 말부터 연속적으로 진행한 공급망 공격 캠페인의 일환입니다. 출발점은 Aqua Security의 보안 스캐너 Trivy였습니다. (출처: Datadog Security Research, 2026.03.25)
| 날짜 | 피해 대상 |
|---|---|
| 2026.02.28 | Trivy 저장소 초기 침투 |
| 2026.03.19 | Trivy GitHub Actions 태그 76개 변조 / Docker 이미지 교체 |
| 2026.03.20 | npm 패키지 28개 이상 탈취 |
| 2026.03.21 | Checkmarx KICS GitHub Action 침해 |
| 2026.03.24 | LiteLLM PyPI 패키지 v1.82.7·v1.82.8 악성 업로드 |
LiteLLM은 CI/CD 보안 스캔에 Trivy를 사용하고 있었는데, 버전을 고정하지 않고 최신 버전을 자동으로 받아오는 방식이었습니다. 이미 변조된 Trivy가 실행되면서 LiteLLM의 PyPI 배포 토큰이 공격자 손에 넘어갔고, 결국 하나의 Trivy 침해가 LiteLLM 침해로 이어졌습니다. (출처: LiteLLM 공식 보안 공지, docs.litellm.ai, 2026.03.26)
v1.82.8이 더 무서운 이유
v1.82.7은 litellm/proxy/proxy_server.py에 악성 코드가 삽입돼 있어, 해당 모듈을 import할 때 실행됩니다. 그런데 13분 뒤 올라온 v1.82.8은 차원이 다릅니다. litellm_init.pth라는 파일이 추가됐는데, Python의 .pth 파일은 인터프리터 시작 시 자동 실행되는 속성을 가집니다. (출처: Python 공식 문서, site 모듈)
⚠️ v1.82.8의 핵심 위험
import litellm을 명시적으로 쓰지 않아도, 그 환경에서 Python이 실행되는 순간 악성 코드가 함께 실행됩니다. pytest 실행, pip install 명령어, 심지어 단순 python 실행만으로도 즉시 정보 유출이 시작됩니다.
악성 코드의 수집 대상 목록을 직접 확인해보면 범위가 상당히 넓습니다.
- SSH 키 전체 (RSA, Ed25519, ECDSA, DSA 등)
- AWS, GCP, Azure 클라우드 자격증명
- Kubernetes 서비스 계정 토큰 및 모든 네임스페이스 시크릿
- Docker 레지스트리 인증정보 (
~/.docker/config.json) - GitLab CI, Jenkins, CircleCI 설정 파일, npm/PyPI 토큰
- DB 패스워드(PostgreSQL, MySQL, Redis), 암호화폐 지갑 키
- 환경변수 전체 (
printenv전량), 쉘 히스토리
수집된 데이터는 AES-256-CBC로 암호화한 뒤, 세션 키를 RSA-4096 공개키로 한 번 더 감싸서 models.litellm.cloud로 전송됩니다. 공격자만 RSA 개인 키를 갖고 있어 탈취된 데이터는 복호화가 불가능합니다. (출처: FutureSearch 기술 분석, futuresearch.ai, 2026.03.24)
공식 Docker 이미지 사용자는 피해 없습니다
여기서 많은 분들이 놓치는 부분이 있습니다. LiteLLM 공식 Docker 이미지(ghcr.io/berriai/litellm)를 사용하는 환경은 이번 사고에 영향을 받지 않았습니다. (출처: LiteLLM 공식 보안 공지, docs.litellm.ai, 2026.03.26)
💡 공식 문서와 실제 배포 패턴을 같이 놓고 보니 이런 차이가 보였습니다 — 공식 Docker 이미지는 requirements.txt에서 LiteLLM 버전을 고정(pin)해서 관리합니다. 사고 당시 최신 Docker 이미지의 LiteLLM 버전은 v1.82.3이었고, 이 고정 방식이 있었기에 악성 v1.82.7·v1.82.8이 자동으로 끌려들어오지 않았습니다.
즉, 버전을 고정하지 않고 litellm>=1.79.2처럼 느슨하게 설정한 프로젝트들이 이번 사고에서 취약했습니다. Comet의 사고 대응 보고서에 따르면, poetry.lock이나 uv.lock을 쓴 프로젝트는 완전히 보호됐습니다. (출처: Comet 사고 대응 리포트, comet.com, 2026.03.25)
LiteLLM Cloud 사용자, v1.82.6 이하 버전 고정 사용자, GitHub 소스 직접 설치 사용자도 피해가 없었습니다. 이 세 경우는 악성 버전이 PyPI를 통해서만 배포됐기 때문입니다.
보안 스캐너가 공격 입구가 됐습니다
이번 사고에서 생각해볼 만한 지점이 있습니다. 공격 경로가 된 도구가 보안 스캐너 Trivy라는 사실입니다. LiteLLM은 CI/CD 파이프라인 보안을 위해 Trivy를 사용하고 있었는데, 바로 그 도구가 공격의 발판이 됐습니다.
💡 타임라인을 거꾸로 읽어보면 이런 흐름이 보입니다 — TeamPCP는 Trivy GitHub Actions 태그 76개를 통째로 변조했고, LiteLLM의 CI/CD 스크립트(ci_cd/security_scans.sh)는 apt-get install -y trivy 방식으로 버전을 고정하지 않고 설치하고 있었습니다. 보안을 위해 사용한 도구가, 보안을 고정하지 않아서 뚫리는 구조였습니다.
GitHub Actions를 태그로 참조하는 것도 이번에 드러난 약점입니다. 태그는 가변적이라 공격자가 기존 태그에 악성 코드를 force-push할 수 있습니다. Trivy Action v0.35.0은 GitHub의 불변 릴리스 보호 덕분에 유일하게 살아남았습니다. 나머지 모든 태그는 변조됐습니다. (출처: Datadog Security Research, 2026.03.25)
이번 사고를 계기로 Andrej Karpathy(전 OpenAI 공동 창립 멤버, 전 Tesla AI 디렉터)는 “software horror”라고 표현했습니다. 개발 도구 생태계 전반에 대한 신뢰 문제가 됐다는 의미입니다.
지금 당장 해야 할 것 3가지
감염 여부 확인 방법은 아래 세 가지입니다. 2026년 3월 24일 오전 10:39~오후 4:00(UTC) 사이에 LiteLLM을 설치하거나 업그레이드했다면 즉시 확인이 필요합니다.
① 설치 버전 확인
pip show litellm | grep Version
Version이 1.82.7 또는 1.82.8이면 감염 환경입니다.
② 악성 .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
감염이 확인됐다면 순서대로 진행해야 합니다.
패키지 제거 + 캐시 삭제
pip cache purge 또는 rm -rf ~/.cache/uv로 캐시된 wheel까지 제거해야 합니다.
모든 자격증명 즉시 교체
SSH 키 재생성, 클라우드 액세스 키 로테이션, API 키 전량 교체. 하나라도 남기면 안 됩니다.
CI/CD 파이프라인 감사
GitHub Actions 실행 로그에서 Downloading litellm-1.82.7 또는 litellm-1.82.8 문자열을 검색합니다.
안전한 버전으로 다운그레이드할 때는 pip install "litellm<=1.82.6"을 사용합니다. (출처: LiteLLM 공식 보안 공지, docs.litellm.ai, 2026.03.26)
AI 에이전트로 AI 인프라를 공격했습니다
이번 사고에서 잘 알려지지 않은 부분이 있습니다. TeamPCP는 hackerbot-claw라는 AI 에이전트를 공격 타깃팅에 활용한 것으로 알려졌습니다. 이 에이전트는 약 47,000개의 저장소를 스캔하며 취약한 GitHub Actions 워크플로우를 자동으로 찾아냅니다. AI 인프라를 공격하는 데 AI 에이전트를 쓴 셈입니다. (출처: 나무위키 2026 LiteLLM 공급망 공격 사건 문서, 2026.03.27)
💡 공격 도구와 피해 대상을 같이 보니 이런 구도가 보였습니다 — AI 에이전트 개발자들이 가장 많이 쓰는 오픈소스 라이브러리를, AI 에이전트를 동원해 공격했습니다. 공격 자동화의 방향이 일반 소프트웨어가 아닌 AI 생태계 자체를 향하기 시작했습니다.
사고 수습 과정에서도 흥미로운 지점이 있었습니다. 이 사건이 조기에 발각된 건 공격자의 실수 덕분이었습니다. FutureSearch.ai의 Callum McMahon이 Cursor의 MCP 플러그인을 테스트하다가 LiteLLM이 간접 의존성으로 설치됐고, v1.82.8 설치 직후 시스템 메모리가 급격히 고갈되면서 머신이 다운됐습니다. .pth 파일이 Python 시작 때마다 자식 프로세스를 생성하는데, 그 자식 프로세스가 다시 .pth를 실행하는 포크 폭탄 버그가 있었던 것입니다. 이 버그가 없었다면 발견이 훨씬 늦었을 수 있습니다. (출처: FutureSearch 기술 분석, futuresearch.ai, 2026.03.24)
사고 발견 이후 TeamPCP는 73개의 봇 계정을 동원해 88개의 스팸 댓글을 102초 만에 GitHub 이슈에 쏟아부어 보고서를 묻으려 했습니다. 탈취한 관리자 계정으로 이슈를 강제 닫기까지 했습니다. 그러나 Hacker News에 이미 관련 스레드가 올라온 뒤였기 때문에 은폐에는 실패했습니다.
자주 묻는 질문
LiteLLM Cloud 유료 서비스를 쓰는 경우도 피해를 봤나요?
▼
CrewAI, DSPy를 쓰는데 LiteLLM을 직접 설치하지 않았어도 감염될 수 있나요?
▼
litellm<=1.82.6으로 고정했습니다. (출처: Comet 사고 대응 리포트, 2026.03.25)
GitHub Actions에서 Trivy를 쓰고 있습니다. 지금도 위험한가요?
▼
uses: aquasecurity/trivy-action@v0.35.0 또는 커밋 SHA로 사용하세요. (출처: Datadog Security Research, 2026.03.25)
피해 환경에서 버전만 다운그레이드하면 안전한가요?
▼
~/.config/systemd/user/sysmon.service)와 지속성 스크립트(~/.config/sysmon/sysmon.py)를 별도로 제거해야 합니다. 또한 감염 환경에 있던 모든 자격증명은 이미 유출됐을 수 있어, 반드시 전량 교체가 필요합니다. (출처: docs.litellm.ai, 2026.03.26)
LiteLLM 대신 쓸 수 있는 대안이 있나요?
▼
마치며
솔직히 말하면, 이번 LiteLLM 사고에서 가장 무서운 건 악성코드 자체보다 구조적인 취약점입니다. “여러 LLM API 키를 한 곳에 모아서 편리하게” — 그 편의성 뒤에 “한 번 뚫리면 전부 털린다”는 리스크가 있었습니다. 편의성과 보안의 트레이드오프를 제대로 따져보지 않은 설계였습니다.
더불어 보안 스캐너가 공격 벡터가 됐다는 점, 그리고 AI 에이전트가 공격 자동화에 쓰였다는 점은 2026년의 위협 환경이 달라졌음을 보여줍니다. 이제 CI/CD에 쓰이는 모든 도구 — 보안 스캐너 포함 — 도 공급망 공격 대상이 됩니다.
당장 할 수 있는 조치는 간단합니다. 의존성 버전 고정(lockfile), GitHub Actions를 SHA로 참조, CI/CD 시크릿 스코프 최소화. 이 세 가지만 제대로 돼 있었어도 이번 사고의 절반은 막을 수 있었습니다.
본 포스팅 참고 자료
- LiteLLM 공식 보안 공지 — docs.litellm.ai/blog/security-update-march-2026
- Datadog Security Research 분석 — securitylabs.datadoghq.com
- FutureSearch 기술 분석 — futuresearch.ai/blog/litellm-pypi-supply-chain-attack/
- Comet 사고 대응 리포트 — comet.com/site/blog/litellm-supply-chain-attack/
- Python site 모듈 공식 문서 — docs.python.org/3/library/site.html
본 포스팅은 2026년 3월 27일 기준으로 작성됐습니다. LiteLLM을 포함한 관련 서비스·정책·보안 권고 내용은 이후 업데이트로 달라질 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으며, 최신 정보는 공식 채널을 통해 확인하시길 권장합니다.
댓글 남기기