같은 코드베이스인데 한쪽만 샌드박스를 깜빡했다 — LiteLLM Jinja2 SSTI
같은 코드베이스인데 한쪽만 샌드박스를 깜빡했다 — LiteLLM Jinja2 SSTI
분류: Security · 웹·AI 인프라 · SSTI(템플릿 인젝션) [정보성]
덱. Pwn2Own 출전을 준비하던 연구자 blackcon이 여러 LLM 제공사를 하나의 API로 묶어주는 오픈소스 게이트웨이 LiteLLM에서 템플릿 인젝션(SSTI) 취약점을 발견했습니다. 단일 HTTP 요청만으로 서버에서 루트 권한 코드 실행까지 이어지는 결함이었지만, 대회 직전 메인테이너가 별도 공지 없이 조용히 고쳐버리면서 대회 출전은 무산됐습니다.
리드
AI 인프라라고 하면 프롬프트 인젝션이나 모델 탈옥 같은 새로운 위협을 먼저 떠올리기 쉽습니다. 그런데 실제로는 이런 새 인프라 안에도 SQL 인젝션·SSRF·안전하지 않은 역직렬화 같은 오래된 웹 취약점 클래스가 그대로 살아 있는 경우가 많습니다. 이번 사례는 그 전형입니다 — 새로운 것은 LLM 게이트웨이라는 무대뿐, 취약점 자체는 고전적인 템플릿 인젝션입니다.
핵심 사실 요약
- LiteLLM은 OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex AI 등 여러 LLM 제공사를 하나의 OpenAI 호환 API로 묶어주는 오픈소스 프록시 게이트웨이입니다. Pwn2Own Berlin 2026의 Local Inference 카테고리에 공식 타깃으로 등재돼 있었던 것으로 원문은 밝힙니다.
- LiteLLM은 Dotprompt 형식의 프롬프트 템플릿을 지원하는데, 이를 처리하는 컴포넌트가 Jinja2 템플릿 엔진 환경을 만들 때 샌드박스가 적용되지 않은 일반
Environment를 사용하고 있었습니다. 같은 코드베이스의 다른 위치에서는 샌드박스가 적용된 환경(ImmutableSandboxedEnvironment)을 쓰고 있었는데, 이 특정 컴포넌트만 그렇지 않았던 것으로 원문은 설명합니다. - 이 샌드박스 없는 환경으로 흘러가는 진입점은
/prompts/test라는 API 엔드포인트였습니다. 클라이언트가 HTTP 요청 본문으로 보내는 임의 문자열이 별도의 검증(화이트리스트·길이 제한·패턴 검사) 없이 그대로 이 템플릿 환경에서 렌더링됐습니다. - Jinja2에서 샌드박스가 적용되지 않은 환경은
__globals__,__class__,__mro__같은 파이썬 내부 속성에 자유롭게 접근할 수 있게 해줍니다. 사용자가 넣은 템플릿 문자열이 이런 환경에서 렌더링되면, 이 속성 접근 경로를 통해 임의 코드 실행으로 이어질 수 있습니다 — SSTI(서버 사이드 템플릿 인젝션)의 전형적인 형태입니다. - 인증 요구 조건도 약했던 것으로 설명됩니다. 마스터 키를 설정하지 않은 기본 상태에서는 인증이 사실상 없었고, 마스터 키를 설정한 경우에도 관리자가 아닌 일반 내부 사용자(internal_user) 역할의 API 키만 있으면 이 엔드포인트를 통과할 수 있었습니다.
- 연구자는 여러 버전에서 이 결함을 실제로 검증했다고 밝혔고, 2026년 4월 9일 메인테이너가 별도 보안 공지 없이 두 줄짜리 수정(샌드박스 미적용
Environment를ImmutableSandboxedEnvironment로 교체)을 병합했습니다. 이 수정은 다른 사소한 개선과 함께 하나의 풀 리퀘스트로 묶여 반영됐고, CVE는 발급되지 않은 것으로 보입니다. 이런 형태를 원문은 “silent fix”(조용한 수정)라고 부릅니다. - ⚠️미확인(팩트체크 대상) — 정확한 영향 버전 범위, 취약점 재현에 사용된 구체적인 페이로드·환경, 패치 커밋의 정확한 diff 내용은 이 초안에서 1차출처(GitHub 리포지토리)로 직접 재대조하지 않았습니다.
대응방안
- 근본. 원문이 안내하는 패치 버전 이상으로 LiteLLM을 업데이트합니다. 공식 컨테이너 이미지를 쓰고 있다면
latest계열 태그를 단순히 따라가기보다, 패치가 반영된 것으로 확인된 태그로 명시적으로 고정하는 것이 안전합니다. - 차선.
/prompts/test처럼 사용자 입력을 템플릿 엔진으로 넘기는 엔드포인트가 외부에 노출돼 있다면, 패치 적용 여부와 별개로 별도 접근 제어(ACL)로 제한하는 것을 권장합니다. - 탐지 관점. 프록시·서버 로그에서 요청 본문에
__globals__,__class__,__import__같은 SSTI 특유의 키워드가 섞인 요청이 과거에 있었는지 소급 점검하는 것도 도움이 됩니다.
짧은 논평
이 사례에서 눈에 띄는 지점은 두 가지입니다. 하나는 같은 코드베이스 안에서도 어떤 곳은 샌드박스를 쓰고 어떤 곳은 쓰지 않는, 일관성 없는 방어 적용이 실제 취약점으로 이어졌다는 것입니다. “다른 곳에서는 잘 처리했으니 여기도 괜찮겠지”라는 가정이 얼마나 위험한지 보여주는 사례입니다. 다른 하나는, 빠르게 성장하는 AI 인프라 계층에서도 결국 가장 빠른 침해 경로는 프롬프트 인젝션 같은 LLM 고유 위협이 아니라 SSTI·SQL 인젝션 같은 고전적인 웹 취약점 패턴이라는 점입니다. 새로운 인프라를 평가할 때도 기본적인 웹 보안 점검 항목부터 짚어야 한다는 교훈을 남깁니다.
References / 참고자료
- blackcon, “LiteLLM에서 발견한 Jinja2 SSTI 취약점 — Pwn2Own 2026 출전 시도와 silent fix 분석” — 이 글이 재구성한 원 분석. 취약점 발견 경위·구조·패치 분석 전체를 다룸. https://blackcon.github.io/posts/litellm-jinja2-ssti/
이 글은 위 원 분석을 우리 관점에서 다시 쓰고 짧은 논평을 더한 정보성 초안입니다. 특정 문장·소스코드 조각을 그대로 옮기지 않았으며, 작동하는 페이로드는 싣지 않았습니다. ⚠️미확인 표시 항목은 발행 전 독립 팩트체크에서 1차출처로 확증·정정되어야 합니다.