Hacker News가 경고한 LiteLLM 악성 PyPI 릴리스, Python 시작만으로 실행

Hacker News는 LiteLLM 공급망 사고를 긴급 이슈로 끌어올렸다. 이용자들은 BerriAI GitHub 조사 이슈를 공유했고, 쟁점은 PyPI의 1.82.7과 1.82.8이 단순한 버그가 아니라 악성 릴리스였다는 점이었다. 2026년 3월 24일 maintainer update에 따르면, 특히 한 릴리스 경로는 Python interpreter가 시작되기만 해도 코드가 실행될 수 있었다.

기술 분석 이슈 #24512에 따르면 1.82.8 wheel에는 litellm_init.pth 파일이 들어 있었다. Python은 시작 시 .pth 파일을 자동 처리하므로, 운영자가 LiteLLM을 import하지 않아도 payload가 동작할 수 있었다. 같은 분석은 이 패키지가 environment variables, SSH 자료, cloud credentials를 수집한 뒤 attacker-controlled domain으로 전송했다고 설명한다. 이후 maintainer status thread는 1.82.7도 악성이었다고 밝혔지만, 그쪽은 trigger 범위가 더 좁아 litellm.proxy import 시점에 발화했다고 정리했다.

• maintainers는 문제 버전을 PyPI에서 제거했다고 밝혔다.
• status update는 release chain compromise를 조사 중이며 maintainer account rotation을 마쳤다고 적었다.
• BerriAI는 dependency가 pinned된 requirements.txt를 쓰는 proxy Docker image 사용자는 영향이 없었다고 설명했다.

HN discussion이 눈에 띈 이유는 이 사건을 평범한 dependency update가 아니라 incident response 문제로 재정의했기 때문이다. 공식 권고도 분명하다. 악성 .pth 파일 존재 여부를 확인하고, 해당 패키지가 설치된 시스템에서 노출됐을 수 있는 모든 credential을 rotation하며, 무단 접근 징후를 감사해야 한다. maintainer update에는 Google의 Mandiant 팀이 조사에 참여했다는 내용도 포함돼 있다.

agent stack이나 proxy layer를 운영하는 엔지니어에게 더 큰 교훈은 packaging trust다. LiteLLM은 model credential, vendor API key, infrastructure config 가까이에 위치하므로 설치 단계 compromise는 곧바로 특권 foothold가 된다. HN의 반응은 공포보다는, 현대 LLM tooling이 기본적으로 얼마나 많은 민감 정보를 볼 수 있는지를 다시 확인하는 쪽에 가까웠다.

1차 출처: 기술 분석 이슈, maintainer status timeline. 커뮤니티 출처: Hacker News 스레드.