당신의 AI 게이트웨이가 백도어였다 — LiteLLM 공급망 공격의 모든 것

들어가며: "pip install"이 당신의 서버를 넘긴 순간

2026년 3월 24일 오전 10시 52분(UTC). 누군가 pip install litellm을 실행합니다. 평범한 월요일의 평범한 패키지 설치. 하지만 이 순간, 그의 서버에 있는 모든 SSH 키, AWS 인증정보, 쿠버네티스 시크릿, 환경변수, 암호화폐 지갑 정보가 암호화되어 공격자의 서버로 전송되기 시작합니다.

import litellm조차 필요 없었습니다. Python 인터프리터가 시작되는 것만으로 악성코드가 실행됐습니다.

이것은 2026년 가장 충격적인 오픈소스 보안 사고 중 하나인 LiteLLM 공급망 공격(Supply Chain Attack)의 이야기입니다. 보안 스캐너가 무기가 되고, 합법적인 인증정보가 독이 되고, AI 에이전트가 공격에 동원된 — 현대 소프트웨어 공급망의 가장 어두운 면을 들여다봅니다.

1장. LiteLLM이 뭐길래?

AI 시대의 통합 게이트웨이

LiteLLM은 100개 이상의 LLM API를 단일 인터페이스로 통합하는 Python 라이브러리입니다. OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI, Mistral, Cohere — 이 모든 것을 동일한 코드로 호출할 수 있게 해주죠.

from litellm import completion

# OpenAI든 Claude든 같은 인터페이스
response = completion(model="gpt-4", messages=[{"role": "user", "content": "안녕"}])
response = completion(model="claude-3-opus", messages=[{"role": "user", "content": "안녕"}])

즉, LiteLLM은 모든 AI 서비스의 API 키를 한곳에 모아두는 도구입니다. 편리하지만, 바로 이것이 공격자에게는 황금 같은 표적이 됩니다. LiteLLM을 침투하면 해당 조직의 모든 AI 서비스 인증정보를 한 번에 탈취할 수 있으니까요.

2026년 3월 기준, LiteLLM은 GitHub 스타 30,000개 이상, PyPI 주간 다운로드 수백만 건을 기록하며, DSPy, MLflow, CrewAI, OpenHands 등 주요 AI 프레임워크의 핵심 의존성으로 자리잡고 있었습니다.

2장. 공급망 공격의 역사: 왜 이것이 가장 위험한 공격인가

공급망 공격이란?

소프트웨어를 직접 해킹하는 대신, 그 소프트웨어가 의존하는 도구나 라이브러리를 감염시켜 간접적으로 침투하는 공격입니다.

비유하자면 이렇습니다: 집 현관문을 부수는 대신, 택배 상자에 도청기를 숨겨서 당신이 직접 집 안으로 가져오게 만드는 것이죠.

역대 주요 공급망 공격

LiteLLM 사건이 특별한 이유는 "공급망의 공급망"을 공격했다는 것입니다. 보안 도구(Trivy) → CI/CD 파이프라인 → 패키지 저장소(PyPI)라는 3단계 신뢰 체인을 역으로 타고 올라간 것이죠.

3장. 공격의 전모: TeamPCP의 9단계 캠페인

공격자는 누구인가?

TeamPCP (별칭: PCPcat, Persy_PCP, ShellForce, DeadCatx3)는 2025년 12월부터 활동이 확인된 위협 행위자 그룹입니다. Telegram 채널을 운영하며, 페이로드에 "TeamPCP Cloud stealer"라는 식별 문자열을 삽입합니다.

LiteLLM 공격은 이들의 "Phase 09" — 즉, 9번째 캠페인 단계였습니다.

공격 타임라인

핵심 관찰: 보안 도구가 공격 벡터가 되다

가장 충격적인 부분은 이것입니다: Trivy는 컨테이너와 코드의 취약점을 스캔하는 보안 도구입니다. 보안을 위해 설치한 도구가, 보안을 뚫는 무기가 된 것이죠.

LiteLLM의 CI/CD 파이프라인은 Trivy를 버전 고정(pinning) 없이 apt로 설치하고 있었습니다. 공격자가 Trivy의 GitHub Action을 변조했을 때, LiteLLM의 빌드 환경에서 자동으로 PYPI_PUBLISH 환경변수가 노출되었고, 이 합법적인 PyPI 배포 인증정보로 악성 패키지를 올릴 수 있었습니다.

4장. .pth 파일 — Python의 숨겨진 시한폭탄

.pth 파일이란?

대부분의 Python 개발자도 모르는 기능이 있습니다. site-packages/ 디렉토리에 .pth 확장자의 파일이 있으면, Python 인터프리터가 시작될 때 자동으로 실행됩니다.

원래 목적은 파이썬의 모듈 검색 경로를 추가하는 것이었지만, import 문을 포함하면 임의의 코드를 실행할 수 있습니다.

왜 이것이 특히 위험한가?

더 소름 끼치는 사실: 이 .pth 파일은 wheel의 RECORD 파일에 정상적으로 선언되어 있었습니다. 해시 검증을 완벽하게 통과합니다. pip의 무결성 확인은 "PyPI가 배포한 것과 동일한 파일인지"를 검증할 뿐, "그 파일이 악성인지"는 판단하지 못합니다.

CPython 커뮤니티도 이 위험을 인지하고 있습니다 (cpython#113659), 하지만 2026년 현재까지 패치는 적용되지 않았습니다.

5장. 3단계 악성 페이로드 해부

Stage 1: 인증정보 수확 (Credential Harvesting)

악성코드는 시스템에서 닿을 수 있는 모든 인증정보를 체계적으로 수집합니다:

특히 주목할 점은 AWS IMDS(Instance Metadata Service)에 IMDSv2 서명까지 구현하여 쿼리한다는 것입니다. EC2 인스턴스에서 실행될 경우, 인스턴스에 할당된 IAM 역할의 임시 인증정보까지 탈취합니다.

Stage 2: 암호화 및 탈취 (Encryption & Exfiltration)

수집된 데이터는 하이브리드 암호화를 거쳐 전송됩니다:

주의: 탈취 도메인은 litellm.cloud입니다. 합법적인 LiteLLM 도메인은 litellm.ai입니다. 공격자는 비슷하지만 다른 도메인을 사용하여 네트워크 모니터링에서 눈에 띄지 않도록 했습니다.

중요한 포렌식 단서: Trivy, Checkmarx KICS, LiteLLM 세 공격 모두에서 동일한 RSA-4096 공개키가 발견되었습니다. 이것이 TeamPCP라는 단일 그룹의 소행임을 확인하는 가장 강력한 기술적 귀속 근거입니다.

Stage 3: 지속성 확보 및 횡적 이동

단순한 정보 탈취에서 끝나지 않습니다. 악성코드는 장기 거점을 마련합니다:

쿠버네티스 횡적 이동은 특히 위험합니다. 하나의 감염된 파드에서 시작하여 전체 클러스터의 모든 노드로 확산할 수 있기 때문입니다. 프로덕션 환경이라면, 이것은 곧 전체 인프라의 완전한 장악을 의미합니다.

6장. 발견의 순간: "왜 내 컴퓨터가 멈춘 거지?"

Callum McMahon의 발견

보안 연구원 Callum McMahon(FutureSearch)이 이 공격을 최초로 발견한 경위는 아이러니합니다. 그는 LLM 연구 제품을 개발하고 있었고, Cursor IDE의 MCP 플러그인이 전이 의존성(transitive dependency)으로 litellm을 설치했습니다.

그런데 컴퓨터가 RAM 소진으로 응답 불능 상태에 빠졌습니다. 악성코드의 서브프로세스 생성 버그 — 일종의 포크 봄(fork bomb) — 이 기하급수적으로 프로세스를 복제하면서 시스템이 멈춘 것이죠.

원인을 추적한 McMahon은 site-packages/에서 34,628바이트의 이중 Base64 인코딩된 파일을 발견합니다. 바로 litellm_init.pth.

그가 GitHub 이슈 #24512에 이 사실을 보고하자, 놀라운 일이 벌어집니다.

88개의 봇 댓글, 102초

이슈가 등록되자 12:44~12:46 UTC, 단 102초 동안 73개의 고유 계정에서 88개의 봇 댓글이 쏟아졌습니다. 분석 결과, 이 봇넷 계정의 76%가 Trivy 공격 때 사용된 것과 동일했습니다.

더 충격적인 것은, 공격자가 탈취한 LiteLLM 메인테이너(krrishdholakia) 계정을 사용하여 이슈를 "not planned"로 닫아버렸다는 것입니다.

7장. AI 에이전트가 공격에 동원되다

CanisterWorm과 hackerbot-claw

TeamPCP의 인프라에서 특히 주목할 부분이 있습니다. 이들은 CanisterWorm이라는 도구를 개발했는데, 이것은 인터넷 컴퓨터 프로토콜(ICP)을 C2(Command and Control) 채널로 사용합니다. ICP는 탈중앙화 플랫폼이라 전통적인 도메인 테이크다운이 불가능합니다.

더 놀라운 것은 hackerbot-claw라는 컴포넌트입니다. 이 안에는 openclaw라는 AI 에이전트가 포함되어 있으며, 타깃 선정과 공격 경로 분석을 자동화합니다.

"공급망 공격에 AI 에이전트가 운영적으로 사용된 최초의 사례 중 하나" — Snyk Security Labs

이것은 2026년의 현실입니다. AI가 코드를 작성하는 데만 쓰이는 것이 아니라, 공격을 자동화하는 데도 쓰이기 시작한 것입니다.

8장. 왜 기존 보안 체크로는 막을 수 없었나

해시 검증의 한계

"pip는 설치할 때 해시를 확인하지 않나요?"라고 물을 수 있습니다. 맞습니다. 하지만 해시 검증은 "PyPI가 배포한 것과 동일한 파일인지"만 확인합니다.

문제는, 이 패키지가 합법적인 인증정보로 PyPI에 업로드되었다는 것입니다. PyPI 입장에서는 정상적인 배포였죠.

핵심 교훈: .pth 파일은 wheel의 RECORD 파일에 정상 선언되어 해시가 일치합니다. 오타 도메인이나 의심스러운 패턴이 없습니다. 기존의 모든 자동화된 보안 체크를 통과합니다.

9장. 영향과 대응

즉각 대응한 프로젝트들

공격 발견 후 수시간 내에 다음 프로젝트들이 긴급 패치를 배포했습니다:

• DSPy — Stanford NLP 연구 프레임워크
• MLflow — ML 라이프사이클 관리
• OpenHands — AI 개발 에이전트
• CrewAI — 멀티 에이전트 프레임워크
• Arize Phoenix — ML 옵저버빌리티
• langwatch — LLM 모니터링

유일하게 사전에 안전했던 프로젝트는 Aider-AI였습니다. 이들은 litellm==1.82.3으로 버전을 고정(pinning)하고 있었습니다.

BerriAI의 공식 대응

LiteLLM을 개발하는 BerriAI는 다음과 같이 대응했습니다:

1. PyPI에서 감염된 버전 즉시 제거
2. 모든 인증정보 로테이션
3. Google Mandiant에 포렌식 분석 의뢰
4. 보안 검토가 완료될 때까지 신규 릴리스 중단
5. v1.82.6 이하 버전의 SHA-256 체크섬 검증 및 공개

영향받은 경우 즉시 해야 할 것

10장. 탐지 지표 (IOC)

파일 해시

네트워크 IOC

11장. 2026년, 이것이 의미하는 것

AI 인프라는 새로운 공격 표면

TeamPCP의 타깃 선정은 우연이 아닙니다. 이들이 노리는 것은 높은 권한이 필요한 개발자 도구입니다:

• 컨테이너 보안 스캐너 (Trivy) — CI/CD에서 코드와 시크릿에 접근
• IaC 분석 도구 (Checkmarx KICS) — 인프라 설정 파일에 접근
• LLM 게이트웨이 (LiteLLM) — 모든 AI 서비스의 API 키를 보유

2026년, AI 도구는 더 이상 단순한 라이브러리가 아닙니다. 조직의 핵심 인프라를 관통하는 신뢰된 게이트웨이입니다. 이것을 공격하면 전통적인 보안 도구보다 훨씬 더 많은 것을 얻을 수 있습니다.

방어의 원칙

마치며: 신뢰는 취약점이다

이 사건의 본질은 기술적 취약점이 아닙니다. 신뢰 모델의 실패입니다.

• 우리는 보안 스캐너를 신뢰합니다 → 보안 스캐너가 무기가 되었습니다
• 우리는 PyPI의 서명된 패키지를 신뢰합니다 → 합법적 인증정보로 악성 패키지가 배포되었습니다
• 우리는 메인테이너의 GitHub 계정을 신뢰합니다 → 메인테이너 계정이 탈취되어 이슈가 묻혔습니다

"신뢰하되 검증하라(Trust but verify)"는 더 이상 충분하지 않습니다. 2026년의 공급망 보안은 "아무것도 신뢰하지 말고 모든 것을 검증하라(Zero Trust)"를 요구합니다.

당신의 requirements.txt를 열어보세요. 거기에 적힌 패키지 중 몇 개의 소스코드를 직접 확인해 보셨나요?