LiteLLM 1.107.0 공급망 공격 대응:
감염 확인과 키 교체 순서 [2026]

2026년 10월 21일, AI 게이트웨이 오픈소스 LiteLLM의 정상 릴리스 파이프라인이 훔친 GitHub 토큰으로 조작돼 자격 증명 탈취 코드가 든 litellm 1.107.0이 PyPI(11:39~13:23 UTC, 한국 시간 20:39~22:23)와 공식 Docker 이미지(v1.107.0·latest·main-latest·main-stable 태그, 11:46~14:20 UTC)로 나갔다. 설치 시각과 버전 고정 여부에 관계없이 1.107.0이 설치됐거나 악성 이미지가 실행된 환경은 침해로 가정해 대응하고(캐시·사내 미러의 악성 산출물도 조사·차단하고 그것을 설치·실행한 환경을 추적한다), 그 환경의 python·pip는 실행하지 말고 밖에서 파일과 이미지 다이제스트를 확인한 뒤 LLM 공급자 키, 클라우드 자격 증명, GitHub 토큰 순으로 교체한다.

LiteLLM은 10월 23일 근본 원인 분석에서 출발점을 5월 27일 공개 저장소에 커밋된 뒤 폐기되지 않은 AI 에이전트 플랫폼 마스터 키로 정리했고, 첫 공지의 'AI 게이트웨이 로그에서 토큰이 샜다'는 가설은 철회했다. 9월 KEV에 오른 LiteLLM 인증 결함 CVE-2026-59822는 CISA KEV AI 인프라 3종에서 다뤘다. 이번 건은 취약점이 아니라 배포 경로를 빼앗은 공급망 공격이고, 다른 AI 관련 사고는 AI 해킹 사고 사례 2026에 모았다.

한눈에 보기

무슨 일이 있었나: 타임라인

시각은 UTC다(한국 시각은 9시간을 더한다). 공격 과정은 LiteLLM 근본 원인 분석 기준이다.

• 05-27: Agent Platform 마스터 키가 든 설정 파일이 공개 저장소 LiteLLM-Labs/lite-harness에 커밋됐다. 커밋은 강제 푸시로 덮었지만 키는 폐기되지 않았다.
• 10-10: 공격자가 마스터 키로 조직 소유자의 GitHub CLI 토큰을 얻고, 임시 워크플로로 유지관리자 2명의 토큰이 든 CI 비밀을 빼냈다(12일 비공개 저장소들에서 2차 유출).
• 10-19(월): 백포트 배포를 위해 릴리스 권한을 넓혀 엔지니어 두 명이면 릴리스를 시작·승인할 수 있게 됐다.
• 10-21 10:08~11:11: 소유자 토큰으로 릴리스 저장소의 브랜치 보호를 끄고 빌드 소스를 유사 저장소로 바꾼 뒤 훔친 토큰으로 승인했다.
• 10-21 11:39~12:06: PyPI 휠 7개, 이어 Docker Hub·GHCR 이미지(11:46)가 나갔다. 공개 7분 뒤 Socket의 AI 스캐너가 경보를 냈고, 12:06 Upwind 연구팀이 GitHub 이슈 #47826으로 공개 신고했다.
• 10-21 13:23~17:01: PyPI 격리(13:23), GHCR 태그 접근 불가(13:51), Docker Hub 태그 제거·재지정(14:20). 16:20~17:01 Wiz가 탈취 자격 증명 악용을 관측했다.
• 10-27(예정): 엔터프라이즈 릴리스로 먼저 고친 별도 취약점이 공개될 예정이다(내용 미공개).

3월 사건과는 다르다. 3월에는 1.82.7·1.82.8이 약 40분 공개됐고(Trivy 의존성 경유, LiteLLM 판단) 시작 파일은 litellm_init.pth(1.82.8), 유출 도메인은 models.litellm[.]cloud·checkmarx[.]zone이었으며 공식 Docker 이미지는 영향이 없었다. 지표는 사건별로 쓴다.

공격 흐름 단계별 분석

1~3단계는 LiteLLM 내부, 4~6단계는 1.107.0을 설치한 쪽의 일이다. 1~3단계 흔적은 우리 조직이 같은 수법을 당했는지 볼 곳이다.

1단계 진입: 공개 저장소에 남은 에이전트 플랫폼 마스터 키

• 무엇을: 에이전트가 GitHub에 PR을 올리는 실험 서비스 Agent Platform에는 조직 소유자 개인 계정의 GitHub CLI OAuth 토큰이 범위 축소 없이 들어 있었다. 공격자가 마스터 키로 GET /api/v1/managed_agents/agents?limit=100을 부르자 모든 에이전트 설정과 함께 이 토큰이 돌아왔다. 이 토큰은 2단계 인증 뒤 발급돼 민감한 작업의 재인증을 거치지 않는다(LiteLLM).
• 방어자가 볼 흔적: 에이전트 플랫폼·게이트웨이 API 로그의 마스터 키 사용, 처음 보는 출발지 IP, 설정 전체를 돌려주는 목록 API 호출.

2단계 확산: 저장소 CI를 비밀 유출 통로로

• 무엇을: ci-tmp-<16진수> 임시 브랜치에 워크플로를 넣는 커밋을 푸시해 실행하고 기록을 지워, GH_TOKEN과 RELEASE_PLEASE_TOKEN 비밀에 저장된 유지관리자 두 명의 개인 토큰을 빼냈다(LiteLLM). Socket이 복구한 커밋은 .github/workflows/cache.yml을 추가하는 'ci: bump cache config'였다.
• 방어자가 볼 흔적: 워크플로 파일과 실행 기록을 지워도 저장소 Insights의 Actions 지표와 환경 배포 기록은 남았다(Socket). 웹 UI 밖에서 토큰으로 인증한 이벤트에는 감사 로그에 토큰 해시가 남고, LiteLLM은 이 해시로 10월 10일 빼낸 토큰이 릴리스 승인 토큰임을 확인했다.

3단계 릴리스 조작: 보호 해제, 유사 저장소, 서명된 발행

• 무엇을: 릴리스 저장소에 '포크 소스에서 릴리스' 커밋을 푸시하다 브랜치 보호에 막히자 5초 뒤 소유자 토큰으로 보호를 끄고 강제 푸시했다. 빌드 소스는 하이픈 하나 다른 Berri-AI/litellm이었고 pyproject.toml에 넣은 data = "cook" 한 줄이 페이로드를 휠에 실었다(Socket). 승인은 다른 토큰으로 했고 정상 파이프라인이 서명해 발행했다. 포크 커밋도 GitHub에서 BerriAI/litellm 주소로 열리니 주소만으로 공식 커밋이라 판단하지 않는다(LiteLLM).
• 방어자가 볼 흔적: 감사 로그의 브랜치 보호 무시·강제 푸시, 배포 환경 승인자와 IP, 빌드 출처 정보의 소스 소유자("source_owner": "Berri-AI", Socket).

4단계 설치 환경 실행: 파이썬 시작 훅

• 무엇을: pip는 휠의 시작 파일 3개를 site-packages 최상위에 설치한다. 파이썬은 초기화 때 .pth 파일의 import 줄을 실행하고 sitecustomize를 불러오므로 cook.pth의 import cook 한 줄이 감춰 둔 수집기를 돌린다. 관련 없는 패키지를 설치하려던 파이썬 호출로 수집기가 돈 Windows 사례도 있다(마이크로소프트). 파일이 litellm 폴더 밖이라 패키지만 지우면 남는다.
• 방어자가 볼 흔적: dist-info와 시작 파일 3개, 환경변수 PRIVCOLLECT_ACTIVE=1, python이 systeminfo·ipconfig·route·arp·netstat를 연달아 띄운 프로세스 트리(마이크로소프트, ATT&CK T1546.018).

5단계 수집과 암호화 유출

• 무엇을: DATABASE_URL이 있으면 Prisma로 LiteLLM_CredentialsTable과 LiteLLM_ProxyModelTable을 500행까지 읽어 프록시의 공급자 키를 가져간다(Endor Labs). AI 코딩 도구 인증 파일(예: ~/.codex/auth.json)을 포함해 수집 모듈은 16개다(Socket). 코드에 대상이 있다고 실제로 가져갔다는 뜻은 아니다(마이크로소프트).
• 유출: AES-256으로 암호화하고 키를 RSA-4096으로 감싸 hxxp://www[.]litellm[.]dev/healthcheck에 POST하고 성공하면 /tmp/.pc_once_72129118c59f5636c0bb를 쓴다. litellm.dev는 10월 13일 등록된 도메인으로 정식 도메인(litellm.ai)이 아니며, 패킷을 잡아도 복호화할 수 없다(Upwind).
• 방어자가 볼 흔적: POST /healthcheck(헤더 X-Token: XWiA8gZNa7NcX2XRoAEb, Socket), openssl 명령줄의 .pc_e_와 enc -aes-256-cbc, python -c 명령줄의 LiteLLM_CredentialsTable(마이크로소프트).

6단계 원격 로더와 탈취 자격 증명 악용

• 무엇을: sitecustomize.py는 분리된 데몬으로 떠서 1시간마다 GitHub의 letters9813/pythonclient-test/main/domain.txt를 읽고 도메인이 있으면 /codepy를 받아 실행하게 돼 있다. 실제 C2 주소가 들어간 적은 없고(Upwind) 저장소는 13:30경 내려갔지만(Wiz), 데몬이 같은 주소를 계속 읽으므로 마이크로소프트는 다시 무장할 수 있는 장치로 남는다고 경고했다. Windows에서는 로더만 실패하고 수집기는 돈다(Upwind).
• 악용: Wiz는 유출 약 4.5시간 뒤 감염된 CI 러너와 Kubernetes 노드의 AWS 인스턴스 역할 자격 증명이 168.100.8[.]57, 165.227.201[.]8에서 sts:GetCallerIdentity, bedrock:ListFoundationModels, ListModels 순으로 검증되는 것을 봤다. 훔친 클라우드 키로 LLM을 쓰는 LLMjacking과 일치하고 일부는 IAM 열거로 이어졌다.
• 방어자가 볼 흔적: /tmp/remote_code_loader.lock, 작업 디렉터리가 / 이고 제어 터미널이 없는 python 프로세스(Endor Labs), CloudTrail의 위 호출 순서와 외부 출발지 IP.

AI는 정확히 무엇을 했나

AI가 한 일

• 공격자가 AI를 썼다는 확인된 증거는 없다. Wiz는 장황한 변수명, 과한 예외 처리, 호출되지 않는 모듈을 근거로 'LLM 보조 개발의 강한 징후'라고 평가했지만 검증된 판단은 아니다.
• AI 인프라가 통로이자 표적이었다. 진입점은 에이전트 플랫폼의 마스터 키와 에이전트 설정 속 토큰이었고, 수집기는 공급자 키와 AI 코딩 도구 인증 파일을 겨냥했다. LiteLLM은 공격자가 내부 시스템에서도 추론 API 토큰을 주로 찾았다고 밝혔다.

사람이 한 일

• 공격 운영: 11일 동안 들키지 않은 비밀 수집, 감사 로그 소음을 피하려 토큰을 나눠 쓴 승인(LiteLLM 판단), 기록 삭제가 이어졌다. 공격자 신원과 도구는 공개되지 않았다.
• 원인 제공: 키 폐기 누락, 개인 토큰 저장, 승인 완화는 모두 사람이 정한 운영 설정이다.

과장된 해석 바로잡기

• 'AI 코딩 도구가 토큰을 흘려 뚫렸다'가 아니다. 첫 공지는 앤트로픽의 AI 코딩 도구가 특정 상황에서 GitHub CLI 토큰을 응답 본문에 넣어 게이트웨이 로그에 남을 수 있다고 썼지만, 10월 24일 LiteLLM 보안 책임자는 탈취 경로가 아니라 조사 중 발견한 현상이라고 정정했다(앤트로픽과 확인 중).
• '게이트웨이 로그 유출'·'최근 패치된 취약점'도 원인이 아니었다. 첫 토큰은 Agent Platform API 응답에서 나왔고, 내부 게이트웨이의 낯선 사용자는 다른 경로로 얻은 자격 증명으로 추가된 것이었다(경로 미공개).
• '49,000곳 감염'이 아니다. 다운로드 수이고 미러·CI의 내려받기도 함께 센다.
• '3월 공격자의 재공격'이라는 근거는 없다. JFrog는 두 사건을 잇는 증거가 없다고 했다. 3월 사건을 TeamPCP와 연결한 것도 JFrog 등 업체 분석이고 LiteLLM 3월 공지에는 Trivy 연관만 있다.

왜 뚫렸나: 원인

기술 원인

1. 시작 훅은 import 없이 돈다. 그래서 조사용 pip 실행도 위험하다.
2. 소스 검토로는 안 보였다. LiteLLM은 3월 뒤 릴리스를 비공개 저장소로 옮기고 Trusted Publishing, 불변 Docker 태그, 이미지 서명을 도입했지만 공격자는 훔친 신원으로 그 경로를 그대로 돌렸다. 출처 정보도 '기록된 빌드 입력'의 증거일 뿐이다(Socket).
3. 떠다니는 태그와 게이트웨이의 비밀 집중. latest 계열 태그나 고정하지 않은 설치가 고르지 않은 버전을 받았고, 게이트웨이는 공급자 키·DB 연결 문자열·워크로드 신원을 쥐는 자리라 호스트 하나의 감염으로 그 환경에서 접근 가능한 LLM 키가 유출될 수 있다(마이크로소프트).

운영 원인

1. 노출된 키를 덮기만 하고 폐기하지 않았다. LiteLLM 보안 책임자는 근본 원인을 '범위를 충분히 줄이지 않은 키 사용과 우발적 노출 뒤 폐기 실패'로 요약했다. 커밋 속 비밀을 막는 절차는 AI 코딩 커밋 시크릿 유출 대응에 있다.
2. 자동화에 사람의 최고 권한 토큰을 넣었다. 에이전트 설정에는 조직 소유자 토큰이, CI 비밀에는 유지관리자 개인 토큰이 있었다.
3. 릴리스 승인을 임시로 완화했다. 물리 장치에 묶인 승인이 '엔지니어 두 명'으로 바뀐 지 이틀 뒤 공격이 왔다.
4. 11일 동안 몰랐다. 몇 분 만에 지워진 임시 브랜치 워크플로를 잡지 못했다.

우리 조직에서 찾아볼 흔적

지표 하나로 침해를 확정하지 않고, 못 찾았다고 깨끗하다고 보지도 않는다(LiteLLM·마이크로소프트). 점검은 의심 환경의 파이썬 없이, 가능하면 깨끗한 시스템에서 한다.

• 설치 흔적: find / -path '*site-packages/litellm-1.107.0.dist-info' -type d 2>/dev/null, find / -path '*site-packages/cook.pth' -type f 2>/dev/null(Endor Labs). pip show 대신 이렇게 파이썬 없이 확인하고 찾은 파일은 sha256sum으로 마이크로소프트 IOC와 대조한다. Windows 개발 PC는 Get-ChildItem C:\ -Recurse -Force -Filter cook.pth -ErrorAction SilentlyContinue(일반 점검).
• 이미지: docker image inspect --format '{{.Id}} {{join .RepoDigests " "}}' $(docker images -q), Kubernetes는 kubectl get pods -A -o jsonpath='{..imageID}' 결과에서 아래 다이제스트를 찾는다(Endor Labs 명령 축약).
• 악성 다이제스트(앞 12자리): 인덱스 1bbcb1443bc9(litellm)·c00f9d92c427(litellm-database)·7b00e91cd2fe(litellm-non_root), 플랫폼별 매니페스트 bd1aeee419ea·56b74573eed6·24581ddc3076·827dd893c74c·645a67d81062·f75c8edae59b(LiteLLM·Wiz).

대응 순서

오늘

1. 플랫폼·DevOps 담당: 영향 범위를 뽑는다. 위 표대로 1.107.0이 들어간 개발 PC, CI 러너, 컨테이너, 게이트웨이 호스트를 목록으로 만들고 사내 미러에서 1.107.0을 막는다.
2. 보안관제: 격리하고 증거부터 남긴다. 호스트를 네트워크에서 떼고 자동 재시작을 막은 뒤, 재부팅·삭제·재설치 전에 프로세스 목록, 메모리, 디스크, 외부 통신 로그를 보존한다(Endor Labs·마이크로소프트). www.litellm[.]dev와 litellm[.]dev를 막고, GitHub는 전체가 아니라 데드드롭 저장소 경로만 막는다(Endor Labs). 첫 1시간 역할 분담은 침해사고 1시간 골든타임 액션북을 쓴다.
3. 모든 담당자: 의심 환경에서 python과 pip를 실행하지 않는다. LiteLLM 첫 공지는 pip show litellm 확인을 안내했지만, 같은 공지와 마이크로소프트는 pip를 포함한 파이썬 시작이 수집기를 다시 돌린다고 경고했다.
4. 플랫폼 담당: 고치지 말고 다시 짓는다. 증거 보존 뒤 이미지와 가상환경을 새로 빌드하고 1.106.2 등 공식 확인된 정상 산출물의 버전과 해시로 고정한다(1.82.7·1.82.8·1.107.0 제외). 제자리 정리가 불가피하면 분리된 python 데몬을 끝내고 셸에서 시작 파일 3개와 __pycache__의 관련 .pyc를 지운다(LiteLLM).
5. 키 담당자: 깨끗한 시스템에서 노출 가능 키 목록 작성 → 새 키 발급·배포 → 옛 키 폐기 → 사용 흔적 확인 순서로 바꾼다. 외부 인터넷이 되는 호스트에 1.107.0이 한 번이라도 설치됐다면 유출이 성공했다고 가정하고(LiteLLM), 키를 바꿔도 기존 세션이 남을 수 있으니 세션도 폐기한다(마이크로소프트).
6. DevOps: 자사 GitHub 감사 로그에서 같은 수법을 찾는다. 유출 의심 토큰은 echo -n TOKEN | openssl dgst -sha256 -binary | base64 값을 hashed_token:"값"으로 검색하되, 화면 검색에서 빠지는 Git 이벤트는 오늘 JSON으로 내보내 대조한다. Git 이벤트 보존 기간은 7일이다(GitHub 문서). 셸 기록에 토큰이 남지 않게 한다.

이번 주

1. 보안관제: 탈취 키 사용 흔적을 설치 시각 이후로 끝까지 본다. CloudTrail, LLM 공급자 사용량, GitHub·레지스트리 감사 로그를 보고, 흔적이 나오면 그 신원이 만든 새 키·사용자·리소스까지 확인한다(일반 점검).
2. 플랫폼: 고정과 검증을 기본값으로 바꾼다. 이미지는 다이제스트, 패키지는 해시 고정 잠금 파일로 받고 사내 미러는 검토 뒤 반입한다(마이크로소프트). 1.106.3과 백포트 1.103.8·1.104.6·1.105.4는 새 cosign 키를 쓰므로 릴리스별 공지의 키로 서명을 검증한다(교체 이유는 미공개).
3. 네트워크 담당: 게이트웨이·CI 러너·개발 PC의 외부 HTTP를 기본 차단한다. 게이트웨이는 필요한 LLM·인증·운영 서비스의 목적지를 확인하고 정상 호출을 검증한 뒤 허용 목록을 적용한다(일반 점검). LiteLLM 보안 책임자도 앱 설정이 아니라 네트워크 계층의 이그레스 차단을 권했다.
4. 보안관제: 의존성의 새 시작 훅에 경보를 건다. 서드파티 휠의 새 .pth 실행 줄이나 sitecustomize.py는 드물어 신호가 강하다(Endor Labs).

이번 달

1. 보안 책임자: 노출된 키는 '지웠다'가 아니라 '폐기를 확인했다'로 닫는다. 노출 경보마다 폐기 시각, 담당자, 폐기 뒤 사용 시도를 기록한다.
2. DevOps: 자동화에서 사람 계정 토큰을 뺀다. AI 에이전트와 CI에는 범위를 줄인 서비스 신원을 쓰고 조직 소유자 토큰은 어떤 설정에도 두지 않는다.
3. 릴리스 책임자: 승인 완화에는 기한과 대체 통제를 둔다. 릴리스 워크플로가 승인된 저장소 소유자와 검토된 리비전으로만 빌드하게 묶는다(Endor Labs).

자가점검

예/아니오로 답하고 '아니오'부터 대응 순서로 돌아간다.

1. 1.107.0 휠이나 악성 이미지가 들어간 곳을 CI·사내 미러까지 하루 안에 뽑을 수 있는가

개발 PC와 CI 러너도 파이썬만 시작하면 수집기가 돈다.

2. 의심 환경에서 python·pip를 쓰지 않는 점검 절차가 있는가

조사용 pip 한 번이 수집기를 다시 실행한다.

3. 프록시 DB의 공급자 키 목록과 교체 담당자가 정해져 있는가

수집기는 이 테이블을 직접 읽었다.

4. 게이트웨이와 CI 러너의 외부 통신이 기본 차단인가

유출과 원격 로더 모두 바깥 연결이 있어야 동작한다.

5. 공개 저장소에 노출된 키를 폐기 확인까지 추적하는가

이번 사고는 5월에 덮기만 한 키 하나에서 시작됐다.

6. AI 에이전트와 CI에 사람 계정 토큰 대신 범위를 줄인 서비스 신원을 쓰는가

조직 소유자 토큰 하나가 모든 저장소 권한이 됐다.

7. 브랜치 보호 무시, 실행 기록 삭제, 릴리스 승인에 경보가 있는가

공격자는 보호를 끄고 기록을 지웠지만 감사 로그에는 남았다.

1.107.0이 돌았던 흔적이 보이면 유출 범위부터 확인하기

보안 전문 기업 SENTRIX의 침해사고 대응은 메일 제목에 [긴급]을 표기하면 영업일 기준으로 우선 확인해 초기 대응 범위와 일정을 안내하고, 침해 원인 분석(포렌식), 악성코드 분석·제거, 피해 범위 산정과 보고서, KISA·수사기관 신고 지원, 재발 방지 대책, 복구·모니터링까지 이어 간다. 이미 탈취된 키로 생긴 피해를 되돌리는 서비스는 아니다. 1.107.0 설치 흔적이나 우리 인프라 밖에서 쓰인 자격 증명 기록이 보였다면 키 교체와 함께 어느 호스트에서 무엇이 나갔을 수 있는지부터 확인하세요. 침해사고 진단 문의하기

참고 자료

• LiteLLM, Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised(2026-10-21)
• LiteLLM, The attack chain behind the v1.107.0 LiteLLM release(2026-10-23)
• LiteLLM GitHub, 이슈 #47826(신고·분석과 보안 책임자 댓글)(2026-10-21)
• LiteLLM GitHub, Release v1.106.3(2026-10-24)
• LiteLLM, Security Update: Suspected Supply Chain Incident(3월 사건)(2026-03-24)
• Microsoft Security Blog, Inside the LiteLLM 1.107.0 supply chain compromise(2026-10-23)
• Upwind, LiteLLM 1.107.0 Supply Chain Attack(2026-10-21)
• Wiz, LiteLLM Compromised, Steals Credentials(2026-10-21)
• Socket, LiteLLM PyPI Package and Docker Images Compromised to Steal Cloud and AI Credentials(2026-10-21)
• Socket, New Evidence Shows LiteLLM Secret-Stealing Workflows Ran 11 Days Before Supply Chain Attack(2026-10-23)
• Endor Labs, LiteLLM 1.107.0 Compromised(2026-10-21)
• JFrog Security Research, LiteLLM Hijacked Again(2026-10-21)
• GitHub Advisory Database, GHSA-92x9-889m-jgmw(2026-10-22 갱신)
• PyPI, litellm 릴리스 목록(JSON)(2026-10-26 확인)
• GitHub Docs, Identifying audit log events performed by an access token(2026-10-26 확인)