환경 변수 사고는 워크스페이스·조직, 악성 패키지는 실행 호스트가 대응 기준

서비스 내부 환경 변수 사고: 가능성과 확인을 따로 공개

Railway는 환경 변수를 저장하는 내부 시스템에 대한 이상 접근을 조사한 뒤, 무단 제3자가 암호화된 환경 변수에 접근했을 수 있고 일부 값의 복호화 내용도 얻었을 가능성이 있다고 공지했습니다. 후속 예비 보고서는 전체 워크스페이스의 최대 1.85%, 약 10만 곳에서 일부 환경 변수가 잠재적으로 침해됐을 수 있다고 산정했습니다. Railway는 어떤 변수가 복호화됐는지 특정할 수 없었다고 밝혔습니다. 따라서 1.85%는 복호화가 확인된 워크스페이스 비율이 아니라 잠재적 노출의 상한입니다.

Railway는 모든 사용자에게 플랫폼에 저장한 환경 변수와 API 키, 사설 레지스트리 자격 증명을 교체하고 관련 서비스 로그를 살펴보라고 권고했습니다. 외부 제공업체에도 플랫폼에 보관한 키를 폭넓게 전달해 폐기를 요청했으며, 공급업체의 키 폐기 통지가 곧 해당 자격 증명이 사고에 노출됐다는 뜻은 아니라고 설명했습니다. 조사 중 새 빌드와 배포는 중단했지만, 기존 고객 서비스는 계속 실행됐습니다.

Trigger.dev는 일부 고객 조직에서 공격자가 환경 변수에 실제로 무단 접근했다고 공지하고 익스플로잇을 차단했으며, 영향받은 계정 소유자에게 완화 절차를 이메일로 보냈습니다. 상태 페이지는 11월 2일 오전 7시 50분(KST) 사고를 해결 상태로 표시했고, 후속 세부 설명을 예고했습니다. 공개 공지에는 영향 조직 수와 노출된 변수 종류, 이메일에 담긴 구체적인 절차가 나오지 않습니다. Railway가 잠재적 노출의 최대치를 워크스페이스 비율로 제시한 것과 달리 Trigger.dev는 접근이 확인된 범위를 ‘일부 조직’으로만 밝혀, 두 표현만으로 피해 규모를 직접 비교할 수 없습니다.

LiteLLM은 배포물을 통해 실행 호스트로 위험을 넓혔다

SafeDep의 Kunal Singh가 작성한 분석에 따르면, PyPI의 LiteLLM 1.107.0은 `cook.pth`, `cook.py`, `sitecustomize.py`를 설치합니다. `cook.pth`가 `cook.py`를 불러오고 `sitecustomize.py`가 백그라운드 데몬을 시작해, LiteLLM을 직접 불러오지 않는 Python 프로세스에서도 코드가 작동합니다. 탈취 코드는 환경 변수뿐 아니라 SSH 키, 클라우드·CI 자격 증명, 브라우저 비밀번호와 LiteLLM 프록시의 제공업체 키 등을 수집해 암호화한 뒤 전송합니다. 데몬은 매시간 공격자 측 주소를 읽고 원격 코드를 내려받아 실행하도록 구성됐습니다.

SafeDep은 2026년 10월 21일 PyPI의 `litellm==1.107.0` 전체 7개 휠이 11:39~13:23 UTC에, Docker Hub와 GHCR의 `v1.107.0`, `latest`, `main-latest`, `main-stable` 이미지가 11:46~14:20 UTC에 악성 코드를 포함했다고 정리했습니다. SafeDep 분석은 1.106.2와 1.107.0rc1·rc2를 깨끗한 버전으로 기록했고, LiteLLM은 비공개 엔터프라이즈 릴리스가 영향을 받지 않았다고 밝혔습니다. LiteLLM의 사고 보고서는 해당 버전을 설치하거나 영향 이미지로 컨테이너를 실행한 환경을 침해된 것으로 취급하라고 안내했습니다. 여기서 공개된 시간과 버전은 배포물의 범위를, 설치·실행 조건은 개별 호스트의 위험 범위를 설명합니다.

사업자 조치는 각자 확인한 노출 지점을 따라갔다

LiteLLM은 악성 패키지를 PyPI에서 제거하고 관리자 자격 증명을 축소했으며, 10월 23일 이미지 서명 키를 교체했다고 보고했습니다. 이미 영향 버전을 실행한 환경에는 악성 파일과 백그라운드 데몬을 정리하고 가상환경이나 이미지를 새로 만들며, 해당 호스트가 접근할 수 있던 자격 증명을 교체하라고 안내했습니다. 외부 통신이 가능한 호스트에 1.107.0을 설치했다면 데이터 반출이 이뤄졌다고 가정하라는 지침도 포함했습니다. 배포물 제거는 새 설치를 막는 조치이고, 이미 실행된 호스트의 정리와 자격 증명 교체는 별도의 대응입니다.

세 사례의 공개 범위는 워크스페이스의 잠재적 영향 상한, 접근이 확인된 일부 조직, 악성 패키지의 버전·배포 시간과 실행 호스트 조건으로 각각 다릅니다. 이에 따라 Railway는 변수를 특정하지 못한 상황에서 폭넓은 교체와 외부 키 폐기를 권고했고, Trigger.dev는 영향받은 계정 소유자에게 완화 절차를 보냈으며, LiteLLM은 악성 배포물 제거에 더해 실행된 호스트의 재구축과 자격 증명 교체를 안내했습니다. 이들 표현은 집계 단위와 확인 수준이 달라 공통된 피해자 수나 사고 규모 순위를 나타내지 않습니다.