LiteLLM 공급망 공격: AI 스택 전반의 접근 권한 리스크

이시우
3일 전
5분 분량

이번 사례는 접근 권한과 비밀정보가 한곳에 집중될 때, 공급망 공격의 영향이 어떻게 확대될 수 있는지를 보여줍니다.

PyPI에 배포된 litellm 패키지의 1.82.7, 1.82.8 버전이 악성 코드로 변조된 사실이 확인됐습니다. LiteLLM 측은 2026년 3월 24일 보안 공지를 통해 해당 두 버전이 침해되었으며, 이후 PyPI에서 제거됐다고 밝혔습니다. 이번 사건은 개발자가 정상 패키지라고 믿고 설치한 오픈소스 구성요소가 실제로는 악성 코드가 포함된 상태로 배포된 공급망 공격 사례(Supply Chain Attack) 로 볼 수 있습니다.

LiteLLM은 여러 LLM 서비스의 API를 하나의 공통 방식으로 연결해 주는 Python 라이브러리이자 프록시로, 서로 다른 AI 서비스의 호출 방식을 중간에서 맞춰 개발자가 보다 일관된 형태로 연동하고 사용할 수 있게 해줍니다. 보안 기업 Wiz 분석 기준으로 클라우드 환경의 36% 에서 LiteLLM이 확인됐다고 설명했습니다. 또 BleepingComputer는 이 패키지가 하루 340만 회 이상, 최근 한 달 약 9,500만 회 다운로드된 만큼, 매우 널리 사용되는 구성요소라고 설명했습니다.

이번 공격의 핵심은 LLM 자체보다, 여러 AI 서비스를 한곳에서 연결해 쓰는 중간 도구에 어떤 권한과 중요한 정보가 저장되어 있었는가에 있습니다. 악성 버전은 환경 변수, SSH 키, AWS, GCP·Azure 자격증명, Kubernetes 토큰, 데이터베이스 비밀번호, CI/CD 비밀값 등을 수집해 외부로 전송하도록 설계됐습니다. LiteLLM 같은 도구는 여러 AI 서비스의 API 키와 클라우드 접근 정보를 한곳에서 함께 다루는 경우가 많습니다. 이번 공격은 바로 그 권한과 비밀정보가 집중된 지점을 타겟팅한 사례입니다. 따라서 조직이 LiteLLM을 중심으로 여러 모델 API 키와 인프라 비밀값을 함께 관리하고 있었다면, 피해 범위도 그만큼 커질 수 있습니다.

이번 사건은 AI Security 관점에서 무엇을 먼저 확인해야 하는지 다시 상기시켜 줍니다. 많은 조직이 모델 자체의 답변 품질이나 데이터 처리 문제를 먼저 떠올리지만, 실제 운영에서는 여러 AI 서비스를 한곳에서 연결하는 도구와 그 도구에 함께 부여된 권한이 공격자들에게는 Attack Vector가 될 수 있습니다.

LiteLLM은 여러 AI 호출을 한곳에서 연결해 주기 때문에 편리합니다. 하지만 그만큼 권한과 중요한 정보가 함께 모이기 쉬운 구조이기도 합니다. 이번 사례처럼 공급망이 취약한 경우 공격자는 모델 API 키 몇 개만 수집하는 수준이 아니라, 클라우드 자격증명, CI/CD 비밀값, SSH 키, Kubernetes 토큰까지 함께 수집할 수 있습니다. 결국 “LLM을 어디까지 연결할 것인가”보다 먼저 봐야 할 위험은 “그 도구가 어떤 권한까지 대신 가지고 있는가” 입니다.

이번 사례의 배경에는 Trivy 공급망 사고도 언급할 수 있습니다. Trivy는 컨테이너 이미지, 파일시스템, Git 저장소, Kubernetes 환경 등을 점검할 때 널리 쓰이는 오픈소스 보안 스캐너입니다. LiteLLM 공식 측은 CI/CD 보안 점검 과정에서 사용되던 Trivy 관련 요소를 통해 배포 권한 접근이 이어졌을 가능성을 언급했고, Snyk도 이번 LiteLLM 사건을 앞서 발생한 Trivy 관련 공급망 침해의 여파가 LiteLLM의 PyPI 게시 권한까지 이어진 사례로 정리했습니다. Aqua Security 역시 Trivy 사고에 대해 공식 입장을 내고 악성 릴리스 및 태그 제거, 비밀값과 토큰 회전, 조사와 복구 작업 진행을 공개했습니다.

LiteLLM 사고의 핵심 포인트:

이번 사례가 중요한 이유는 세 가지입니다.

첫째, 공격 대상이 AI 애플리케이션 자체가 아니라 AI 운영 체인이었다는 점입니다.
둘째, 악성 버전 1.82.8은 LiteLLM을 직접 실행하지 않아도, 해당 악성 버전이 설치된 Python 환경이 시작될 때 코드가 동작할 수 있도록 구성됐습니다.
셋째, 피해 범위는 LiteLLM 자체보다 LiteLLM과 함께 보관, 관리되던 API 키, 토큰, 자격증명, 권한이 얼마나 많았는지에 따라 달라졌습니다.

이번 사건은 단순한 Python 패키지 변조 사례를 넘어, 권한을 한곳에 몰아두면 공급망 침해의 파급 범위가 얼마나 커질 수 있는지 보여주는 사례이기도 합니다.

영향 범위

현재 공개 자료 기준으로 보면, 영향 범위는 아래와 같습니다.

항목	내용
영향 패키지	litellm (PyPI)
확인된 악성 버전	1.82.7, 1.82.8
안전 기준	공개 분석 기준 1.82.6 이하 버전이 마지막 정상 버전으로 언급

LiteLLM 공식 공지에 따르면 2026년 3월 24일 10:39 UTC부터 16:00 UTC 사이 LiteLLM을 설치하거나 업그레이드하면서 설치할 버전을 따로 지정하지 않았다면, 악성 버전인 1.82.7 또는 1.82.8이 설치됐을 것이라 언급합니다. 또 직접 LiteLLM을 설치하지 않았더라도 영향 범위에서 제외되는 것은 아닙니다. 다른 AI 프레임워크나 도구가 설치 과정에서 litellm 패키지 의존성이 있었다면, 같은 악성 버전도 함께 설치될 수 있습니다.

직접 설치하지 않았더라도 영향이 생길 수 있는 이유는 아래와 같습니다.

사용자가 어떤 AI 도구를 설치합니다.
해당 도구가 동작하려면 litellm 패키지가 필요합니다.
설치 과정에서 litellm을 PyPI에서 함께 받아옵니다.
그 시점에 PyPI에 올라와 있던 litellm 최신 버전이 악성 1.82.7 또는 1.82.8이었다면,
결과적으로 해당 AI 도구를 설치하는 과정에서 악성 LiteLLM도 함께 설치됩니다.

핵심은 다른 도구 자체가 악성이었다는 뜻이 아니라, 그 도구가 설치 과정에서 함께 받아온 PyPI의 litellm 버전이 악성이었다는 점입니다.

IOC

이번 사례와 관련된 주요 IOC는 아래와 같습니다.

File IOC

litellm-1.82.7.whl
- SHA-1: 78cd382040eda14e2f8a17ee7387cffdabe96ab5
- SHA-256: 8395c3268d5c5dbae1c7c6d4bb3c318c752ba4608cfcd90eb97ffb94a910eac2
litellm-1.82.8.whl
- SHA-1: 3fcc7360a2738ad2656e17c7d4ed3e651ff7d73a
- SHA-256: d2a0d5f564628773b6af7b9c11f6b86531a875bd2d186d7081ab62748a800ebb
proxy_server.py
- SHA-1: 9e7587b990ae57319a6afedeba3b8873f6238206
- SHA-256: a0d229be8efcb2f9135e2ad55ba275b76ddcfeb55fa4370e0a522a5bdee0120b
litellm_init.pth
- SHA-1: 2d94efc6d49e05b314a9da55804f6a0d57154b18
- SHA-256: 71e35aef03099cd1f2d6446734273025a163597de93912df321ef118bf135238

Domain IOC

models[.]litellm[.]cloud
checkmarx[.]zone
checkmarx[.]zone/raw

권고 사항

이번 사례는 패키지 제거와 함께 아래 항목도 점검해야 합니다.

1. 점검

2026-03-24에 pip install litellm 또는 업그레이드를 수행했는지 확인
설치 시 버전을 따로 지정하지 않았는지 확인
해당 시간대에 빌드된 Docker 이미지 사용 여부 확인
다른 AI 도구가 설치 과정에서 litellm을 PyPI에서 함께 받아오는 구조였는지 확인
Python 패키지 설치 경로에 litellm_init.pth 파일이 존재하는지 확인
Python 프로세스에서 비정상적인 외부 통신이 있었는지 확인

2. 차단

상기에 기재한 File IOC는 사용 중인 보안 솔루션의 Blocklist에 등록
상기에 기재한 Domain IOC는 사용 중인 방화벽, 프록시, DNS 보안 장비 등에서 차단

3. 후속 조치

해당 시스템에 저장돼 있던 API 키, 토큰, 클라우드 자격증명, 비밀번호 변경 또는 재발급
해당 시스템을 통해 접근 가능한 클라우드, IAM, Kubernetes, DB, CI 권한 범위 재점검
LiteLLM, 프록시, AI 도구 운영 환경에 함께 부여된 권한 최소화

LiteLLM 사고에 대한 PAGO MDR Center 관점

PAGO MDR Center는 항상 그렇듯이 이번 LiteLLM 공급망 사례를 단순 IOC 차단 대응으로만 운영하지 않습니다. 위협 리서치(Threat Research) → 위협 헌팅(Threat Hunting) → 탐지 엔지니어링(Detection Engineering) → 탐지 운영(Detection Operations) 흐름으로 연결되며, 이 라이프 사이클은 종료되지 않고 지속적으로 관리됩니다.

PAGO MDR Center continuous lifecycle — *PAGO MDR Center 지속 운영 사이클*

공개된 악성 파일 4종은 PAGO에서 공급하고 있는 보안 솔루션에 악성 리스트로 분류하였습니다.

litellm-1.82.7.whl
litellm-1.82.8.whl
proxy_server.py
litellm_init.pth

여기에 그치지 않고, PAGO MDR Center의 Continuous Threat Hunting & Detection Engineering 방법론을 통해 이번 사례와 유사한 위협 유형의 헌팅 및 탐지 메커니즘을 지속적으로 개발하고 있습니다.

Threat Hunting은 공격 과정에서 나타나는 행위(behavior)를 기준으로 수행됩니다. 이번 사례와 같은 공급망 공격에서는 Python 패키지 설치 흐름, 비정상적인 .pth 파일 생성, 민감한 인증 정보 접근, 외부 도메인 통신, 악성 패키지 설치 이후의 후속 행위를 함께 조사하는 게 중요합니다. LiteLLM 공식 분석과 외부 분석에서도 1.82.8은 .pth 파일을 이용해 Python 시작 시 코드 실행이 가능했고, 자격증명 수집 후 외부 도메인으로 전송하는 구조가 확인됐습니다.

탐지의 핵심은 “악성 파일이 있는가”만 보는 것이 아니라, 패키지 설치 → 파일 생성 → 인증 정보 접근 → 외부 통신으로 이어지는 행위를 연결해 보는 것입니다. 이런 방식은 알려진 해시를 바꾸거나 파일명을 바꾼 변형에도 대응할 수 있다는 장점이 있습니다. 이번 사례처럼 공급망을 통해 유입된 위협은 단일 IoC만으로 놓칠 수 있기 때문에, 위협 조사 결과를 실제 운영 환경에서 재현 가능한 탐지 로직으로 전환하는 과정이 중요합니다.

다시 말해, 위협 연구가 위협 헌팅으로 이어지고, 위협 헌팅이 탐지 엔지니어링으로 연결되며, 그 결과가 실제 탐지 운영으로 정착되는 구조가 중요합니다. 이번 LiteLLM 사례는 그 연결이 왜 필요한지를 보여줍니다.

LiteLLM 사건은 “AI가 위험하다”는 형태의 안내글이 아닙니다. 더 정확히 말하면, AI 서비스를 연결하고 운영하는 과정에서 어떤 권한과 비밀정보가 한곳에 집중돼 있었는지가 위험을 키운 사건입니다.

LLM 시대에는 모델 자체보다 모델을 연결하는 도구, 프록시, 그리고 그 주변에 함께 저장되거나 사용되는 비밀정보와 권한이 더 큰 공격 지점이 될 수 있습니다. 이번 공급망 공격은 그 현실을 직접적으로 보여줬습니다. 조직은 이제 LLM 보안을 프롬프트나 출력 통제 수준에서만 볼 것이 아니라, 권한이 한곳에 집중된 구조, 비밀정보 분리, 간접 설치 구조 관리, 배포 과정의 신뢰성까지 함께 점검해야 합니다.

About PAGO Networks

The Global MDR Frontline | Owning the Decisions That Matter Most

PAGO Networks는 단순히 위협을 분석하거나 대응을 권고하는 MDR이 아닙니다.보안 사고가 발생하지 않도록 사전에 판단하고 개입하며,필요한 순간에는 가장 중요한 의사결정과 그 결과까지 책임지는 MDR 서비스를 제공해 왔습니다.

검증된 AI 기술과 보안 플랫폼을 기반으로,실제 운영 현장에서 축적된 사람의 판단과 경험을 결합해고객의 비즈니스에 가장 적합한 선택을 수행해 왔으며,그 선택에 대한 책임을 가장 앞선 자리에서 일관되게 이어가고 있습니다.

이것이 PAGO Networks가 실천해 온 Global MDR Frontline의 방식이며,앞으로도 고객이 결정을 맡길 수 있는 보안 파트너로서 지켜갈 기준입니다.

References

작성자: 이시우 Threat Analyst | DeepACT MDR Center

이상 징후를 감지하셨나요?