pip install litellm 한 번으로 SSH 키가 털렸다 — 2026 공급망 공격 분석 : 보안 도구가 감염 벡터가 되다

안녕하세요! 갓대희 입니다.

 

AI API 키를 한곳에서 관리해 주는 패키지가, 그 API 키를 전부 훔쳐 갔다.

 

2026년 3월 24일, 월 9,500만 다운로드의 Python 패키지 LiteLLM에 악성코드가 심어졌다. 설치만 해도 SSH 키, 클라우드 인증 정보, .env 파일, 암호화폐 지갑까지 전부 수집해서 외부로 전송한다. 쿠버네티스 클러스터에서는 모든 노드에 관리자 권한 컨테이너를 심는다. 재부팅해도 살아남는 백도어까지 설치한다.

이 글에서는 검증된 보안 리포트(Wiz, Endor Labs, FutureSearch, The Hacker News)를 기반으로 사건의 전모, 악성코드의 기술적 구조, 영향 범위, 그리고 지금 당장 해야 할 대응 방법을 정리한다.

목차

1. 사건 개요 — 무슨 일이 벌어졌는가
2. TeamPCP 연쇄 공격 타임라인
3. 감염 경로 — 보안 도구가 감염 벡터가 되다
4. 악성코드 기술 분석 — 3단계 공격 구조
5. 발견 경위 — 악성코드의 버그가 구한 세상
6. 영향 범위 — 내가 위험한가?
7. 지금 당장 해야 할 대응 방법
8. 교훈 — 바이브 코딩 시대의 공급망 보안
9. 트러블슈팅 Q&A
10. 결론

LiteLLM 공급망 공격 요약 (2026-03-24)

공격자	TeamPCP
감염 버전	1.82.7, 1.82.8
감염 경로	Trivy CI/CD 공급망 공격 → PyPI 토큰 탈취 → 악성 버전 배포
악성코드 행위	인증 정보 수집 → AES-256 + RSA-4096 암호화 후 외부 전송 → 영구 백도어 설치
영향 범위	월 9,500만 다운로드, 클라우드 환경의 36%에 존재 (Wiz 추정)
현재 상태	감염 버전 제거됨. PyPI 전체 패키지 격리 중 (신규 설치 불가). BerriAI 릴리스 중단 상태 (2026-03-26 기준)

(출처: Wiz Research, FutureSearch, Endor Labs)

 

1. 사건 개요 — 무슨 일이 벌어졌는가

LiteLLM이 뭔가

LiteLLM은 BerriAI가 만든 오픈소스 Python 라이브러리이자 프록시 서버다. OpenAI, Anthropic, Google, Azure, AWS Bedrock 등 100개 이상의 LLM 서비스를 하나의 OpenAI 호환 인터페이스로 통합한다. 기업 입장에서는 여러 AI 서비스의 API 키를 한곳에서 관리하면서 모델을 자유롭게 전환할 수 있다.

문제는 이 편의성이 공격자에게도 매력적이라는 것이다. LiteLLM이 설치된 서버에는 기업이 사용하는 모든 AI 서비스의 API 키가 집중되어 있다. 열쇠를 보관하는 금고를 하나 뚫으면, 금고 안의 모든 열쇠가 유출 대상이 된다.

항목	내용
패키지	litellm (PyPI)
GitHub	BerriAI/litellm (Stars: 40,369개, 2026-03-25 기준)
월 다운로드	약 9,500만 회 (일 340만 회 이상)
클라우드 보급률	전체 클라우드 환경의 36%에 존재 (Wiz 데이터)
역할	100+ LLM 서비스를 OpenAI 호환 포맷으로 통합하는 게이트웨이

(출처: Wiz Research, 2026-03-24)

 

어떤 일이 벌어졌나

2026년 3월 24일, LiteLLM의 악성 버전 1.82.7(10:39 UTC)과 1.82.8(10:52 UTC)이 PyPI에 업로드되었다. GitHub에는 대응하는 태그나 릴리스가 없었다. 정상적인 릴리스 프로세스를 우회하여 PyPI에 직접 업로드된 것이다.

두 버전의 감염 메커니즘은 다르다

1.82.8에는 litellm_init.pth 파일이 포함되어 있다. Python의 .pth 파일은 인터프리터 시작 시 자동 실행된다. import litellm을 호출할 필요 없이, Python을 실행하기만 하면 악성코드가 작동한다.

1.82.7은 .pth 대신 proxy_server.py에 악성코드가 삽입되어, import litellm.proxy 시에 트리거된다. 프록시 서버를 실행하지 않으면 트리거되지 않지만, LiteLLM을 프록시로 사용하는 환경(대부분의 기업 환경)에서는 동일하게 위험하다.

(출처: LiteLLM 공식 대응 Issue #24518)

FutureSearch가 PyPI에 최초 신고했고, PyPI가 격리(quarantine) 조치했다. LiteLLM 공식 보안 공지에 따르면 영향 시간대는 10:39 UTC ~ 16:00 UTC (약 5시간 20분)이다. 감염 버전은 제거되었으며, 2026년 3월 26일 현재 litellm 전체 패키지가 PyPI에서 격리 중이어서 어떤 버전도 pip install litellm으로 설치할 수 없는 상태다. BerriAI는 공급망 검토가 완료될 때까지 새 릴리스를 중단했다.

(출처: FutureSearch, 2026-03-24)

 

2. TeamPCP 연쇄 공격 타임라인

이 사건은 단독 범행이 아니다. TeamPCP라는 공격 그룹이 보안 도구를 연쇄적으로 공격하며 신뢰 체인을 타고 올라간 계획적 캠페인이다.

날짜	대상	유형	설명
3월 19일	Trivy (Aqua Security)	보안 취약점 스캐너	trivy-action의 77개 태그 중 76개를 악성 커밋으로 교체. CI/CD 파이프라인의 인증 정보를 수집하는 악성 페이로드 삽입
3월 23일	KICS (Checkmarx)	IaC 보안 스캐너	KICS GitHub Action을 12:58~16:50 UTC 사이에 감염. 해당 시간대에 이 Action을 사용한 모든 CI/CD에 악성코드 실행
3월 24일	LiteLLM (BerriAI)	AI 게이트웨이	감염된 Trivy를 CI/CD에서 사용하던 LiteLLM의 PyPI 토큰이 탈취됨. 악성 버전 1.82.7, 1.82.8 직접 배포

패턴이 보인다. 보안 도구를 먼저 감염시키고, 그 보안 도구를 사용하는 다음 타겟의 인증 정보를 수집하여 연쇄 공격을 이어간다. Wiz에 따르면 TeamPCP는 GitHub Actions, Docker Hub, npm, Open VSX, PyPI 등 5개 패키지 생태계에 걸쳐 공격을 확장했다.

공급망 공격의 핵심: 신뢰 체인 악용

일반적인 해킹은 방화벽이나 인증 시스템을 뚫는다. 공급망 공격은 이미 신뢰받는 도구 자체를 감염시킨다. CI/CD 파이프라인에서 "보안 스캐너"로 등록된 Trivy가 감염되면, 보안 스캐너를 실행하는 행위 자체가 인증 정보 유출 행위가 된다. 보안 도구가 감염 벡터가 되는 아이러니다.

(출처: Wiz - KICS Compromise, The Hacker News)

 

3. 감염 경로 — 보안 도구가 감염 벡터가 되다

LiteLLM의 CI/CD 파이프라인에는 Trivy가 보안 취약점 스캔 도구로 등록되어 있었다. 정상적이라면 코드 푸시 때마다 Trivy가 취약점을 검사하고, 문제가 없으면 빌드를 통과시키고, PyPI에 배포하는 흐름이다.

문제는 3월 19일부터 Trivy 자체가 감염된 상태였다는 것이다.

## 공격 흐름 (재구성)

1. TeamPCP가 Trivy GitHub Action의 태그 76/77개를 악성 커밋으로 교체
2. 감염된 Trivy가 CI/CD에서 실행될 때 환경변수(PyPI 토큰 포함)를 수집
3. LiteLLM의 CI/CD에서 감염된 Trivy가 실행됨
4. LiteLLM의 PyPI API 토큰이 TeamPCP에 전달됨
5. TeamPCP가 탈취한 토큰으로 PyPI에 악성 버전을 직접 업로드
6. GitHub 릴리스 없이 PyPI에만 1.82.7, 1.82.8 배포

PyPI advisory에서도 Trivy 사건에서 노출된 API 토큰이 근본 원인이라고 확인했다. LiteLLM 관리자가 직접 공격당한 것이 아니라, LiteLLM이 의존하고 있던 보안 도구(Trivy)가 먼저 감염되어 인증 정보가 유출된 것이다.

(출처: Wiz Research — "An PyPI advisory has been posted, identifying an API token exposed via the prior Trivy incident as the root cause")

 

4. 악성코드 기술 분석 — 3단계 공격 구조

악성 litellm_init.pth 파일이 Python 인터프리터 시작 시 자동으로 실행하는 페이로드는 3단계로 구성된다.

 

Stage 1: 수집 (Collection)

호스트 시스템에서 민감한 파일과 정보를 광범위하게 수집한다.

수집 대상	구체적 파일/경로
SSH 키	~/.ssh/ (개인키, 설정 파일)
클라우드 인증 정보	AWS credentials, GCP ADC, Azure 토큰
쿠버네티스 설정	~/.kube/config, 서비스 어카운트 토큰
환경 변수 파일	.env 파일 (API 키, DB 비밀번호 포함)
암호화폐 지갑	일반적인 지갑 파일 패턴 매칭
Git 설정	.gitconfig (토큰, 인증 정보)
쉘 히스토리	.bash_history, .zsh_history
데이터베이스 비밀번호	설정 파일 내 비밀번호 패턴
Slack / Discord 토큰	채팅 서비스 인증 토큰 (OX Security 분석)
클라우드 메타데이터	IMDS 엔드포인트, 컨테이너 자격증명 조회

환경변수 덤프와 클라우드 메타데이터 엔드포인트(IMDS, 컨테이너 자격증명) 쿼리까지 수행한다. 즉 파일 시스템과 런타임 환경 양쪽에서 인증 정보를 수집한다.

 

Stage 2: 유출 (Exfiltration)

수집된 데이터를 외부로 전송한다.

• 수집 데이터를 AES-256-CBC로 암호화 (랜덤 세션 키 사용)
• 세션 키를 하드코딩된 4096-bit RSA 공개키로 암호화
• 전체를 tar 아카이브로 묶어 https://models.litellm.cloud/로 POST 전송

models.litellm.cloud는 LiteLLM 공식 인프라가 아니다

도메인 이름이 litellm.cloud를 포함하고 있어 공식 서버처럼 보이지만, LiteLLM의 정상적인 인프라와 무관한 공격자가 등록한 도메인이다. 방화벽 규칙에서 이 도메인으로의 아웃바운드 트래픽을 즉시 차단해야 한다.

 

Stage 3: 지속성 확보 (Persistence)

환경에 따라 두 가지 경로로 영구 백도어를 설치한다.

쿠버네티스 환경:

• 서비스 어카운트 토큰이 있으면 모든 네임스페이스의 시크릿을 읽는다
• kube-system의 모든 노드에 특권(privileged) alpine:latest 컨테이너를 생성한다
• 각 컨테이너가 호스트 파일시스템을 마운트하고 백도어를 설치한다

로컬 머신:

• /root/.config/sysmon/sysmon.py 또는 ~/.config/sysmon/sysmon.py에 백도어 설치
• systemd user service로 등록하여 재부팅 후에도 자동 실행
• 백도어는 checkmarx[.]zone/raw를 50분 간격으로 폴링하여 추가 바이너리를 다운로드한다 — 공격자가 나중에 추가 페이로드를 배포할 수 있다

# 백도어 설치 경로 확인 명령어
ls -la ~/.config/sysmon/sysmon.py
ls -la ~/.config/systemd/user/sysmon.service

# 쿠버네티스 환경에서 의심스러운 Pod 확인
kubectl get pods -n kube-system | grep node-setup

(출처: FutureSearch, 2026-03-24 — 3단계 페이로드 기술 분석)

 

5. 발견 경위 — 악성코드의 버그가 구한 세상

이 사건의 발견 경위가 흥미롭다. FutureSearch 팀이 Cursor 에디터에서 MCP 플러그인을 사용하던 중, LiteLLM이 간접 의존성(transitive dependency)으로 자동 설치되었다. 직접 설치한 것이 아니다.

그런데 갑자기 시스템 메모리(RAM)가 전부 소진되면서 머신이 멈췄다.

원인은 악성코드의 버그였다. .pth 파일은 Python 인터프리터 시작 시마다 실행되는데, 이 악성 .pth가 subprocess.Popen으로 자식 Python 프로세스를 생성한다. 자식 프로세스가 시작되면 다시 .pth가 실행되고, 또 자식 프로세스를 생성하고... 지수적으로 프로세스가 복제되는 포크 폭탄(fork bomb)이 발생한 것이다.

아이러니: 악성코드의 버그가 없었으면 발견이 훨씬 늦었을 것이다

의도된 동작대로였다면 악성코드는 조용히 인증 정보를 수집하고, 조용히 전송하고, 조용히 백도어를 설치했을 것이다. 포크 폭탄은 공격자의 실수다. 이 실수가 시스템을 폭주시켰고, FutureSearch 개발자가 원인을 추적하면서 악성코드가 발견되었다. 10:39 UTC에 첫 배포가 시작되었다. LiteLLM 공식 보안 공지에 따르면 영향 시간대는 10:39 UTC ~ 16:00 UTC (약 5시간 20분)이다. 버그가 없었다면 이 시간은 훨씬 길어졌을 것이다.

(출처: FutureSearch — "The fork bomb is actually a bug in the malware")

 

6. 영향 범위 — 내가 위험한가?

직접 설치하지 않아도 위험하다

LiteLLM은 본인이 직접 pip install litellm하지 않아도 다른 도구의 의존성으로 자동 설치되는 경우가 많다. 대표적인 경로는 다음과 같다.

• MCP 플러그인 — Cursor, Claude Code 등에서 사용하는 MCP 플러그인이 의존성으로 설치
• AI 에이전트 프레임워크 — LangChain, CrewAI 등 LLM 오케스트레이션 도구
• LLM 게이트웨이/프록시 — 여러 AI 모델을 관리하는 서버 환경
• 바이브 코딩 도구 체인 — AI 코딩 에이전트가 자동으로 설치하는 패키지

 

영향받지 않는 경로

다음 경우에는 이번 사건의 영향을 받지 않는다

• LiteLLM 공식 Proxy Docker 이미지를 사용한 경우 (PyPI 패키지가 아닌 이미지 기반)
• LiteLLM Cloud (호스팅 서비스) 사용자
• 소스에서 직접 설치한 경우 (GitHub clone → pip install -e .)
• litellm 1.82.6 이하를 사용 중이고, 3월 24일 이후 업그레이드하지 않은 경우

(출처: LiteLLM 공식 보안 공지)

 

GitHub 계정 탈취까지

TeamPCP는 LiteLLM 관리자(BerriAI)의 GitHub 계정까지 탈취한 것으로 보인다. GitHub에 "teampcp owns BerriAI"라는 메시지를 남겼다. 이 사건을 신고한 GitHub Issue #24512를 "not planned"으로 닫아 버렸으며, 수백 개의 봇 댓글로 토론을 희석시키려 했다.

BerriAI 대응 현황 (2026-03-26 기준)

• 관리자 계정 전체 교체 — 새 계정(@krrish-berri-2, @ishaan-berri)으로 전환
• PyPI 토큰 폐기 — 탈취된 PYPI_PUBLISH_PASSWORD 시크릿 무효화
• 새 릴리스 중단 — 공급망 전체 검토 완료 시까지 배포 일시 중지
• Trusted Publishers(OIDC) 마이그레이션 — 토큰 기반 배포에서 OIDC 기반으로 전환 논의 중 (Issue #24542)

(출처: LiteLLM 공식 보안 공지, Issue #24518)

확인 방법

지금 터미널을 열고 아래 명령어를 실행한다.

# 1. litellm 설치 여부 및 버전 확인
pip show litellm

# 2. uv 캐시에 감염 파일이 있는지 확인
find ~/.cache/uv -name "litellm_init.pth" 2>/dev/null

# 3. 가상환경에서 확인
find . -path "*/site-packages/litellm_init.pth" 2>/dev/null

# 4. 백도어 존재 확인
ls -la ~/.config/sysmon/ 2>/dev/null
ls -la ~/.config/systemd/user/sysmon.service 2>/dev/null

버전이 1.82.7 또는 1.82.8이면 감염된 것이다. 해당 환경에 있던 모든 인증 정보가 이미 유출되었을 가능성이 있다.

(출처: FutureSearch, GitHub Issue #24512)

 

7. 지금 당장 해야 할 대응 방법

감염 버전이 확인되었다면 아래 순서대로 대응한다.

 

Step 1: 즉시 삭제

# 감염 버전 제거
pip uninstall litellm -y

# 패키지 매니저 캐시 삭제
rm -rf ~/.cache/uv
rm -rf ~/.cache/pip

# 안전한 버전으로 재설치 (PyPI 격리 해제 후)
# 2026-03-26 현재 전체 패키지 격리 중 — 아래 명령은 격리 해제 후 실행
pip install litellm==1.82.6

 

Step 2: 백도어 제거

# 로컬 백도어 파일 제거
rm -rf ~/.config/sysmon/

# systemd 서비스 중지 및 제거
systemctl --user stop sysmon.service 2>/dev/null
systemctl --user disable sysmon.service 2>/dev/null
rm -f ~/.config/systemd/user/sysmon.service
systemctl --user daemon-reload

# 쿠버네티스: 의심스러운 Pod 탐지 (이름 패턴 + 이미지 기준)
kubectl get pods -n kube-system -o wide | grep -E "node-setup|alpine"

# 의심 Pod 확인 후 개별 삭제 (이름, 이미지, 생성 시각을 반드시 확인)
kubectl delete pod -n kube-system <pod-name>

 

Step 3: 모든 인증 정보 교체

감염 환경에 있던 모든 인증 정보가 유출되었다고 가정하고 교체한다.

교체 필수 목록

• SSH 키 — 새 키 쌍 생성 후 모든 서버에 재배포
• 클라우드 인증 정보 — AWS Access Key, GCP ADC, Azure 토큰 전부 재발급
• 쿠버네티스 설정 — kubeconfig 재생성, 서비스 어카운트 토큰 로테이션
• API 키 — .env 파일에 저장된 모든 API 키 (OpenAI, Anthropic, Google 등)
• 데이터베이스 비밀번호 — 환경변수나 설정 파일에 있던 모든 DB 비밀번호
• Git 토큰 — .gitconfig에 저장된 GitHub/GitLab 개인 액세스 토큰
• CI/CD 시크릿 — 감염 환경의 CI/CD 파이프라인에서 사용하던 모든 시크릿

 

Step 4: 네트워크 차단

# 공격자 도메인으로의 아웃바운드 트래픽 차단
# /etc/hosts 또는 방화벽 규칙에 추가
echo "0.0.0.0 models.litellm.cloud" | sudo tee -a /etc/hosts
echo "0.0.0.0 checkmarx.zone" | sudo tee -a /etc/hosts
# models.litellm.cloud = 데이터 유출 서버
# checkmarx.zone = 백도어 C2 폴링 서버 (50분 간격)

(출처: FutureSearch 대응 가이드, Microsoft Security Blog)

 

8. 교훈 — 바이브 코딩 시대의 공급망 보안

바이브 코딩이 공격 표면을 넓힌다

이 사건에서 가장 주목할 점은 FutureSearch의 발견 경위다. Cursor에서 MCP 플러그인을 사용했을 뿐인데, LiteLLM이 간접 의존성으로 자동 설치되었다. 본인이 pip install litellm을 타이핑한 적이 없다.

바이브 코딩 환경에서는 AI 에이전트가 패키지를 자동으로 설치한다. 사용자가 설치 목록을 일일이 확인하지 않는다. 이 자동화된 신뢰가 공급망 공격의 핵심 공격 표면이 된다.

 

보안 도구의 역설

TeamPCP의 전략은 보안 도구를 먼저 감염시키는 것이다. Trivy는 코드의 보안 취약점을 스캔하는 도구다. 기업들은 "보안을 위해" 이 도구를 CI/CD에 추가한다. 그런데 이 보안 도구 자체가 감염되면, 보안을 강화하려는 행위 자체가 인증 정보를 유출하는 행위가 된다.

 

키 집중 관리의 양면성

LiteLLM이 타겟이 된 이유는 명확하다. 100개 이상의 AI 서비스 API 키를 한곳에서 관리하는 도구이기 때문이다. 키를 한곳에 모으면 관리는 편해지지만, 그 한곳이 뚫리면 모든 키가 동시에 유출된다. 편의성과 보안의 근본적 긴장이다.

방어를 위한 실전 체크리스트

• 의존성 고정 — pip install litellm 대신 pip install litellm==1.82.6처럼 버전을 명시하고, lockfile을 사용한다
• GitHub Action 태그 고정 — uses: aquasecurity/trivy-action@v0.X 대신 커밋 SHA를 고정한다
• CI/CD 시크릿 최소 권한 — PyPI 업로드 토큰은 해당 job에서만 접근 가능하도록 범위를 제한한다
• 간접 의존성 모니터링 — pip list나 uv pip list를 정기적으로 확인하여 예상치 못한 패키지가 설치되었는지 검사한다
• 네트워크 이그레스 제한 — 프로덕션 환경에서 알려진 도메인 이외로의 아웃바운드 트래픽을 차단한다

 

9. 트러블슈팅 Q&A

Q. pip show litellm 했는데 버전이 1.82.6 이하이다. 안전한가?

감염 버전은 1.82.7과 1.82.8이다. 1.82.6 이하라면 이번 사건의 직접적 영향은 없다. 다만 캐시에 감염 파일이 남아 있을 수 있으니 find ~/.cache -name "litellm_init.pth"로 추가 확인한다.

Q. litellm이 설치되어 있지 않다. 완전히 안전한가?

이번 LiteLLM 사건에 대해서는 안전하다. 하지만 TeamPCP의 캠페인은 LiteLLM만이 아니다. Trivy, KICS(Checkmarx)도 감염되었고, Endor Labs는 "이 캠페인은 아직 끝나지 않았다"고 경고했다. CI/CD에서 Trivy GitHub Action이나 KICS GitHub Action을 사용하고 있다면 해당 사건도 별도로 확인해야 한다.

Q. macOS에서도 systemd 백도어가 작동하는가?

macOS에는 systemd가 없으므로 systemd 경로의 백도어는 작동하지 않는다. 하지만 Stage 1(인증 정보 수집)과 Stage 2(외부 전송)는 OS에 관계없이 실행된다. macOS 사용자도 감염 버전이 설치되었다면 인증 정보가 유출되었을 가능성이 있다. ~/.config/sysmon/ 디렉토리가 존재하는지 확인한다.

Q. Docker 컨테이너 안에서만 litellm을 사용했다. 호스트도 위험한가?

컨테이너 안에서만 실행했다면 호스트 파일시스템의 인증 정보는 안전할 가능성이 높다. 하지만 컨테이너에 마운트된 시크릿, 환경변수로 전달된 API 키, 쿠버네티스 서비스 어카운트 토큰은 유출 대상이다. 컨테이너 내부에서 접근 가능했던 모든 인증 정보를 교체한다.

Q. 현재 LiteLLM을 계속 사용해도 되는가?

2026년 3월 26일 현재, litellm 전체 패키지가 PyPI에서 격리 중이다. 감염 버전뿐 아니라 모든 버전이 pip install litellm으로 설치할 수 없다. 이미 설치된 1.82.6 이하는 그 자체로는 안전하지만, PyPI에서 새로 받을 수는 없다. BerriAI는 관리자 계정을 전체 교체했고, 공급망 검토 완료 시까지 새 릴리스를 중단한 상태다. Trusted Publishers(OIDC)로의 마이그레이션도 논의 중이다. BerriAI 공식 대응 이슈(#24518)와 공식 보안 공지를 추적한다.

Q. 노출 시간이 약 5시간이었는데, 실제로 영향 받은 사람이 많을까?

LiteLLM 공식 공지 기준 영향 시간대는 10:39~16:00 UTC (약 5시간 20분)이다. 일 다운로드 340만 회 기준으로, 5시간이면 약 70만 다운로드에 해당할 수 있다 (단순 비율 추정). 모든 다운로드가 감염 버전을 받은 것은 아니지만, CI/CD 파이프라인에서 pip install litellm(버전 미고정)을 실행하는 환경은 자동으로 최신 버전을 받았을 가능성이 있다. 정확한 피해 규모는 아직 공개되지 않았다.

 

10. 결론

언제 경계해야 하는가 / 언제 안심할 수 있는가

상황	위험도	행동
litellm 1.82.7 또는 1.82.8 설치됨	긴급	즉시 삭제 + 백도어 제거 + 모든 인증 정보 교체
litellm 설치되어 있으나 다른 버전	주의	캐시에 감염 파일 없는지 확인, 버전 고정 설정
litellm 미설치, CI/CD에서 Trivy 사용	주의	Trivy 사건 별도 대응 필요 (3월 19일~)
litellm 미설치, Trivy 미사용	낮음	간접 의존성 점검, 의존성 고정 습관화

오늘 / 이번 주 / 운영에 반영할 것

오늘:

• pip show litellm 실행하여 버전 확인
• 감염 환경이면 Step 1~4 즉시 수행
• models.litellm.cloud 도메인 차단

 

이번 주:

• 모든 프로젝트의 의존성 lockfile 점검 (requirements.txt, poetry.lock, uv.lock)
• CI/CD에서 사용하는 GitHub Action 태그를 커밋 SHA로 교체
• CI/CD 시크릿의 접근 범위 최소화

 

운영에 반영:

• 프로덕션 환경의 이그레스 트래픽을 화이트리스트 방식으로 제한
• 의존성 업데이트 시 자동화된 보안 스캔 적용 (단, 스캔 도구 자체도 검증 필요)
• API 키 집중 관리 도구 사용 시 키 로테이션 주기 단축 및 접근 로그 모니터링

Endor Labs의 보안 연구자들은 "이 캠페인은 아직 끝나지 않았다"고 경고했다. TeamPCP는 5개 패키지 생태계에 걸쳐 공격을 확장 중이고, 신뢰 체인을 타고 올라가는 패턴을 반복하고 있다. 다음 타겟이 무엇이 될지 아무도 모른다.

바이브 코딩 시대에 pip install 한 줄은 더 이상 가벼운 행위가 아니다.

 

참고자료

• Wiz Research — Three's a Crowd: TeamPCP trojanizes LiteLLM (2026-03-24)
• FutureSearch — Supply Chain Attack in litellm 1.82.8 on PyPI (2026-03-24)
• Endor Labs — TeamPCP Isn't Done (2026-03-24)
• The Hacker News — TeamPCP Backdoors LiteLLM Versions 1.82.7–1.82.8 (2026-03-24)
• Bleeping Computer — Popular LiteLLM PyPI package compromised (2026-03-24)
• LiteLLM 공식 — Security Update: Suspected Supply Chain Incident
• Snyk — How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM
• Microsoft Security Blog — Trivy Supply Chain Compromise 대응 가이드
• GitHub — BerriAI/litellm Issue #24512 (커뮤니티 추적)
• GitHub — BerriAI/litellm Issue #24518 (공식 대응)