LiteLLM 해킹 보안: 영향 버전 확인과 대응 순서

LiteLLM 해킹 여부는 설치·실행한 배포물과 시점을 확인해야 판단할 수 있습니다. 2026년 3월에는 PyPI 패키지 1.82.7·1.82.8이 침해됐고, 10월 21일에는 PyPI 1.107.0과 일부 Docker·GHCR 이미지가 영향을 받았습니다. 두 사건 모두 취약한 코드가 발견된 경우가 아니라 배포 과정에서 악성 파일이 포함된 공급망 침해입니다. 해당 배포물이 실제 환경에서 실행됐다면 패키지 제거에 그치지 말고, 그 환경이 접근할 수 있던 비밀정보의 노출 가능성까지 조사해야 합니다.

2026년 LiteLLM 해킹, 무엇이 달라졌나

3월: PyPI 1.82.7·1.82.8 침해

3월 24일 PyPI에 배포된 litellm==1.82.7과 1.82.8은 약 40분간 공개된 뒤 격리·삭제됐습니다. LiteLLM은 당시 공급망 침해가 이 두 배포 버전에 영향을 줬으며, CI/CD에서 사용한 Trivy 보안 스캐너 침해와 관련된 것으로 파악했다고 밝혔습니다. KISA도 영향 버전을 1.82.7·1.82.8로 안내하고 1.82.6 이하 사용을 권고했습니다. 자세한 경위는 LiteLLM의 3월 보안 타운홀 업데이트와 KISA LiteLLM 제품 사용 주의 권고에서 확인할 수 있습니다.

LiteLLM의 당시 설명에 따르면 1.82.7은 프록시 서버 파일을 통한 악성 동작이 있었고, 1.82.8에는 Python 시작 때 자동으로 로드되는 litellm_init.pth가 추가됐습니다. 따라서 1.82.8은 애플리케이션에서 LiteLLM 기능을 직접 호출했는지만으로 실행 여부를 판단하기 어렵습니다.

10월: PyPI와 공식 Docker·GHCR 이미지 1.107.0 침해

LiteLLM의 10월 21일 공식 사고 공지에 따르면 악성 PyPI 패키지 1.107.0은 UTC 11:39부터 13:23까지 게시됐습니다. Docker Hub의 v1.107.0, latest, main-latest, main-stable 태그는 UTC 11:46부터 14:20까지 영향을 받았습니다. GHCR의 같은 태그들도 UTC 11:46부터 13:51까지 영향을 받았습니다. 악성 파일은 정상 GitHub 태그 소스가 아니라 공격자가 통제한 저장소에서 만든 배포물에 포함됐다고 LiteLLM은 밝혔습니다. 따라서 소스 저장소 태그가 정상으로 보인다는 이유만으로 설치한 휠이나 이미지를 안전하다고 단정할 수 없습니다.

우선 확인할 버전은 3월 PyPI 1.82.7·1.82.8, 10월 PyPI 1.107.0입니다. 10월 공지의 영향 Docker·GHCR 태그를 사고 시간대에 실행했다면, 이미지가 이후 교체됐더라도 기존 컨테이너와 캐시된 이미지의 실행 이력을 별도로 확인해야 합니다.

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

먼저 설치 경로와 실행 시점을 대조하세요

개발자 PC뿐 아니라 빌드 러너, 배포 서버, 컨테이너, 노트북 환경, 간접 의존성도 살펴야 합니다. 직접 설치 명령에 LiteLLM이 없더라도 다른 Python 패키지가 의존성으로 가져왔을 수 있습니다. 잠금 파일만 보지 말고 설치 로그, CI 작업 기록, 이미지 digest, 실제 배포 이력을 함께 대조하세요.

PyPI 설치: 잠금 파일과 설치 로그에서 영향 버전이 내려받혔는지 확인합니다. 현재 설치 정보를 보려면 신뢰할 수 있는 일반 환경에서 pip show litellm을 사용할 수 있지만, 10월 침해가 의심되는 호스트에서는 Python이나 pip를 먼저 실행하지 마세요.
Docker·GHCR: 태그 이름뿐 아니라 실제 사용한 이미지 digest, pull 시각, 컨테이너 시작 이력을 확인합니다. 태그가 안전한 이미지로 이동한 뒤에도 이전 digest가 로컬이나 사설 레지스트리에 남아 있을 수 있습니다.
간접 의존성·CI/CD: 잠금 파일, 빌드 로그, 캐시, 테스트·배포 작업 기록에서 LiteLLM 버전과 다운로드 시간을 찾습니다. 3월 침해 여부를 확인할 때는 직접·간접 의존성을 모두 살펴보세요.
호스트 흔적: 사고별 공식 지표를 확인합니다. 3월 LiteLLM 배포물의 지표와 KISA의 Trivy 연쇄 공격 헌팅 지표는 범위가 다를 수 있습니다. KISA가 안내한 pgmon·sysmon 경로와 서비스는 광범위한 연쇄 공격 점검 지표이며 LiteLLM만의 고유 지표는 아닙니다. 10월 공지는 cook.pth, cook.py, sitecustomize.py 등의 흔적을 안내합니다.

흔적이 발견되면 노출 사실을 뒷받침하지만, 발견되지 않았다고 감염이 없었다고 확정할 수는 없습니다. 임시 파일이 지워졌거나 컨테이너가 교체됐을 수 있기 때문입니다. 반대로 취약 버전이 잠금 파일에만 있고 실제 설치·실행되지 않았다면, 실행된 경우와 같은 수준의 침해로 단정하지 말고 빌드 로그와 배포 이력으로 구분하세요.

두 사고의 영향 범위 비교

사고	확인된 배포물	공식 안내의 핵심
2026년 3월	PyPI 1.82.7·1.82.8	영향 버전 사용 여부와 자격증명 노출 가능성 점검
2026년 10월	PyPI 1.107.0, 일부 Docker·GHCR 태그	공지된 시간대와 이미지 digest 대조

LiteLLM은 3월 사고 당시 공식 Proxy Docker 배포 경로가 영향을 받은 PyPI 패키지에 의존하지 않아 영향받지 않았다고 밝혔습니다. 이 설명을 10월 사건에 그대로 적용하면 안 됩니다. 10월에는 공식 Docker·GHCR 이미지의 특정 태그도 영향 대상이었습니다. 배포 경로의 안전성은 사건별 공지와 사용한 시점·digest로 확인해야 합니다.

영향이 의심될 때 대응 순서

의심 호스트의 추가 실행을 멈추세요

10월 침해 의심 환경에서는 Python 시작 시 악성 시작 파일이 다시 실행될 수 있다고 LiteLLM이 안내합니다. 해당 환경에서 pip로 재설치하거나 진단 스크립트를 실행하는 일을 먼저 하지 말고, 네트워크 접근을 제한한 뒤 보안 담당자와 로그·이미지를 보존하세요. 3월 사건도 악성 파일 삭제만으로 이미 수집된 비밀정보가 회수되지는 않습니다.

깨끗한 환경에서 비밀정보를 교체하세요

영향 버전이 실행된 호스트가 외부 네트워크에 연결돼 있었다면, 그 호스트가 읽을 수 있었던 키와 토큰은 유출 가능성을 전제로 처리하는 편이 안전합니다. 감염 의심 환경 안에서 키를 바꾸면 새 값까지 노출될 수 있으므로 신뢰할 수 있는 별도 장치에서 교체하고, 기존 자격증명은 폐기하세요.

LiteLLM에 등록된 모델 제공자 API 키, 마스터 키, 가상 키와 데이터베이스 접속 비밀번호
환경변수와 .env에 있던 클라우드 자격증명, IAM 역할 권한, Kubernetes 토큰
SSH 키, CI/CD 토큰, 패키지 저장소·컨테이너 레지스트리 게시 자격증명
서비스 계정과 자동화 계정의 세션·토큰 및 해당 호스트가 접근할 수 있던 다른 비밀정보

키 회전은 권한 범위와 서비스 영향도를 고려해 순서를 정하세요. 사용처를 새 키로 전환한 뒤 이전 키를 폐기하고, 인증 로그에서 알 수 없는 출처의 사용이 있었는지 확인합니다.

재설치보다 깨끗한 재구축을 우선하세요

LiteLLM은 10월 사고 공지에서 당분간 명시적 버전 1.106.2 또는 사고 전 배포된 명시적 버전을 고정하도록 안내했습니다. 이는 공지 시점의 안내이므로, 실제 복구 때는 공식 사고 공지의 최신 업데이트를 먼저 확인하세요. 감염 의심 가상환경이나 컨테이너 안에서 패키지만 덮어쓰지 말고, 검증된 기반 이미지와 의존성으로 새 환경을 만들고 깨끗한 아티팩트만 배포합니다. LiteLLM도 영향 환경의 재구축이 더 나은 선택이라고 안내했습니다.

패키지 제거는 유출된 키를 무효화하지 않으며, 키 교체도 감염된 실행 환경을 정리하지 않습니다. 의심 환경 격리, 접근 권한을 가진 비밀정보 교체, 검증된 환경 재구축, 로그 조사까지 각각 완료해야 합니다.

재발 위험을 줄이는 배포 관리

버전 고정은 같은 사고가 다시 발생하지 않는다는 보장은 아니지만, 새 악성 릴리스가 자동으로 빌드에 들어오는 범위를 줄이는 기본 통제입니다. 잠금 파일과 해시를 관리하고, 릴리스 직후 새 버전을 바로 채택하기 전에 출처와 빌드 결과를 확인하세요. 컨테이너는 이동 가능한 태그만 쓰지 말고 검증한 digest를 기록해 배포 이력과 연결합니다.

의존성 잠금 파일에 직접·간접 패키지 버전을 고정하고, 변경 사항을 코드 리뷰 대상으로 둡니다.
CI/CD 게시 토큰은 필요한 작업에만 제공하고, 저장소·환경별 권한과 만료 정책을 최소화합니다.
빌드 로그, 패키지 해시, 이미지 digest, 배포 시각을 남겨 사고 공지의 범위와 대조할 수 있게 합니다.
보안 사고 발생 시 담당자, 비밀정보 교체 순서, 이미지 폐기와 재구축 절차를 미리 정합니다.

LiteLLM은 여러 모델 API를 연결하므로 한 환경에 모인 키의 권한과 저장 위치를 주기적으로 점검할 가치가 있습니다. 모델 API 키에 불필요한 클라우드 관리자 권한이나 배포 토큰을 함께 넣지 않고, 프록시가 실제로 필요한 비밀정보만 읽도록 분리하면 한 구성요소가 침해됐을 때 피해 범위를 줄이는 데 도움이 됩니다.

자주 묻는 질문

Q. LiteLLM을 쓰면 모두 해킹된 건가요?

아닙니다. 공지된 특정 버전과 배포 경로, 실행 시점이 핵심입니다. 3월은 PyPI 1.82.7·1.82.8, 10월은 PyPI 1.107.0 및 공지된 Docker·GHCR 이미지가 대상입니다. 설치·실행 기록을 확인해야 합니다.

Q. 버전을 삭제하고 다시 설치하면 충분한가요?

아닙니다. 실행 중 자격증명이 수집됐을 가능성이 있다면 삭제 후 재설치만으로 이미 노출된 키를 보호할 수 없습니다. 신뢰할 수 있는 환경에서 관련 키를 교체하고, 의심 호스트와 이미지를 조사·재구축하세요.

Q. 10월 1.107.0 확인에 pip를 실행해도 되나요?

해당 버전이 실행된 것으로 의심되는 환경에서는 먼저 실행하지 마세요. LiteLLM은 악성 시작 파일이 Python 시작 시 다시 동작할 수 있으므로, 셸에서 확인 절차를 시작하고 격리·대응하라고 안내합니다. 패키지 정보는 신뢰할 수 있는 환경에서 확인하세요.

Q. 3월 사고 때 공식 Docker만 썼다면 영향이 없나요?

LiteLLM은 3월 공지에서 공식 Proxy Docker 배포 경로가 영향받은 PyPI 패키지에 의존하지 않는다고 밝혔습니다. 다만 이 설명은 3월 사고 범위에 관한 것이며, 10월에는 특정 공식 Docker·GHCR 태그가 영향을 받았습니다. 사용한 날짜와 이미지 digest를 각 사고 공지에 대조하세요.

Q. 한국에서 침해가 의심되면 어디에 신고하나요?

KISA 보호나라의 침해사고 신고를 이용할 수 있으며, KISA는 해킹·스팸·개인정보침해 상담 전화 118도 안내합니다. 신고 전에 영향 환경과 로그를 보존하고, 조직 내 보안 담당자와 함께 범위를 정리하세요.