요약
PyPI에 올라온 LiteLLM 1.107.0에 파이썬을 켤 때마다 실행되는 자격 증명 탈취 도구와 백도어가 숨어 있었습니다.
보안 업체 세이프뎁이 10월 21일 공개한 분석입니다. LLM API 호출을 중계하는 파이썬 라이브러리 LiteLLM의 새 버전이 GitHub 소스에 없는 파일 세 개를 몰래 설치했습니다. PyPI는 올라온 지 약 두 시간 만에 이 버전을 내렸습니다.
왜 중요한가
- litellm을 불러오지 않아도 설치만 돼 있으면 pip, IDE, CI 작업 등 모든 파이썬 프로세스에서 악성 코드가 돕니다.
- 공개 저장소에는 악성 커밋이 없어서 소스 코드를 검토해서는 찾을 수 없었습니다.
- 클라우드·SSH 키부터 AI 코딩 도구 토큰, 프록시 DB에 저장된 LLM API 키까지 노려 피해 범위가 넓습니다.
핵심 내용
- .pth 파일(파이썬이 시작할 때 자동으로 읽는 파일)이 탈취 코드를 불러와 비밀값을 공격자 도메인 www.litellm[.]dev로 빼돌렸습니다.
- sitecustomize.py 백도어는 매시간 GitHub 파일에서 서버 주소를 읽어 추가 코드를 내려받아 실행했습니다.
- 그 GitHub 계정은 13시 40분(UTC)에 삭제됐지만, 그 전에 감염된 호스트는 2단계 코드를 이미 실행했을 수 있습니다.
- 소스 배포본 설정에 몰래 들어간 한 줄을 근거로, 세이프뎁은 비공개 릴리스 파이프라인이 조작된 소스로 빌드했다고 봤습니다.
- 1.106.2와 1.107.0rc1·rc2, 함께 설치되는 보조 패키지는 깨끗합니다.
HN 반응
- 3월에 이어 올해 두 번째 공급망 공격이라는 점에서, 당분간 이전 버전에 고정해 두겠다는 이용자가 많았습니다.
- 일부 이용자는 출처 증명(배포한 워크플로를 보증하는 서명)이 어떤 소스를 빌드했는지까지는 보증하지 못한다고 지적했습니다.
다들 https://canarytokens.org/ 라는 게 있다는 걸 잊지 마시라고 한마디 남깁니다.
오늘 또 하나 배웠네요! 이거 멋지네요.
맞아요, 해킹당했다는 사실을 아는 게 $x 이상의 가치가 있다고 생각해서, 암호화폐를 전혀 안 하는데도 $x에 해당하는 금액을 눈에 확 띄는 곳에 "소프트웨어 지갑"으로 컴퓨터에 놔두는 사람들이랑 별로 다르지 않죠.
해킹당했다는 걸 반드시 알 수 있는 건 아니지만, 그래도 꽤 괜찮은 경보 장치예요. 그리고 말씀하신 것과 같은 일을 암호화폐용으로 해 주는 서비스도 있어요. "어떤 주소의 코인"이 한 번이라도 움직이면 이메일이나 문자, 심지어 우편으로까지 알려 줍니다.
sandbox-exec과 Lulu 규칙을 아무리 늘어놔도 이런 건 막지 못합니다.
어느 순간 권한 팝업 피로감이 쌓이면, 우리는 어떤 권한이든 당연하다는 듯이 내주기 시작합니다. 도구를 설치하는 데도 무뎌집니다. brew, npm이 그냥 몸에 뱁니다.
"패키지 X가 도구를 367개나 깔았다고? 응, 요즘 다 그런 거겠지."
"brew가 오래된 패키지 59개가 있다고? 업그레이드해야지." "응, 끝. 완벽해."
게다가 에이전트와 하네스까지 등장했습니다. 일어날지 말지의 문제가 아니라 언제 일어나느냐의 문제입니다! OS가 이 문제를 어떻게든 해결해야 합니다. 하다못해 더 낫고, 더 쉽고, 더 가벼운 VM으로 사용자가 완전히 분리된 "프로그램 공간"을 편하게 쓰게 해 줘야 합니다. 알아요, 압니다. 유닉스와 리눅스는 알렉산드로스 3세가 기저귀를 차기도 전에 이미 이걸 다 해결해 놨다는 거죠. 물론 그렇겠죠.
아니, 모든 웹사이트에서 5단계 인증을 하고, 눈만 한 번 떼도 로그인 과정을 처음부터 다시 거치는 게 얼마나 중요한데요.
[지연됨]
항문 탐침도 추가할 준비 되셨어요?
뭐 하려고요, chess.com 때문에요?
이봐요! 바닥에 치약을 온통 뱉어 버렸잖아요!
아니요, 샌드박싱 도구로 이런 건 막을 수 있습니다. 저는 LLM 에이전트에 Nono라는 도구를 쓰는데, macOS 구현이 sandbox-exec과 같은 기반 위에 만들어져 있습니다. 이 도구가 지원하는 핵심 기능 하나(이런 도구가 이것만 있는 것은 아닙니다)는 프록시와, 프록시를 통한 자격 증명 주입입니다. 예를 들어 제가 회사에서 Codex를 돌릴 때, Codex는 제 Azure AI Foundry API 자격 증명에 접근할 수 없습니다. 가짜 자격 증명으로 요청을 보내면, 샌드박스 밖에 있는 프록시가 진짜 자격 증명을 끼워 넣습니다.
이 프록시는 네트워크 접근을 여러 방식으로 제한하는 역할도 합니다. 그래서 LiteLLM 같은 것도 인터넷 전체에 접근하지 못하게 하고 Azure AI Foundry나 AWS Bedrock 같은 추론 제공자하고만 통신하도록 돌릴 수 있습니다. LiteLLM은 에이전트와 따로 샌드박싱하고, 훨씬 적은 권한만 줍니다. 소프트웨어 방화벽이 완벽하지는 않지만, 이런 공격을 막는 데 상당한 방어책이 됩니다.
이 밖에도 쉽게 적용할 수 있고 피해를 줄여 주는 제한이 많습니다. Nono는 $HOME의 루트 접근을 막은 뒤 그 안의 경로를 선택적으로 허용하고, 비밀 정보가 흔히 있는 경로도 명시적으로 막습니다. 그래서 SSH 자격 증명, GnuPG 소켓(그리고 로컬 유닉스 소켓 전반), 로컬 OS 키링 같은 중요한 것에 접근하지 못하게 하기가 꽤 쉽습니다.
저는 이런 도구를 오직 정책을 쓰고, 테스트하고, 정책이 부족한 곳을 고치는 식으로만 씁니다. 승인을 하지 않으니 승인 피로감도 없습니다.
이런 공격은 막기 어렵다는 말씀, 우리가 도구가 마구 늘어나는 데 익숙해졌다는 말씀, 그리고 LLM이 우리가 예상하지 못한 도구를 알아서 설치할 수도 있다는 말씀은 맞습니다! 하지만 이런 공격을 예상하고 완화할 방법은 있습니다. 자격 증명 주입을 지원하는 샌드박싱 도구(컨테이너와 VM 포함)는 이런 상황에서 정말 쓸모가 있습니다.
그 Nono라는 도구가 공급망 공격을 당해서 여러분의 Azure 자격 증명을 엉뚱한 곳으로 신나게 보내고, 모네로 채굴 같은 걸 시작하기 전까지만 안전하겠죠.
LiteLLM도 대체로 같은 시나리오로 자주 쓰입니다. LAN 안에서만 쓰는 가상 키를 받고, 추론 제공자에게 요청을 중계하면서 진짜 키로 바꿔 주는 식이죠.
LiteLLM은 샌드박싱 도구가 아니라서, 모든 게 의도대로 돌아가더라도 위험을 줄이는 효과가 그만큼 크지 않습니다.
그리고 nono가 sandbox-exec보다 더해 주는 것은 플랫폼 전반에 걸친 통일된 인터페이스와 몇 가지 정책 관리 도구입니다. 똑같은 제한을 OS 내장 방식인 Seatbelt나 sandbox-exec 같은 내장 인터페이스로 직접 걸 수도 있습니다. nono, zerobox, 앤트로픽의 srt, Seatbelt, landrun, Bubblewrap, Fence 같은 OS 수준 샌드박싱 도구를 Docker의 sbx, smolvm, krunvm, microsandbox, Shuru 같은 VM 기반 도구와 함께 쓸 수도 있고요. 그러면 서로 무관한 두 프로젝트에서 공급망 공격이 동시에 딱 맞물려 터져야 합니다.
"결국 보안 스택의 어느 부분은 믿을 수밖에 없다"는 말은 별로 흥미롭지도 않고, 공급망 공격을 막을 방법이 없다는 증거도 아닙니다. 샌드박싱 도구가 하나뿐이고 VM 기반이 아닌 OS 수준이라 해도, 그것은 업데이트를 평가할 때 특별히 신경 쓸 수 있는 스택의 한 부분이 됩니다. LiteLLM으로는 그게 안 됩니다.
게다가 이제 LiteLLM 관리자들이 릴리스 파이프라인을 잘 잠가 두리라 믿는 건 무모해 보인다는 경험적 사실도 있습니다. 7개월 사이에 공급망 공격을 두 번째로 당했습니다. 마음에 드는 샌드박싱 도구를 골라서 릴리스 파이프라인, 코드 서명 요건, 증명(attestation) 전략 같은 것들을 감사한 다음, LiteLLM을 그 도구의 샌드박스 안에 넣는 편이 "뭐든 믿어야 하니까 LiteLLM이라고 못 믿을 게 뭐야!" 하고 손을 놓아 버리는 것보다 훨씬 현명합니다. nono도 정답이 아닐 수 있습니다. 저도 잘 모르겠고, 제 환경을 어떻게 꾸밀지 아직 이것저것 시험하는 중입니다.
그래도 이 스레드에 나온 패배주의도, 상대주의도 별로 설득력 있게 들리지 않습니다.
네, 엉망이에요. pi 에이전트와 그 확장 기능이 세 시간마다 업데이트를 받는다는 생각이 났어요.
LiteLLM에 대한 중대한 공격이 이번이 두 번째인데, 1~2년 사이였나요? 바로 어젯밤에 예전 Claude 세션에서 나온 메모와 스크립트를 봤거든요. 모든 프로젝트 의존성을 감사해서 litellm을 쓰는 곳이 없는지 확인하는 용도였어요.
그래서 확인해 봤더니 올해 3월이었네요: https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/ . LLM 시대에 시간이란 대체 뭘까요?
올여름에도 주목을 덜 받은(아니, 전혀 못 받은) 다른 건이 하나 있었는데, 인증된 사용자나 가상 키만 있으면 마스터 제공자 키를 빼낼 수 있는 취약점이었습니다.
https://nvd.nist.gov/vuln/detail/cve-2026-84377
그리고 서두에 묻혀 있는데, 뚫린 사람 중 하나가 조직 소유자였습니다. 그러니 보안을 소홀히 하는 문화가 윗선에서부터 나오는 것 같고, 특히 그쪽이 "여러분, 이건 누구한테나 일어날 수 있는 일이었어요" 하는 식으로 굴고 있어서 더 안타깝습니다.
맞아요, 저는 이제 다시는 업그레이드 안 할 것 같아요. 1.04.2로 한두 해는 버틸 겁니다. 이쯤 되면 러시안 룰렛 같아요.
3년 동안 커밋이 5만 5천 개나 쌓인 프로젝트에서 어떻게 이런 일이 생길 수 있죠?
침해는 빌드와 배포 시스템 어딘가에서 일어난 것으로 보입니다.
지금 모든 하네스가 이렇게 생각하고 있겠죠. "이런 걸 하고 싶으면 아무것도 침해할 필요조차 없겠네."
비꼬시는 거죠?
하하, 네, 죄송해요.
느낌표를 더 붙이셨어야죠 :)
신사의 /s 태그죠.
그러니까 3년에 커밋 5만 5천 개면 주 7일 근무로 하루에 55개쯤이잖아요. 아무도 그걸 다 꼼꼼히 볼 수는 없다는 걸 충분히 짐작할 수 있죠.
이번 사고는 저장소에 커밋된 내용과는 관련이 없습니다. 자세한 정보: https://docs.litellm.ai/blog/security-incident-oct-21-2026
"공격자가 서로 다른 개발자 GitHub 자격 증명 3개를 탈취했다"는 대목이 좀 무섭습니다. 구조적인 문제로 보입니다. 개발자 세 명의 키가 털렸다면 진짜 문제는 다른 곳에 있다는 뜻이니까요.
한 명을 뺀 모든 개발자의 권한을 취소했다는데, 아마 올바른 대응일 겁니다. 그래도 저라면 LiteLLM을 "이 버전 이전의 어떤 버전"으로 고정해 두고, 추가 공지가 있을 때까지 그대로 두겠습니다!
누가 어떻게 릴리스에 파일을 몰래 끼워 넣었는지 이해가 안 됩니다.
제가 읽은 내용은 빌드 파일에서 디렉터리를 만든다는 것뿐이고, 새 파일이나 추가된 의존성이 어떻게 검문을 통과했는지에 대한 설명은 없는 것 같습니다.
cook.pth가 설치할 때 PyPI에서 자동으로 내려받는 의존성이었고, 빌드 시스템이 그걸 의존성에 넣은 건가요?--
다른 분들을 위해 남겨 둡니다.
이해가 됩니다. 의존성이 모두를 대상으로 탈취된 것이 아니라, 관리자나 비공개 파이프라인이 공격당했고 관리자의 로컬 사본을 선점하는 방식으로 악성 의존성이 거기에 주입된 것이군요. 아주 영리합니다.
그 말이 맞다면 증명(attestation)이 있었어도 이번에는 아무도 구하지 못했을 겁니다. 증명은 어떤 워크플로가 휠을 게시했는지를 보증할 뿐, 그 워크플로가 어떤 소스를 체크아웃했는지는 보증하지 않으니까요. 겉보기에 같은 저장소에서 빌드하는 비공개 파이프라인이라면 완벽하게 유효한 증명이 나옵니다.
이걸 잡아낼 수 있는 건 공개 태그에서 다시 빌드해 결과물을 비교하는 사람인데, 파이썬 휠에 대해서는 그렇게 하는 사람이 거의 없습니다. 저는 제 프로젝트의 릴리스에서 증명이 해답이라고 여기고 있었는데, 증명이 어디까지만 유효한지 되새기게 해 주는 좋은 사례네요.
공식 사고 보고서: https://docs.litellm.ai/blog/security-incident-oct-21-2026