택배로 주문한 상자가 진짜 그 회사 트럭에 실려, 진짜 송장을 붙이고 왔어요. 그런데 상자 안에 몰래 열쇠 도둑이 함께 들어 있었다면? 어제(10월 21일) 밤 AI 개발자들 사이에서 실제로 이런 일이 벌어졌어요. 챗GPT·클로드·제미나이 같은 여러 AI를 하나의 방식으로 연결해 주는 인기 부품 LiteLLM(라이트LLM)의 공식 새 버전 1.107.0에 정보 탈취 악성코드가 실려 배포된 거예요.
문제의 버전이 공개돼 있던 시간은 약 2시간. 하지만 이 부품은 일주일에 약 2,300만 번 내려받아질 만큼 많이 쓰여요. 오늘은 무슨 일이 있었는지, 왜 ‘공식 업데이트’인데도 막지 못했는지, 그리고 내 PC·회사 서버가 해당되는지 확인하는 법과 해야 할 일을 초보 눈높이로 정리해 볼게요.
한눈에 보는 요약
| 질문 | 짧은 답 |
|---|---|
| 무슨 일이에요? | 파이썬용 AI 연결 부품 LiteLLM 1.107.0이 공격자 손을 거쳐 공식 경로(PyPI·도커)로 배포됐어요. 안에 비밀번호·열쇠 도둑 + 원격 조종 뒷문이 들어 있었어요 |
| 언제요? (한국 시간) | PyPI: 10월 21일 20:39 ~ 22:23 / 도커 이미지: 20:46 ~ 23:20 |
| 누가 해당돼요? | 그 시간에 버전을 고정하지 않고 pip install litellm을 했거나, 도커 태그 v1.107.0·latest·main-latest·main-stable을 받아 실행한 곳 |
| 무엇을 훔쳐요? | 클라우드 열쇠, AI 서비스 API 키, SSH·Git 토큰, 브라우저 저장 비밀번호·쿠키, AI 코딩 도구 로그인 정보, .env 비밀값 등 |
| 어떻게 뚫렸어요? | 개발자 3명의 깃허브 CLI 로그인 토큰이 털려, 공격자가 공식 배포 공장을 하이픈 하나 다른 가짜 저장소(Berri-AI)로 돌렸어요 |
| 지금은요? | 악성 버전은 모두 내려갔고, 안전한 버전은 1.106.2. 이전 버전들은 안전하다고 LiteLLM이 밝혔어요. 기업용 비공개 배포판은 영향 없음 |
| 나는 뭘 해요? | 해당되면 ① 악성 파일 삭제 → ② 1.106.2로 재설치(새로 짓기 권장) → ③ 그 컴퓨터가 닿던 열쇠를 전부 교체 |
먼저, LiteLLM은 뭐 하는 물건일까
여행용 멀티 어댑터를 떠올리면 쉬워요. 나라마다 콘센트 모양이 다르듯, AI 회사마다 접속 방식이 조금씩 달라요. LiteLLM은 그 차이를 감춰 주는 ‘만능 어댑터’ 부품이라, 개발자는 코드 한 줄로 여러 회사의 AI를 바꿔 끼울 수 있어요. 회사에서는 이걸 사내 AI 관문(프록시)으로 세워 두고, 직원들의 AI 사용량·비용·API 키를 한곳에서 관리하기도 해요.
| 용어 | 생활 속 비유 | 이번 사건에서의 의미 |
|---|---|---|
| 라이브러리(패키지) | 조립식 가구의 기성 부품 | LiteLLM 자체. 직접 만들지 않고 가져다 쓰는 코드 묶음 |
| PyPI | 파이썬 부품 전용 앱스토어 | pip install로 내려받는 공식 창고. 악성 1.107.0이 여기에 올라왔어요 |
| 도커 이미지 | 가구가 다 조립된 채 오는 완제품 상자 | LiteLLM을 서버에 바로 띄우는 공식 이미지도 오염됐어요 |
| latest 태그 | “늘 최신 걸로 보내 주세요” 정기배송 | 자동으로 최신을 받던 곳은 사람이 몰라도 악성 버전을 받았어요 |
| 공급망 공격 | 공장·물류 단계에서 독을 타는 범죄 | 가게(사용자)가 아니라 부품 공장을 노리면 한 번에 수많은 곳에 퍼져요 |
| 토큰 | 출입증 | 비밀번호 대신 쓰는 로그인 증표. 이번 공격의 출발점 |
상자는 진짜인데 내용물이 가짜, 어떻게 가능했을까
LiteLLM은 사실 올해 3월에도 비슷한 일(1.82.7·1.82.8 버전 오염)을 겪었어요. 그 뒤로 배포 과정을 꽤 단단히 잠갔다고 해요. 배포는 비공개 저장소에서만, 정해진 절차로만, 도커 이미지는 서명까지 하고요. 그런데 공격자는 잠금장치를 부순 게 아니라, 열쇠를 가진 사람들의 출입증을 썼어요.
| 단계 | 무슨 일이 있었나 | 비유 |
|---|---|---|
| 1 | 사건 직전 월요일, 고객용 긴급 수정본을 매일 내보내려고 엔지니어 2명에게 배포 권한을 임시로 넓혀 줬어요 | 바쁜 시즌이라 창고 열쇠를 두 명에게 더 나눠 줌 |
| 2 | 공격자는 개발자 3명의 깃허브 CLI 로그인 토큰을 손에 넣었어요 | 출입증 세 장을 훔침 |
| 3 | 배포 설정을 바꾸려다 보호 규칙에 막혔지만, 토큰 하나가 조직 최고 관리자 것이라 보호 규칙을 끄고 강제로 밀어 넣었어요 | 경비가 막자 사장님 출입증으로 경보를 끔 |
| 4 | 배포 공장을 진짜 BerriAI/litellm 대신 하이픈 하나 다른 Berri-AI/litellm(공격자 저장소)으로 돌렸어요 |
공장에 진짜 설계도 대신 이름이 거의 같은 가짜 설계도를 넣음 |
| 5 | 두 번째 개발자 토큰으로 최종 승인까지 통과 → 공식 서명이 찍힌 채 PyPI·도커에 게시 | 검수 도장까지 받아 정식 출고 |
| 6 | 세 번째 토큰으로 작업 기록을 삭제해 흔적을 줄였어요 | CCTV 녹화본을 지움 |
여기서 핵심은 “공식 서명이 있으니 안전하다”가 통하지 않았다는 점이에요. 보안 업체 데이터독(Datadog)은 결과물이 정상 배포 경로로 나왔고, 빌드 기록도 그럴듯해 보였지만 그 기록엔 가짜 저장소가 출처로 충실히 적혀 있었다고 짚었어요. 즉 서명은 “이 공장에서 만들었다”는 뜻이지 “설계도가 진짜다”라는 뜻은 아니었던 거죠. 또 JFrog 분석에 따르면 소스코드 묶음에는 악성 파일 3개가 없고, 실제 설치되는 완성본(휠)에만 들어 있었어요. 소스만 훑어보는 검토로는 놓치기 쉬웠다는 뜻이에요.
그 토큰은 어디서 샜을까
LiteLLM의 중간 조사 결과는 꽤 아이러니해요. 회사 내부용 LiteLLM 서버가 인터넷에 노출돼 있었고, 거기서 정체 모를 이름의 사용자 계정이 발견됐대요. 그리고 특정 상황에서 AI 코딩 도구 클로드 코드가 사용자의 깃허브 CLI 토큰을 응답 내용에 담는 경우가 있었고, 응답을 기록(로그)하는 설정이면 그 토큰이 LiteLLM 로그에 남을 수 있었다고 해요. 공격자는 이 로그에서 토큰을 꺼낸 것으로 보고 있어요.
| 확인된 것 | 아직 확인 중인 것 |
|---|---|
| 내부 LiteLLM 서버가 인터넷에 노출돼 있었고, 수상한 계정이 있었음 | 공격자가 그 서버에 처음 어떻게 들어왔는지 (최근 패치된 취약점을 의심) |
| 로그에 개발자 토큰이 남을 수 있는 경로가 있었음 | 정확한 전체 타임라인과 피해 범위 |
| 올해 3월 사건(1.82.7·1.82.8)과 같은 방식(.pth 파일) | 두 사건이 같은 범인인지 — 데이터독은 “연관성은 아직 확인되지 않았다”고 밝힘 |
생활 속 교훈으로 바꾸면 이래요. “대화 기록·로그에도 비밀번호가 묻어 있을 수 있다.” 메신저에 공인인증서 비밀번호를 보내 놓고 잊어버리는 것과 비슷해요. AI 도구를 많이 쓸수록, 그 도구가 남기는 기록이 새로운 금고가 된다는 점을 기억해 두면 좋아요.
10월 21일 밤, 한국 시간으로 다시 보기
| UTC (현지 공지 기준) | 한국 시간 (KST) | 무슨 일 |
|---|---|---|
| 10:08 | 19:08 | 보호 규칙이 무단 변경을 거부 → 5초 뒤 관리자 토큰으로 강제 적용 |
| 10:46 | 19:46 | 변조된 배포 작업이 가짜 저장소로 시험 빌드 시작 |
| 11:11 | 20:11 | 두 번째 개발자 토큰으로 운영 배포 승인 통과 |
| 11:39~11:40 | 20:39~20:40 | 악성 1.107.0 설치 파일 7개 PyPI 업로드 (윈도우·맥·리눅스 전부) |
| 11:46 | 20:46 | 도커 이미지 게시 — latest 등 태그가 악성 이미지를 가리킴 |
| 11:53~11:54 | 20:53~20:54 | 세 번째 토큰으로 작업 기록 삭제 |
| 13:23까지 | 22:23까지 | PyPI에서 1.107.0 삭제 |
| 13:51 | 22:51 | 깃허브 컨테이너 저장소(GHCR) 태그 접근 차단 확인 |
| 14:20 | 23:20 | 도커 허브 태그 모두 정리(삭제 또는 안전한 이미지로 교체) |
한국에선 퇴근 후 저녁 시간이었어요. 이 시간대에 자동 빌드가 돌거나, 집에서 AI 사이드 프로젝트를 하며 새로 설치한 분이라면 한 번 확인해 보는 게 좋아요.
악성코드는 무엇을, 어떻게 가져가나
이번 악성코드가 특히 고약한 이유는 LiteLLM을 쓰지 않아도 실행된다는 점이에요. 설치될 때 파이썬 폴더(site-packages)에 파일 3개를 몰래 넣는데, 파이썬은 켜질 때마다 이 파일들을 자동으로 읽어요. 심지어 pip 명령을 치는 것도 파이썬을 켜는 일이라 다시 실행돼요.
| 몰래 들어온 파일 | 하는 일 | 비유 |
|---|---|---|
cook.pth |
파이썬이 켜질 때 cook을 자동으로 불러오는 ‘방아쇠’ |
현관문 열면 켜지는 센서 |
cook.py |
각종 비밀값을 긁어모아 암호화한 뒤, 진짜와 비슷한 주소 litellm[.]dev로 전송 |
집 안 열쇠꾸러미를 통째로 복사해 보내는 도둑 |
sitecustomize.py |
백그라운드에 숨어 1시간마다 지시 서버 주소를 확인하고, 받은 코드를 실행하는 뒷문 | 몰래 달아 둔 무선 조종기 |
데이터독에 따르면 뒷문이 확인하던 지시 파일에는 시험용 값만 들어 있어서, 실제로 2단계 공격 코드가 내려온 건 관찰되지 않았어요. 다행이지만, 정보 도둑(1단계)은 설치 즉시 동작하는 구조였어요.
| 노린 정보 | 예시 | 샜을 때 벌어질 수 있는 일 |
|---|---|---|
| 클라우드 열쇠 | AWS·구글 클라우드·애저 자격 증명, 서버의 메타데이터 열쇠, 쿠버네티스·도커·Vault·테라폼 비밀값 | 남의 돈으로 서버를 수백 대 띄우거나 데이터 반출 |
| AI 서비스 키 | 각 AI 회사 API 키, LiteLLM 관문 DB에 저장된 키들 | 내 카드로 AI 요금 폭탄 |
| 개발자 열쇠 | SSH·GPG·TLS 개인키, Git·npm·PyPI 토큰, .env 파일, 터미널 명령 기록 |
내 이름으로 또 다른 악성 패키지 배포(연쇄 공급망 공격) |
| AI 코딩 도구 | 클로드·코덱스·제미나이·커서·코파일럿 등 로그인 세션·설정 | 내 계정으로 코드 열람·작업 지시 |
| 브라우저 | 저장된 비밀번호·쿠키 | 메일·SNS 로그인 탈취 |
나는 해당될까? 3분 자가 진단
| 나의 상황 | 해당 가능성 | 할 일 |
|---|---|---|
| AI 서비스(챗GPT·클로드 앱 등)를 쓰기만 하는 일반 사용자 | 거의 없음 | 따로 할 일 없음. 다만 회사·서비스 공지는 확인 |
| 파이썬을 설치한 적 없음 | 없음 | 할 일 없음 |
10/21 20:39~22:23(KST)에 버전 지정 없이 pip install litellm 또는 -U 업그레이드 |
높음 | 아래 ‘해야 할 일’ 전부 진행 |
| 그 시간 무렵 LiteLLM을 의존성으로 쓰는 다른 도구를 새로 설치 | 있을 수 있음 | 설치된 litellm 버전 확인 |
도커로 latest·main-latest·main-stable·v1.107.0을 20:46~23:20에 받아 실행 |
높음 | 컨테이너·이미지 폐기 후 열쇠 교체 |
litellm==1.106.2처럼 버전을 고정해 둠 |
낮음 | 고정 버전이 1.107.0이 아닌지만 확인 |
| LiteLLM 기업용 비공개 배포판 사용 | 없음 (회사 발표) | 할 일 없음 |
확인은 파이썬을 켜지 않는 방법부터 하는 게 안전해요. 감염된 환경에선 파이썬·pip를 실행하는 순간 악성코드가 다시 돌기 때문이에요. 아래처럼 파일 이름으로 찾아보기를 먼저 해 보세요.
| 운영체제 | 확인 명령 (터미널·PowerShell) | 무엇이 나오면 위험 |
|---|---|---|
| 맥·리눅스 | find / -name "cook.pth" 2>/dev/nullfind / -type d -name "litellm-1.107.0.dist-info" 2>/dev/null |
경로가 하나라도 출력되면 감염 확정 |
| 윈도우 | Get-ChildItem C:\ -Recurse -Filter cook.pth -ErrorAction SilentlyContinue |
파일이 보이면 감염 확정 |
| 도커 | docker images --digests | grep litellm |
다이제스트가 sha256:1bbcb144…로 시작하면 감염 이미지 |
| 프로젝트 파일 | requirements.txt·poetry.lock·uv.lock에서 litellm 버전 확인 |
1.107.0이 적혀 있으면 해당 |
주의할 점 하나. LiteLLM은 “파일이 나오면 감염 확정, 안 나와도 깨끗하다는 증거는 아니다”라고 했어요. 컨테이너는 지우면 흔적도 사라지고, 임시 폴더 정리로 표식 파일이 없어질 수 있거든요. 그 시간에 설치·실행한 기억이 있다면 감염됐다고 가정하는 게 맞아요.
해당된다면, 이 순서대로
집 열쇠를 잃어버렸을 때를 생각해 보세요. 도둑이 아직 집 안에 있다면 먼저 내보내고(삭제), 문을 새로 달고(재설치), 마지막으로 모든 자물쇠를 바꿔야(열쇠 교체) 해요. 순서가 중요해요.
| 순서 | 할 일 | 왜 |
|---|---|---|
| 1 | pip부터 치지 말기. 셸(터미널)에서 감염된 site-packages의 cook.pth, cook.py, sitecustomize.py와 __pycache__ 속 cook*.pyc·sitecustomize*.pyc 삭제 |
파이썬을 켜면 또 실행되니까요 |
| 2 | 숨어 도는 파이썬 프로세스 종료 (/tmp/remote_code_loader.lock을 쥐고 있는 프로세스) |
뒷문이 계속 열려 있지 않도록 |
| 3 | litellm==1.106.2로 버전 고정해 재설치. 가능하면 가상환경·도커 이미지를 처음부터 새로 짓기 |
남은 찌꺼기까지 없애기 |
| 4 | 깨끗한 다른 컴퓨터에서 그 PC·서버가 닿을 수 있던 열쇠를 전부 교체: 클라우드 역할·키, LiteLLM에 저장한 AI 키·마스터 키, DB 비밀번호, 환경변수 비밀값, Git·npm·PyPI 토큰, SSH 키, 브라우저 저장 비밀번호 | 인터넷이 연결돼 있었다면 이미 전송됐다고 봐야 해요 |
| 5 | 클라우드 접속 기록 점검 (예: AWS CloudTrail에서 설치 시각 전후 GetCallerIdentity, 회사 밖에서의 열쇠 사용) |
이미 누가 내 열쇠로 들어왔는지 확인 |
| 6 | AI 서비스 사용량·청구서, 깃허브 보안 로그 확인 | 요금 폭탄·코드 변조 조기 발견 |
참고로 sitecustomize.py는 일부 리눅스 배포판이나 회사 환경에서 원래부터 쓰는 경우도 있어요. 감염 환경의 site-packages에서 cook.pth와 함께 생긴 파일인지(생성 시각 등) 확인한 뒤 지우면 더 안전해요. 가장 깔끔한 방법은 역시 환경을 통째로 새로 만드는 거예요.
# 예시: 버전을 '정확히' 고정해서 설치하기 (감염 정리 후, 새 가상환경에서)
python -m venv .venv-clean
# (가상환경 활성화 후)
pip install "litellm==1.106.2"개발자가 아니어도 챙길 ‘공급망 시대’ 습관
| 습관 | 일상 버전 | 개발·회사 버전 |
|---|---|---|
| 자동 최신화의 양면 알기 | 앱 자동 업데이트는 대체로 켜 두되, 이상하면 공지 확인 | 운영 서버는 latest 대신 버전·다이제스트 고정, 새 버전은 며칠 지켜본 뒤 반영 |
| 출입증(토큰) 관리 | 안 쓰는 앱 연결·로그인 기기 정리 | 토큰은 최소 권한·짧은 유효기간, 쓰지 않는 CLI 토큰 폐기 |
| 기록에도 비밀이 남는다 | 메신저·메모에 비밀번호 적어 두지 않기 | AI 도구·프록시 로그에 비밀값이 남지 않게 마스킹, 로그 서버를 인터넷에 열어 두지 않기 |
| 이름 한 글자 의심하기 | 택배·은행 문자 속 주소 철자 확인 | 의존성·저장소 이름 오타 스쿼팅(BerriAI vs Berri-AI) 점검 |
| 관리자 권한은 무겁게 | 가족 공유 계정에 결제 권한 주지 않기 | 조직 최고 관리자 계정 최소화, 보호 규칙 우회에도 2인 승인 |
오해하기 쉬운 포인트
| 오해 | 사실 |
|---|---|
| “공식 사이트에서 받았으니 안전하다” | 이번엔 공식 창고·공식 서명을 거쳐 나왔어요. 공식 경로는 필요조건이지 충분조건이 아니에요 |
| “LiteLLM을 import 안 했으니 괜찮다” | 설치만 돼 있어도 파이썬을 켜는 순간 실행돼요 |
| “litellm만 지우면 끝” | 패키지 폴더를 지워도 악성 파일 3개는 남아요. 따로 지우고, 열쇠까지 바꿔야 해요 |
| “2시간뿐이니 피해는 미미” | 주 2,300만 다운로드 규모라 자동 빌드·CI가 많이 받았을 수 있어요. 피해 규모는 아직 조사 중이에요 |
| “일반 AI 앱 사용자도 비밀번호를 다 바꿔야 한다” | 아니에요. 직접 설치·실행한 환경이 대상이에요. 그냥 AI 서비스를 쓰는 분은 서비스 공지만 확인하면 돼요 |
정리하면
| 누구 | 오늘 할 일 한 줄 |
|---|---|
| 일반 사용자 | 직접 설치한 게 없다면 할 일 없음. 이용 중인 AI 서비스·회사 공지만 확인 |
| 파이썬으로 AI 공부·사이드 프로젝트 하는 분 | cook.pth 파일 검색 → 나오면 삭제·재설치·열쇠 교체, 앞으로는 버전 고정 |
| 회사 개발·인프라 담당 | 10/21 20:39~23:20(KST) 빌드·배포 기록, 도커 다이제스트 확인 → 해당 환경 폐기·전 자격 증명 교체·로그 점검 |
이번 사건은 “열쇠를 가진 사람의 출입증”이 가장 약한 고리라는 걸 다시 보여 줬어요. 보호 규칙도, 승인 절차도, 서명도 있었지만 출입증 세 장 앞에서는 한 번에 열렸죠. 우리에게 남는 숙제는 의외로 소박해요. 버전을 고정하고, 토큰을 아끼고, 기록 속 비밀번호를 치우는 것. 오늘 저녁 내 컴퓨터의 열쇠꾸러미를 한 번 점검해 보세요.