LiteLLM v1.82.7 / v1.82.8
⚠️ 긴급 보안 사안
LiteLLM 공급망 공격,
안 써도 털렸을 수 있습니다
2026년 3월 24일 오전 10시 39분(UTC), PyPI에 악성코드가 담긴 LiteLLM 패키지가 올라왔습니다. pip install litellm 한 줄로 SSH 키부터 클라우드 인증 정보, AI API 키까지 전부 털리는 구조였습니다. LiteLLM을 직접 사용하지 않더라도, 의존성으로 딸려 들어온 경우라면 마찬가지입니다.
LiteLLM이 뭔데 이게 문제냐
LiteLLM은 미국 스타트업 BerriAI가 만든 오픈소스 Python 라이브러리입니다. OpenAI, Anthropic, Google, AWS Bedrock, Azure 등 100개 이상 LLM 제공업체의 API를 하나로 묶어주는 역할을 합니다. 쉽게 말해, 이걸 하나 설치해두면 어떤 모델 API든 같은 코드로 돌릴 수 있어서 AI 개발자들 사이에서 사실상 표준처럼 쓰이던 라이브러리였습니다.
월간 다운로드 약 9,700만 건, GitHub 스타 40,700개 이상 — 규모만으로도 파급력이 충분합니다. 더 중요한 건, 스탠퍼드의 DSPy, CrewAI, Google ADK 같은 주요 AI 프레임워크들이 LiteLLM을 의존성으로 사용하고 있었다는 점입니다. (출처: 나무위키 2026년 LiteLLM 공급망 공격 사건, 2026.03.27 기준) LiteLLM을 직접 설치한 적이 없어도, 이들 프레임워크 중 하나를 쓰고 있었다면 간접적으로 영향권 안에 있었던 셈입니다. Wiz Research는 클라우드 환경의 약 36%에 LiteLLM이 존재한다는 수치를 발표했는데, 이는 개발자 개인 머신을 제외한 클라우드 인프라 기준입니다. (출처: Wiz Research, 2026.03.24)
여러 LLM API 키를 한 곳에 모아 관리하는 구조라는 게 핵심입니다. 해커 입장에서 보면, 이것 하나를 뚫으면 수십 개 서비스의 API 키를 한꺼번에 가져올 수 있다는 뜻이기도 했습니다.
보안 스캐너가 뚫린 게 시작이었습니다
LiteLLM이 직접 해킹당한 게 아닙니다. 이게 이번 사건에서 가장 까다로운 부분입니다. 공격 그룹 TeamPCP는 먼저 오픈소스 보안 스캐너인 Trivy를 공략했습니다. 2026년 3월 19일, Trivy 저장소의 GitHub Actions 워크플로우 취약점을 이용해 조직 전체의 GitHub 개인 액세스 토큰(PAT)을 탈취했고, Trivy의 GitHub Actions 태그 76개를 악성 버전으로 통째로 갈아치웠습니다.
LiteLLM은 CI/CD 파이프라인에서 보안 점검용으로 Trivy를 쓰고 있었는데, apt-get install -y trivy로 버전을 고정하지 않고 항상 최신 버전을 받아쓰는 방식이었습니다. 변조된 Trivy가 실행되면서 LiteLLM의 PyPI 배포 토큰이 공격자 손에 넘어간 것입니다. (출처: LiteLLM 공식 보안 업데이트, docs.litellm.ai, 2026.03.27) 보안 도구가 오히려 침투 경로가 된 셈입니다.
Datadog Security Labs가 공개한 전체 타임라인을 보면, 이건 LiteLLM만의 사건이 아니었습니다. 같은 캠페인 안에서 npm 패키지 28개 이상, Checkmarx KICS GitHub Action, OpenVSX 확장 2개가 연달아 침해됐고, 3월 27일에는 telephony SDK인 telnyx까지 같은 수법으로 뚫렸습니다. (출처: Datadog Security Labs, securitylabs.datadoghq.com, 2026.03.27)
| 날짜 (UTC) | 대상 및 내용 |
|---|---|
| 2026.02.28 | Trivy 저장소 초기 침투 |
| 2026.03.19 | Trivy GitHub Actions 태그 76개 변조, Docker 이미지 변조 |
| 2026.03.20~22 | npm 패키지 28개 이상 자기전파 웜으로 침해 |
| 2026.03.23 | Checkmarx KICS GitHub Action, OpenVSX 확장 침해 |
| 2026.03.24 | LiteLLM v1.82.7 / v1.82.8 PyPI 침해 |
| 2026.03.27 | telnyx v4.87.1 / v4.87.2 PyPI 침해 |
(출처: Datadog Security Labs, 2026.03.27)
설치만 했는데 왜 실행됐는지 — .pth 파일의 구조
“나는 litellm을 import한 적도 없으니 괜찮겠지”라고 생각했다면, v1.82.8 기준으로는 그게 맞지 않습니다. v1.82.8에는 litellm_init.pth라는 파일이 포함됐습니다. Python의 .pth 파일은 site-packages 디렉토리에 들어가면, Python 인터프리터가 시작될 때 자동으로 실행되는 특성이 있습니다. import 없이도, 함수 호출 없이도, Python이 켜지기만 하면 동작합니다.
v1.82.7: 악성 코드가 proxy_server.py에 삽입되어 있어, import litellm.proxy를 호출할 때 실행됩니다. 즉, 설치 후 관련 모듈을 실제로 사용해야 발동했습니다.
v1.82.8: litellm_init.pth가 site-packages에 포함되어, Python 인터프리터가 실행되는 모든 순간 자동으로 악성 코드가 작동합니다. (출처: FutureSearch.ai 공식 분석, futuresearch.ai, 2026.03.24)
사실 이 .pth 파일의 자동 실행 특성 때문에 역설적으로 사건이 빨리 발각됐습니다. FutureSearch.ai의 엔지니어가 Cursor MCP 플러그인을 테스트하다가 litellm이 간접 의존성으로 설치됐는데, v1.82.8 설치 직후 시스템 메모리가 급격히 고갈되면서 머신이 다운된 겁니다. 조사해보니 .pth 파일이 Python 시작 때마다 자식 프로세스를 생성하고, 그 자식이 또 .pth를 실행하는 포크 폭탄 구조가 되어 있었습니다. 공격자가 의도한 게 아닌, .pth 자동 실행 특성에서 생긴 버그였습니다. 이 버그가 없었다면 발견이 한참 늦어졌을 수도 있습니다.
litellm_init.pth는 34,628바이트 크기에 Base64 이중 인코딩으로 난독화되어 있었고, 디코딩하면 수집→암호화→유출→백도어 설치 순서로 동작하는 332줄짜리 스크립트가 나왔습니다. (출처: FutureSearch.ai 공식 분석, 2026.03.24)
털린 것들의 범위 — 생각보다 훨씬 넓습니다
악성 페이로드가 수집하는 대상 목록을 LiteLLM 공식 보안 업데이트 문서에서 직접 확인했습니다. (출처: docs.litellm.ai/blog/security-update-march-2026, 2026.03.27) 단순히 환경변수 몇 개가 아닙니다.
| 수집 대상 | 구체적 항목 |
|---|---|
| SSH 키 전부 | RSA, Ed25519, ECDSA, DSA, authorized_keys, known_hosts |
| 클라우드 인증 | AWS(IMDS 포함), GCP, Azure 인증 정보 |
| 쿠버네티스 | 서비스 계정 토큰, 모든 네임스페이스 시크릿 |
| CI/CD 파이프라인 | GitLab CI, Jenkins, CircleCI, npm/PyPI 배포 토큰 |
| AI API 키 | OpenAI, Anthropic, Google 등 환경변수에 저장된 키 전부 |
| 기타 | Docker 레지스트리 인증, 셸 히스토리, 암호화폐 지갑 키 |
수집된 데이터는 AES-256-CBC로 암호화한 뒤, 세션 키를 하드코딩된 RSA-4096 공개키로 한 번 더 감싸서 tpcp.tar.gz로 묶어 https://models.litellm.cloud/로 전송됐습니다. 이 도메인은 LiteLLM 공식 도메인(litellm.ai)을 흉내 낸 가짜로, 공격 하루 전인 3월 23일에 등록됐습니다. LiteLLM 공식 인프라와 무관합니다.
여기서 끝이 아닙니다. 감염된 시스템에는 약 50분마다 외부 서버에서 추가 페이로드를 받아 실행하는 백도어도 설치됩니다. Kubernetes 환경이라면 클러스터 안 모든 노드에 권한 있는 파드를 배포해 횡적 이동까지 시도합니다. 패키지를 제거하는 것만으로는 완전한 복구가 안 됩니다.
Docker 이미지 쓰면 안전하다는 말, 절반만 맞습니다
공식 LiteLLM Proxy Docker 이미지(ghcr.io/berriai/litellm)는 requirements.txt에 의존성 버전이 고정되어 있어 이번 공격에 영향을 받지 않았습니다. 사건 당시 이 이미지의 LiteLLM 버전은 1.82.3이었습니다. (출처: LiteLLM 공식 보안 업데이트, 2026.03.27)
그런데 Docker를 쓴다고 전부 안전한 건 아닙니다. 직접 빌드한 Docker 이미지 안에서 pip install litellm을 버전 고정 없이 실행했다면 이야기가 달라집니다. 3월 24일 10:39~16:00 UTC 사이에 빌드된 이미지라면 감염 버전이 들어갔을 가능성이 있습니다. 공식 이미지를 그대로 쓴 경우와, 자체 빌드 과정에서 litellm을 설치한 경우는 반드시 구분해서 확인해야 합니다.
DSPy는 litellm을 litellm>=1.64.0으로 느슨하게 잡고 있어 감염 버전이 그대로 딸려 들어올 수 있었고, 긴급 PR로 <=1.82.6으로 고정했습니다. 이게 바로 >= 형태의 느슨한 의존성이 실제로 어떤 피해로 이어지는지 보여준 사례입니다. (출처: 나무위키 2026년 LiteLLM 공급망 공격 사건)
CrewAI는 당일 LiteLLM 의존성을 아예 제거하고 네이티브 SDK로 전환하겠다고 선언했습니다. Google ADK도 LiteLLM 의존성 유지 여부를 재검토하기 시작했습니다. 편의성과 보안 사이에서 하나의 라이브러리가 수십 개 서비스의 API 키를 모아 관리하는 구조가 얼마나 위험할 수 있는지, 이번 사건이 그 실물을 보여줬습니다.
지금 당장 해야 할 확인 3단계
3월 24일 오전에 litellm을 설치하거나 업그레이드한 적이 있다면, 아래 순서대로 점검하세요. 공식 보안 업데이트 문서에 나온 내용을 기준으로 정리했습니다. (출처: docs.litellm.ai/blog/security-update-march-2026)
pip show litellm | grep Version
Version이 1.82.7 또는 1.82.8이면 즉시 다음 단계로. 그 외 버전은 공식 SHA-256 체크섬으로 별도 확인 가능합니다. (v1.82.6 이하는 공식적으로 안전 확인됨)
# .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, checkmarx.zone으로의 아웃바운드 트래픽이 있었는지도 확인하세요.
감염이 확인됐다면 해당 환경에 있던 인증 정보 전체를 교체해야 합니다. SSH 키 재생성, AWS/GCP/Azure 액세스 키 회전, 모든 API 키(OpenAI, Anthropic 등) 재발급, DB 비밀번호 변경이 대상입니다. 패키지를 지우는 것만으로는 끝나지 않습니다. 이미 데이터가 외부로 나갔을 수 있기 때문입니다.
pip install "litellm==1.82.6" — 공식 SHA-256 체크섬 확인 버전입니다.
이번 사건이 남긴 구조적인 문제
이번 공격에서 TeamPCP는 hackerbot-claw라는 AI 에이전트를 공격 타겟팅에 활용한 것으로 알려졌습니다. 이 에이전트가 약 47,000개의 저장소를 자동으로 스캔하며 취약한 GitHub Actions 워크플로우를 찾아냈다고 합니다. (출처: 나무위키 2026년 LiteLLM 공급망 공격 사건) AI가 AI 인프라를 공격하는 데 쓰인 셈인데, 이건 기존 공급망 공격에서 보기 어려웠던 방식입니다. 자동화된 취약점 탐색이 이 규모로 가능해졌다는 걸 보여줍니다.
Trivy가 보안 스캐너였기 때문에 LiteLLM 팀은 오히려 버전 고정 없이 최신 버전을 써도 된다고 판단했을 가능성이 높습니다. 보안 도구라면 믿어도 된다는 전제 자체가 이번 공격의 진입 경로였습니다. CI/CD 파이프라인에서 사용하는 도구라면 보안 도구라도 버전을 고정해야 한다는 게, 이번 사건이 실물로 보여준 교훈입니다.
이번 사건 이후 Go 기반 Bifrost, Rust 기반 TensorZero, Cloudflare AI Gateway 같은 LiteLLM 대안이 거론되기 시작했습니다. 하나의 라이브러리가 수십 개 LLM 제공업체의 API 키를 모아 관리하는 편리한 구조가 동시에 가장 큰 위험이 될 수 있다는 인식이 커졌습니다. 편의성을 위해 단일 라이브러리에 너무 많은 민감 정보가 집중되는 구조는 다시 생각해볼 필요가 있습니다. CrewAI가 당일 LiteLLM을 걷어내고 네이티브 SDK 전환을 선언한 것도 같은 맥락입니다.
PyPI의 보안 권고 PYSEC-2026-2, SNYK-PYTHON-LITELLM-15762713이 발행됐지만, 전통적인 CVE는 할당되지 않았습니다. 코드 자체의 취약점이 아니라 인증 정보 탈취를 통한 공급망 침해이기 때문입니다. CVE가 없다는 이유로 자동 탐지 도구가 걸러내지 못하는 경우도 있었습니다.
자주 묻는 질문
마치며
솔직히 말하면, 이번 사건은 개발 환경 보안의 민낯을 드러냈습니다. LiteLLM을 신뢰한 건 개발자의 잘못이 아닙니다. 월 9,700만 건 다운로드에 주요 AI 프레임워크의 핵심 의존성이었고, GitHub 스타도 4만 개가 넘는 검증된 오픈소스였으니까요.
문제는 구조 자체였습니다. 여러 LLM API 키를 한 곳에 모으는 편리함이, 뚫렸을 때 AI 서비스 인프라 전체가 한꺼번에 노출되는 단일 실패 지점이 됐습니다. 보안 도구(Trivy)가 오히려 진입점이 된 것도, 버전 고정 없는 의존성 관리가 실제 피해로 이어진 것도, 이번 사건이 보여준 구조적 취약점입니다.
공식 문서 기준으로 v1.82.6 이하는 안전이 확인됐습니다. 아직 점검하지 않은 환경이 있다면, 지금 바로 pip show litellm 먼저 실행해보세요. 거기서 시작하면 됩니다.
- LiteLLM 공식 보안 업데이트 (2026.03.27) — docs.litellm.ai/blog/security-update-march-2026
- Datadog Security Labs 분석 (2026.03.27) — securitylabs.datadoghq.com
- FutureSearch.ai 최초 발견 보고서 (2026.03.24) — futuresearch.ai/blog/litellm-pypi-supply-chain-attack
- 나무위키 — 2026년 LiteLLM 공급망 공격 사건 (2026.03.27) — namu.wiki
- AlphaMatch.ai — The LiteLLM Supply Chain Attack (2026.03.25) — alphamatch.ai
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. LiteLLM(v1.82.7·v1.82.8 기준, 2026.03.24).
보안 사안은 공식 채널(LiteLLM 공식 업데이트)에서 최신 내용을 직접 확인하시기 바랍니다.
댓글 남기기