LiteLLM 1.107.0 공급망 공격, AI 서비스 운영 기업이 확인해야 할 3가지

핵심 POINT

LiteLLM은 2026년 10월 21일 공식 블로그에 사고 보고를 올리고, 이날 새벽 자사 릴리스 파이프라인이 침해돼 1.107.0 버전이 PyPI(파이썬 패키지 저장소)와 도커 레지스트리로 배포됐다고 밝혔습니다. 이 버전에는 자격 증명을 훔치고 원격 코드 실행 도구를 불러오는 악성코드가 들어 있었다고 설명했습니다.

마이크로소프트 보안 연구팀은 10월 23일 분석 글을 공개하고, 이 악성코드가 Python이 시작될 때 자동으로 실행되는 구조라고 설명했습니다. 개발자 PC, 빌드 서버, 컨테이너처럼 LiteLLM 게이트웨이를 쓰지 않는 환경도 해당 패키지가 설치돼 있었다면 영향을 받을 수 있다는 뜻입니다.

이 글에서는 영향 범위와 시간대, 악성코드의 동작 방식, 내 환경이 해당되는지 확인하는 방법, 복구 순서와 기업의 공급망 점검 항목을 차례로 살펴봅니다.

■ LiteLLM 1.107.0 사고, 무슨 일이 있었을까요?

출처: AI(ChatGPT) 생성 이미지

LiteLLM은 여러 AI 모델 제공사의 API를 하나의 방식으로 호출하게 해 주는 오픈소스 Python 라이브러리이자 프록시 서버입니다. 마이크로소프트는 LiteLLM이 애플리케이션과 모델 제공사 사이의 게이트웨이로 쓰이는 경우가 많아, 모델 제공사 API 키와 데이터베이스 접속 정보, 워크로드 신원 같은 민감한 정보에 접근할 수 있다고 설명했습니다.

LiteLLM이 공개한 영향 범위를 배포 경로별로 정리하면 아래와 같습니다.

[표] LiteLLM 1.107.0 영향 범위, 시간은 UTC 기준이며 괄호 안은 한국 시간 (LiteLLM 사고 보고, 2026.10.21)

LiteLLM은 PyPI에서 이 시간대에 버전을 고정하지 않고 설치했거나, 도커 이미지를 위 태그로 실행했다면 영향을 받은 것으로 가정하라고 안내했습니다. 비공개 레지스트리를 쓰는 엔터프라이즈 고객은 영향이 없었다고 밝혔고, GitHub의 공식 1.107.0 소스 태그에는 악성 파일이 들어 있지 않았다고 설명했습니다. 악성 아티팩트는 공격자가 통제하는 저장소에서 빌드됐다는 것이 LiteLLM의 설명입니다.

LiteLLM은 10월 23일 공개한 원인 분석에서, 공격자가 개발자 GitHub 인증 토큰을 확보해 릴리스 설정을 바꾸고 정상 저장소와 이름이 비슷한 저장소를 소스로 지정해 배포했다고 설명했습니다. 마이크로소프트는 공격자가 처음 어떻게 상위 환경에 접근했는지는 독립적으로 확인하지 못했다고 밝혔습니다.

■ 악성코드는 어떻게 동작했을까요?

출처: AI(ChatGPT) 생성 이미지

마이크로소프트 분석에 따르면 악성 휠에는 cook.pth, cook.py, sitecustomize.py 파일이 들어 있었습니다. 설치 과정에서 이 파일들이 litellm 폴더 밖의 Python 라이브러리 경로로 옮겨지고, Python이 시작될 때 자동으로 읽히는 구조입니다.

❶ LiteLLM을 쓰지 않아도 실행될 수 있었습니다

마이크로소프트는 애플리케이션이 LiteLLM을 불러오지 않아도 해당 환경에서 Python을 시작하는 것만으로 페이로드가 실행될 수 있다고 설명했습니다. 실제로 윈도우 환경에서 관련 없는 패키지를 설치하려고 Python을 실행했을 때 수집 코드가 동작한 사례도 확인했다고 밝혔습니다.

❷ 개발 환경과 클라우드 자격 증명을 수집했습니다

수집 코드는 AI 코딩 도구와 IDE 설정, Git과 패키지 관리자 설정, AWS·Azure·Google Cloud 자격 증명 캐시, 쿠버네티스 서비스 계정 파일, 브라우저 저장 정보, SSH 키, 환경 변수를 대상으로 설계돼 있었습니다. LiteLLM 프록시 데이터베이스에서 자격 증명과 모델 설정 일부를 읽는 기능도 있었습니다. 마이크로소프트는 코드에 대상이 적혀 있다고 해서 실제 접근에 성공했다는 뜻은 아니라고 덧붙였습니다.

❸ 수집한 데이터는 암호화해 외부로 전송했습니다

수집한 정보는 암호화한 뒤 공격자 서버(www.litellm.dev)로 전송하도록 만들어져 있었습니다. 유닉스 계열 시스템에서는 추가 파이썬 코드를 내려받아 실행하는 로더도 포함됐지만, 마이크로소프트는 인용한 연구자들이 해당 주소 정보를 확인했을 때 내용이 비어 있었고 추가 코드의 실행은 확인하지 못했다고 밝혔습니다. 다만 이 주소는 바꿀 수 있어서 이후 원격 코드 실행에 쓰일 여지가 있었다고 설명했습니다.

■ 내 환경이 영향을 받았는지 확인하는 방법

출처: AI(ChatGPT) 생성 이미지

마이크로소프트는 의심되는 환경에서 python, pip 같은 명령을 실행하지 말고, 신뢰할 수 있는 별도 시스템에서 점검하라고 권고했습니다. Python을 시작하면 악성 파일이 다시 실행될 수 있기 때문입니다. 이 점을 염두에 두고 아래 세 가지를 확인하세요.

❶ 설치 이력과 이미지 확인

• 설치된 환경, uv와 pip 캐시, 사내 패키지 미러, 잠금 파일(lock file), 빌드 결과물에 litellm 1.107.0이 있는지 확인합니다.

• 컨테이너는 태그가 아니라 이미지 다이제스트로 확인합니다. LiteLLM은 다이제스트 sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e 이미지를 실행한 적이 있다면 침해된 것으로 보라고 안내했습니다.

• 2026년 10월 21일 20시 39분부터 23시 20분(한국 시간) 사이에 버전을 고정하지 않고 설치했거나 새로 받은 이미지가 있는지 확인합니다.

❷ 악성 파일 흔적 확인

• litellm-1.107.0.dist-info, cook.pth, sitecustomize.py 파일이 있는지 파일 시스템에서 찾아봅니다.

• 하나라도 발견되면 노출이 확인된 것입니다. 하지만 발견되지 않았다고 해서 깨끗하다는 증거는 아니라고 LiteLLM은 설명했습니다.

❸ 네트워크와 프로세스 흔적 확인

• 방화벽, 프록시, DNS 로그에서 litellm.dev 도메인으로 나간 접속 기록을 확인합니다.

• 유닉스 계열 서버에서는 /tmp/remote_code_loader.lock 파일이나 백그라운드 Python 프로세스가 있는지 확인합니다. 전송이 성공하면 /tmp/.pc_once_로 시작하는 표식 파일이 남을 수 있지만, 컨테이너나 임시 폴더 정리로 사라질 수 있어 없다고 해서 안전하다고 단정할 수 없습니다.

마이크로소프트는 Microsoft Defender 제품 사용자를 위해 탐지 이름과 고급 헌팅 쿼리도 함께 공개했습니다. 파일 이름 하나만으로 침해를 단정하지 말고 해시, 프로세스 이력, 네트워크 목적지를 함께 비교하라는 것이 마이크로소프트의 권고입니다.

■ 영향을 받았다면 따라야 할 복구 순서

‍

LiteLLM과 마이크로소프트가 공통으로 강조한 점은 패키지를 지우는 것만으로는 복구가 끝나지 않는다는 것입니다. 복구 순서는 다음과 같습니다.

• 영향받은 환경에서 pip install부터 실행하지 않습니다. Python을 시작할 때마다 악성 파일이 다시 실행될 수 있습니다.

• 셸에서 해당 라이브러리 경로의 악성 파일과 관련 캐시 파일을 삭제하고, 백그라운드에서 동작 중인 Python 프로세스를 종료합니다. 가상 환경과 이미지는 처음부터 다시 구축하는 편이 더 안전하다고 안내했습니다.

• LiteLLM은 사고 직후 1.106.2처럼 이전에 배포된 버전으로 고정해 설치하라고 안내했습니다. 이후 새 릴리스 계획도 밝혔으므로, 설치 전에 LiteLLM 공식 공지에서 현재 권장 버전을 확인하세요.

• 인터넷에 나갈 수 있는 환경에 1.107.0이 설치된 적이 있다면 정보 전송이 성공한 것으로 보고 대응합니다.

• 깨끗한 다른 컴퓨터에서 접근 가능했던 자격 증명을 모두 교체합니다. LiteLLM 프록시 데이터베이스에 저장된 모델 제공사 API 키와 마스터 키, 데이터베이스 접속 비밀번호, 인스턴스 IAM 역할, 환경 변수에 있던 모든 비밀값이 대상입니다.

• 마이크로소프트는 교체만으로 모든 토큰이 즉시 무효가 된다고 가정하지 말고, 해당 계정의 세션도 함께 폐기하라고 권고했습니다. 클라우드 로그에서 설치 시점 전후로 IAM 역할 자격 증명이 외부에서 쓰였는지도 확인합니다.

■ 기업 보안 담당자의 공급망 점검 항목

‍

이번 사고는 유명한 오픈소스를 쓰더라도 배포 경로가 침해되면 정상 패키지 이름으로 악성코드가 들어올 수 있음을 보여 줍니다. 아래 항목을 점검해 보세요.

• 개발 환경과 빌드 서버, 사내 패키지 미러의 LiteLLM 사용 여부와 버전을 자산 단위로 파악합니다. AI 도구는 개발자 개인이 설치하는 경우가 많아 누락되기 쉽습니다.

• 의존성은 해시를 고정한 잠금 파일로 관리하고, 컨테이너는 latest 같은 가변 태그 대신 다이제스트로 지정합니다.

• 사내 미러에는 검토를 거친 패키지만 들이고, 새 버전을 자동으로 받아 바로 배포하는 구조인지 점검합니다.

• 개발 PC, 빌드 서버, AI 게이트웨이 호스트의 외부 접속을 제한하고, 필요한 목적지만 허용합니다.

• AI 게이트웨이에 저장된 모델 제공사 키와 클라우드 자격 증명은 최소 권한으로 발급하고, 유출 시 즉시 폐기할 수 있는 절차를 마련합니다.

• 개발 도구가 사용하는 토큰은 서비스 계정과 범위를 제한한 권한으로 분리합니다. LiteLLM도 원인 분석에서 노출된 키를 폐기하지 않았고, 범위를 좁히지 않은 토큰을 사용한 점을 확인했다고 밝혔습니다.

SK쉴더스는 보안 컨설팅과 관제 서비스를 통해 기업이 소프트웨어 공급망과 개발 환경의 위협을 점검하도록 지원하고 있습니다.

■ 자주 묻는 질문

‍

Q. LiteLLM을 쓰지 않는 서버도 영향이 있나요?

A. LiteLLM 1.107.0이 설치되지 않은 환경은 이번 악성 파일의 직접 대상이 아닙니다. 다만 마이크로소프트는 LiteLLM 게이트웨이를 쓰지 않는 개발자 PC, 빌드 서버, 테스트 환경에도 패키지가 설치돼 있었다면 영향을 받을 수 있다고 설명했습니다. 직접 쓰지 않더라도 다른 도구의 의존성으로 설치됐을 수 있어 설치 이력 확인이 필요합니다.

Q. 1.107.0 이전 버전은 안전한가요?

A. LiteLLM은 이전 버전은 모두 안전하다고 밝혔고, 문제가 된 릴리스는 모두 회수했다고 안내했습니다. 그래도 설치 시점에 공식 공지를 확인하고, 버전을 고정해 설치하는 것이 안전합니다.

Q. 엔터프라이즈 버전을 쓰면 영향이 없나요?

A. LiteLLM은 비공개 레지스트리에서 엔터프라이즈 릴리스를 받는 고객은 영향이 없었다고 밝혔습니다. 오픈소스 PyPI나 공개 도커 이미지를 받아 쓰는 경우는 위 시간대에 해당하는지 확인해야 합니다.

Q. 패키지를 삭제하고 다시 설치하면 충분한가요?

A. 충분하지 않습니다. 악성 시작 파일이 litellm 폴더 밖에 놓였기 때문에 패키지만 지우면 남을 수 있다고 마이크로소프트가 설명했습니다. 환경을 새로 구축하고, 접근 가능했던 자격 증명을 모두 교체해야 합니다.

Q. 이번 사고가 이전 LiteLLM 사고와 같은 건가요?

A. 이번 사고는 2026년 10월 21일에 배포된 1.107.0 버전에 해당하는 별도 사고입니다. 3월에도 다른 버전(1.82.7, 1.82.8)에 악성코드가 삽입된 사고가 있었고, 이번 대응은 3월과 다른 버전인지 구분해서 확인하세요.

[콘텐츠 출처]

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)

Microsoft Security Blog, Inside the LiteLLM 1.107.0 supply chain compromise (2026.10.23)