LiteLLM 1.107.0에 자격 증명 탈취 악성코드 포함(2026년 10월): 영향받은 PyPI 릴리스와 Docker 이미지, 사용자가 해야 할 일

회사가 밝힌 영향받은 아티팩트는 다음과 같습니다. 모든 시각은 2026년 10월 21일입니다.

회사는 해당 시간대에 버전을 고정하지 않고 pip로 LiteLLM을 설치했거나, 해당 시간대에 이 태그 중 하나로 컨테이너를 시작했다면 영향을 받은 것이라고 밝혔습니다. CI가 빌드할 때마다 pip install litellm을 실행하거나 Dockerfile이 latest 태그를 FROM으로 빌드한다면, 아무도 조작하지 않아도 영향받은 버전이 설치되었을 수 있습니다.

• 영향받았을 가능성이 있는 환경에서는 버전을 확인하려고 Python이나 pip를 실행하지 마세요. 먼저 격리한 뒤, 별도의 깨끗한 기기에서 배포 기록이나 이미지 다이제스트를 확인하세요. 노출 가능성을 배제할 수 없으면 영향받은 것으로 취급하고 아래의 재구축과 자격 증명 교체로 진행하세요(이 사이트의 참고). 회사의 버전 확인 명령도 Python을 시작하므로 정리 전에는 실행하지 마세요
• 회사는 찾아야 할 파일 이름과 이미지 다이제스트를 공개했습니다. 발견되면 노출이 확인되지만, 발견되지 않았다고 해서 환경이 깨끗하다는 증거는 아닙니다
• 1.106.2 이하 또는 1.107.0rc1, rc2를 명시적으로 고정해 두었다면 영향을 받지 않습니다(회사는 이전 버전이 이번 침해와 무관하다고 밝혔습니다)
• 비공개 엔터프라이즈 레지스트리에서 받은 고객은 영향을 받지 않았습니다(회사)

회사 공지에 인용된 제보자의 분석에 따르면 악성코드는 Python이 시작될 때마다 자동으로 로드되는 파일로 설치됩니다. litellm을 import하지 않는 프로세스나 pip 자체를 포함해 모든 Python 프로세스에서 다시 실행됩니다.

회사가 제시한 정리 순서는 다음과 같습니다(파일 이름과 위치는 공지 페이지에 있습니다).

• Python을 시작하지 않고, 쉘에서 영향받은 모든 site-packages 디렉터리의 악성 파일(회사가 명시한 파일과 캐시 파일)을 삭제합니다
• 백그라운드에 남아 있는 Python 프로세스를 중지합니다
• 그런 다음에만 litellm==1.106.2로 고정해 다시 설치합니다. 회사는 이미지와 가상 환경을 처음부터 다시 만드는 편이 더 낫다고 밝혔습니다

컨테이너로 실행했다면, 영향받은 이미지로 만든 컨테이너를 중지하고 깨끗한 버전으로 고정한 이미지로 다시 만드는 것이 대개 가장 빠릅니다(이 사이트의 참고).

회사는 첫 게시물에서 1.106.2 또는 이번 사고 이전에 공개된 명시적 버전으로 고정하라고 요청했습니다. 이후 10월 24일(UTC)에 1.103.8, 1.104.6, 1.105.4, 1.106.3을 공개했습니다. PyPI의 최신 버전은 1.106.3이며, 1.107.0은 계속 삭제된 상태입니다. 릴리스 노트에 따르면 이 버전들은 SDK, 프록시, Docker 이미지가 신뢰하는 모든 인증서 번들에서 eMudhra 루트 인증 기관을 제거합니다. eMudhra 문제는 eMudhra 중간 CA 키와 관련해 Python 사용자가 해야 할 일에서 다룹니다.

Docker에서는 latest나 main-stable처럼 내용이 바뀌는 태그가 아니라 버전 태그, 더 좋게는 다이제스트(이미지 내용으로 계산한 값)로 이미지를 참조하세요. 그러면 태그가 가리키는 대상이 바뀌어도 영향을 받지 않습니다.

릴리스 노트에 따르면 10월 24일 릴리스부터 Docker 이미지와 Helm 차트는 새 cosign 키로 서명되며(cosign은 컨테이너 이미지에 서명하고 검증하는 도구), 이전 키로 검증하면 실패합니다. 서명을 확인하는 cosign verify 스크립트, CI 점검, Kubernetes 정책(Kyverno 등)에 이전 cosign.pub을 고정해 두었다면 릴리스 노트에 명시된 커밋의 새 키로 교체하세요. 릴리스 노트에는 새 키의 SHA-256도 나와 있으므로, 교체하기 전에 내려받은 키와 비교하세요(이 사이트의 참고).

회사는 1.107.0이 외부 인터넷에 접속할 수 있는 호스트에 한 번이라도 설치되었다면 탈취된 데이터가 성공적으로 외부로 전송되었다고 가정하라고 밝혔습니다. 특히 다음을 언급합니다.

• 서버나 컨테이너에 연결된 클라우드 역할(AWS 인스턴스나 작업 IAM 역할 등)
• LiteLLM 프록시 데이터베이스에 저장된 모든 LLM 제공업체 키
• 프록시 마스터 키와 발급한 모든 가상 키
• 데이터베이스 연결 문자열(DATABASE_URL)의 비밀번호
• 호스트에서 실행 중이던 모든 프로세스의 환경에 있던 모든 시크릿

제보자의 분석에서는 악성코드가 SSH 키, Git 및 패키지 게시 자격 증명, Kubernetes 토큰, 브라우저에 저장된 비밀번호, AI 코딩 도우미의 설정도 수집하도록 만들어졌습니다. 개발자 노트북에서 1.107.0을 실행했다면 그 노트북의 자격 증명도 교체해야 합니다.

각 서비스의 대시보드에서 새 키를 발급하고 이전 키를 폐기하세요(이 사이트의 참고: 장애를 피하려면 새 키를 먼저 설정한 뒤 이전 키를 폐기하세요). API 키 취급은 .env 파일과 API 키가 위험한 이유에서 다룹니다.

회사는 설치 시점 전후에 인스턴스 역할로 이루어진 신원 확인 호출(GetCallerIdentity)이 있는지 AWS 감사 로그(CloudTrail)에서 확인하고, 이어서 그 역할의 자격 증명이 자체 인프라 외부에서 사용된 적이 있는지 확인하라고 요청합니다.

이 사이트의 참고로, LLM 제공업체의 대시보드에서도 10월 21일 11:39 UTC(일본 시간 저녁) 이후 예상 밖의 사용량이나 요금 증가가 있는지 확인하세요. 탈취된 LLM 키가 사용되면 사용량과 청구에 나타날 수 있습니다. 탈취된 키로 벌어지는 일은 탈취된 API 키가 계정 정지로 이어지는 과정에서 다룹니다.

영향받은 환경은 버전을 고정하지 않고 pip로 설치했거나 latest, main-latest, main-stable처럼 내용이 바뀌는 태그를 쓴 환경이었습니다. 1.106.2로 고정하고 Docker 이미지를 다이제스트로 참조한 환경은 해당 시간대에 다시 빌드되었더라도 영향을 받지 않았습니다.

우선 운영 환경과 CI에서 쓰는 의존성을 해시가 포함된 잠금 파일로 고정하세요(pip install --require-hashes, 또는 uv나 Poetry의 잠금 파일). 아주 최근에 공개된 버전을 피하는 설정(지정한 시점 이후에 공개된 것을 무시하는 uv의 exclude-newer 등)도 몇 시간 안에 회수되는 릴리스에 대비하는 데 도움이 됩니다. 접근 방식은 OSV-Scanner로 의존성 점검하기에서 다룹니다.

프록시 데이터베이스에는 연결한 모든 제공업체의 키가 들어 있습니다. 지금처럼 교체해야 할 때 어떤 키가 어떤 환경에 속하는지 모르면, 일부를 놓치거나 전부 중단하는 것 중에서 고르게 됩니다.

개발, 테스트, 운영에 서로 다른 제공업체 키를 쓰고 제공업체 쪽에서 지출 한도와 알림을 설정하면 교체 범위가 줄고 악용을 더 빨리 알아챌 수 있습니다. 키가 유출되었을 때 할 일은 AI가 작성한 코드에서 유출된 API 키에서 다룹니다.

근본 원인 분석에 따르면 출발점은 5월에 공개 저장소에 실수로 커밋된 마스터 키였습니다. 커밋은 곧 덮어썼고 노출된 키를 폐기해야 한다는 점도 파악되었지만, 마스터 키는 폐기되지 않았고 약 4개월 반 뒤에 사용되었습니다. 회사는 이번 사고가 노출되었을 수 있는 키를 교체하지 않는 위험을 잘 보여 주는 사례라고 밝혔습니다.

비밀 정보를 공개 저장소에 올렸다면 기록을 걱정하기 전에 키를 폐기하고 교체하세요. 교체한 뒤에는 교체한 키 목록을 확인해 빠진 것이 없는지 점검하세요(이 사이트의 참고). 이 문제는 유효한 채로 남는 유출된 자격 증명에서 다룹니다.

분석에 따르면 처음 탈취된 토큰은 에이전트 플랫폼이 풀 리퀘스트를 열 수 있도록 설정해 둔 것이었습니다. 서비스 계정에 연결되지 않았고 범위도 좁혀지지 않은, 조직 소유자의 개인 GitHub CLI 토큰이었습니다. 회사는 GitHub CLI 토큰이 2단계 인증을 거쳐 발급되며, 민감한 작업 전에 GitHub가 요구하는 재인증의 적용을 받지 않는다고 지적합니다.

에이전트와 봇에는 그 작업 범위로만 한정한 전용 토큰(GitHub App 또는 세분화된 토큰)을 주고, 소유자 권한은 일상 업무에 쓰는 계정과 분리하세요(이 사이트의 참고). CI 시크릿을 필요한 워크플로와 환경에서만 쓸 수 있게 하면 탈취된 토큰이 미치는 범위도 줄어듭니다(이 사이트의 참고). GitHub 계정 보호는 GitHub 2단계 인증 설정하기에서 다룹니다.

이번 원인은 아닌 것으로 밝혀졌지만, 회사의 첫 게시물은 특정 상황에서 AI 코딩 도우미가 사용자의 GitHub CLI 토큰을 응답 본문에 넣을 수 있고, 응답 본문을 기록하는 곳에서는 이러한 토큰이 LiteLLM 로그에 나타날 수 있다고 언급했습니다.

직접 운영하는 게이트웨이라면 세 가지를 확인하세요. 관리 인터페이스와 API가 인터넷에서 직접 접근되지 않는지, 응답 본문을 남기는 로깅 설정을 검토했는지, 남긴다면 보존 기간이 짧은지입니다. GitHub 계정 보호는 GitHub 2단계 인증 설정하기에서 다룹니다.