영향 대상은 Enterprise 라이선스가 활성화된 LiteLLM 프록시다. 라이선스 없는 오픈소스 배포는 관련 코드 경로가 로드되지 않아 이번 취약점의 영향을 받지 않는다. 우선 라이선스 활성 여부와 실행 버전을 확인하고, 영향 대상이면 사용하는 버전 라인의 패치를 적용해야 한다.[1]
우리 서비스는 LiteLLM을 사용하지 않는다. 다만 AI 게이트웨이를 운영하는 입장에서 공식 공지를 직접 확인하고 점검 기준을 정리했다.
인증 없는 요청으로 로컬 파일을 읽어 외부로 전송할 수 있다. 이 과정에서 LITELLM_MASTER_KEY와 AI 프로바이더 API 키가 노출되면 프록시 관리자 권한 획득으로 이어질 수 있다. 호스트 코드 실행은 일부 설정에서만 가능한 후속 영향이다. 모든 배포에서 코드 실행이 된다는 뜻은 아니다.[1]
이 글은 공식 공지와 GitHub API 직접 조회 결과를 바탕으로 한 운영 점검안이다. 실제 운영·설치·재현 결과를 전제로 하지 않는다. 확인한 두 공식 자료에는 실제 악용 여부가 기재되지 않았다. 이를 근거로 악용 사례가 없다고 단정해서도 안 된다.
사용 중인 프록시도 긴급 조치 대상인가?
Enterprise 라이선스가 활성화돼 있고 해당 라인의 패치 버전보다 낮다면 조치 대상이다. 제품을 오픈소스로 설치했다는 기억보다 현재 실행 인스턴스의 라이선스 상태가 판단 기준이다. 여러 환경을 운영한다면 운영계만 보지 말고 같은 프록시를 쓰는 개발·검증 환경도 목록에 넣는 편이 좋다. 이는 일반 운영 점검 제안이다.
식별자는 GHSA-w4c7-34wj-hqm8이며, CVSS 3.1 점수는 10.0(Critical)이다. 2026년 10월 29일 직접 조회한 GitHub API의 cve_id는 null이므로, 확인 시점에는 이 공지에 CVE 번호가 표시되지 않았다. GHSA 식별자로 변경 작업과 내부 보안 티켓을 연결하면 된다.[1]
공식 API의 공개 시각은 2026-10-27T20:33:15Z, 한국시간으로는 2026년 10월 28일 05:33이다. 공식 블로그의 ‘10월 27일 엠바고 해제’는 원문 날짜다. 한국시간 공개일과는 시차가 있으므로 서로 다른 사건 날짜로 해석하지 않아야 한다.[1][2]
LiteLLM 사용 여부만으로는 조치 대상을 가릴 수 없다. 각 인스턴스에 대해 라이선스 활성 여부, 현재 버전, 외부 접근 경로, 운영 담당자가 기록돼 있어야 영향 범위를 판단할 수 있다. 확인되지 않은 인스턴스는 비영향으로 처리하지 말고 미확인 상태로 남긴다.
어느 버전으로 올려야 하나?
사용 중인 버전 라인에 대응하는 패치 버전 이상으로 올려야 한다. 공지된 기준은 다음과 같으며, 취약 범위는 각 행의 같은 라인 안에서 읽어야 한다. 표에 없는 더 오래된 버전을 비영향으로 판단해서는 안 된다. 해당 버전의 Enterprise 배포는 벤더에 지원되는 패치·업그레이드 경로를 확인하는 것이 좋다. 이는 일반 운영 권고다.[1][2]
| 버전 라인 | 같은 라인의 취약 범위 | 패치 버전 |
|---|---|---|
| 1.103.x | 1.103.10 미만 | 1.103.10 |
| 1.104.x | 1.104.8 미만 | 1.104.8 |
| 1.105.x | 1.105.6 미만 | 1.105.6 |
| 1.106.x | 1.106.5 미만 | 1.106.5 |
1.103.10을 모든 후속 라인에 공통으로 적용되는 안전 기준으로 삼으면 안 된다. 예를 들어 1.104.x는 그 라인의 기준인 1.104.8과 비교해야 한다. 공식 블로그는 아직 업데이트하지 않은 Enterprise 고객에게 즉시 업데이트하라고 요청한다.[2]
실무적으로는 패키지 설치, 컨테이너 등 실제 배포 방식에 맞게 패치를 반영하고 실행 인스턴스까지 확인하는 절차가 필요하다. 배포 설정이나 저장소의 버전만 바꿨다는 기록은 완료 증거로 부족하다. 재시작·교체 뒤 실제 구동 버전을 확인하고, 여러 복제본이 있다면 이전 버전이 남지 않았는지 확인한다. 이 배포 검증 방식은 일반 운영 권고다.
완료 기준은 ‘업데이트 명령 성공’이 아니라 ‘영향 대상 전체의 실행 버전 확인’이다. 배포 담당자는 대상 목록과 적용 결과를 남기고, 서비스 담당자는 정상 요청이 처리되는지 점검하는 식으로 책임을 나누면 누락을 줄일 수 있다.
공식 완화책: 바로 패치할 수 없다면 무엇을 막아야 하나?
공식 공지는 경계에서 위험 요청을 차단하거나 제거하고, 프록시의 외부 통신을 설정된 LLM 프로바이더 엔드포인트로 제한하도록 제시한다.[1]
WAF·ingress·리버스 프록시에서는 공식 공지의 완화 항목에 제시된 위험 JSON 키를 포함하는 POST 요청 본문을 거부하거나 해당 키를 제거하는 방식을 검토할 수 있다. 키 목록은 이 글에 옮기지 않는다. 적용 담당자는 하단 GitHub 공지의 Mitigations 항목을 기준으로 규칙을 검토해야 한다.[1]
외부 통신은 설정한 LLM 프로바이더 엔드포인트로 제한한다. 공식 설명에 따르면 파일 내용의 외부 유출에는 공격자가 지정한 목적지로의 전송이 필요하므로, egress 허용목록은 그 유출 경로를 막는 완화책이다. 다만 이를 취약 코드 자체가 제거됐다는 뜻으로 받아들이면 안 된다.[1]
공식 공지는 가능하면 VPN, mTLS, 인증 ingress, IP 허용목록을 이용해 공개 인터넷 노출을 줄일 것도 일반적으로 권장한다. 심층 방어로는 마스터키를 프로세스 환경변수 대신 시크릿 매니저에서 로드하고, 별도의 LITELLM_SALT_KEY를 설정하며, 알려진 프로바이더 엔드포인트로 외부 통신을 제한하도록 권고한다.[1]
이 조치들은 패치를 대체하지 않는다. 임시 규칙에는 적용 담당자와 패치 예정 시점을 함께 남겨야 한다. 정상 요청이 차단되거나 필요한 프로바이더 연결이 끊기지 않는지 확인하는 것은 별도의 일반 운영 권고다. 완화책 적용 여부와 정상 트래픽 검증 결과를 구분해서 기록한다.
일반 보안 운영 권고: 키와 로그는 어떻게 점검하나?
노출 가능성이 있었던 환경은 키 교체 필요성과 이상 행위를 함께 검토하되, 점검 시작을 키 유출 확정으로 표현하지 않아야 한다. 아래 항목은 공식 문서가 직접 명령한 사고 대응 절차가 아니라, 이번 영향에 대비한 일반 보안 운영 권고다.
마스터키와 프로바이더 API 키는 노출 가능 범위, 접근 경로, 관찰된 정황을 바탕으로 교체를 검토한다. 교체 전에는 기존 암호화 데이터와 의존 서비스에 미치는 영향을 확인하고 승인된 절차를 따라야 한다. 환경변수만 바꾸면 교체가 끝난다고 보면 안 된다. 새 키를 사용하는 서비스의 정상 동작과 이전 키의 처리 결과까지 확인해야 한다.
가상키 발급 내역, 권한과 설정 변경, 비용 변화, 평소와 다른 외부 통신, 관련 로그도 점검 대상이다. 어느 하나의 이상만으로 이번 취약점 악용을 확정하지 말고 시간대와 변경 이력을 함께 살핀다. 반대로 로그에서 흔적을 찾지 못했다는 사실만으로 노출이 없었다고 결론 내리지 않는다.
운영 기록에는 다음처럼 확인 사항, 조치, 담당자, 완료 기준을 함께 적어 두면 좋다. 담당 칸에는 팀 이름만 적기보다 실제 책임자나 당직 역할을 지정하는 편이 좋다.
① 영향 범위 — 확인: 라이선스·버전·접근 경로. 조치: 대상 목록 확정. 담당: 프록시 운영자. 완료 기준: 모든 인스턴스가 영향·비영향·미확인으로 분류되고 미확인 항목의 후속 담당이 지정됨.
② 패치 — 확인: 사용 라인의 패치 기준과 배포 방식. 조치: 업데이트 후 실행 상태 검증. 담당: 배포 책임자. 완료 기준: 영향 대상 전체가 기준 버전 이상으로 동작하고 정상 요청 점검 결과가 남음.
③ 임시 완화 — 확인: 경계 필터와 egress 정책. 조치: 공식 완화책 적용 및 정상 트래픽 점검. 담당: 네트워크·보안 담당자. 완료 기준: 적용 범위·예외·검증 결과·패치 예정 시점이 기록됨.
④ 키 관리 — 확인: 노출 가능 키와 의존 서비스·암호화 데이터 영향. 조치: 승인된 교체 계획 수립 및 실행. 담당: 시크릿·서비스 책임자. 완료 기준: 새 키 전환, 이전 키 처리, 의존 서비스 정상 동작이 확인됨.
⑤ 이상 징후 — 확인: 가상키·권한·설정·비용·외부 통신·로그. 조치: 관련 기록 보존과 추가 조사 판단. 담당: 보안 대응 담당자. 완료 기준: 검토 기간·확보 자료·관찰 결과·미확인 사항·후속 조치가 기록됨.
공개 전 패치가 있었는데 왜 다시 확인해야 하나?
선배포가 있었다는 사실은 우리 환경의 패치 완료를 보장하지 않기 때문이다. 벤더는 2026년 10월 6일 수정을 완료하고 임시 프라이빗 레지스트리에 패치 릴리스를 배포하기 시작했다고 설명한다. 원문 기준 10월 27일 엠바고를 해제했고, 패치 버전을 PyPI·GHCR·Docker Hub에 공개했다.[2]
공개 패치 diff가 취약점의 단서가 될 수 있다는 것은 이 배포 방식을 택한 벤더의 설명이다. 이 설명만으로 실제 악용 여부를 판단할 수는 없다. 또한 고객에게 패치 존재와 수령 방법을 알리고 실제 적용을 확인하는 데 어려움이 있어, 엠바고가 계획보다 약 1주 길어졌다고 밝혔다. 전체 고객이 패치를 마쳤다는 뜻은 아니다.[2]
엠바고 기간에 통지를 받지 못한 Enterprise 고객은 security@berri.ai로 연락하라는 안내가 있다. 운영 측면에서는 이번 적용 결과와 함께 보안 통지 수신 담당, 배포 담당, 최종 확인 담당이 연결돼 있는지도 점검할 만하다.[2]
정리: 패치 적용과 점검 기록까지 확인하자
이번 대응은 Enterprise 활성 여부를 가르고, 사용 라인의 패치를 적용한 뒤, 실제 실행 인스턴스로 확인하는 데서 시작한다. 당장 업데이트가 어렵다면 공식 완화책을 적용하되 패치 일정을 남긴다. 키와 로그 점검은 일반 보안 운영 권고로 분리하고, 확인된 사실과 아직 모르는 부분을 구분한다.
작업을 닫을 때 남아 있어야 할 것은 영향 대상 목록, 실행 버전 증거, 완화책 적용 범위, 키 교체 판단과 결과, 이상 징후 검토 기록이다. 그중 미완료 항목이 있다면 담당자와 다음 확인 시점을 남긴다. ‘조치함’ 한 줄보다 이 기록이 다음 운영자의 판단에 도움이 된다.
참고자료
[1] LiteLLM GitHub 보안 공지 — GHSA-w4c7-34wj-hqm8 https://github.com/BerriAI/litellm/security/advisories/GHSA-w4c7-34wj-hqm8
[2] LiteLLM 공식 블로그 — Introducing the LiteLLM Private Registry https://docs.litellm.ai/blog/litellm-private-registry