또 LLM 게이트웨이가 털렸다? CVE-2026-42271 LiteLLM 명령어 주입 취약점, 방어자 시점으로 뜯어보기

이미지 출처: CISA KEV

요즘 사내에 LLM 하나쯤 붙여 쓰는 건 너무 당연한 일이 됐는데 말입니다, 그 LLM 트래픽을 한곳에 모아주는 "게이트웨이"가 뚫리면 어떻게 될까요? 이번에 또 하나 터졌습니다. BerriAI의 LiteLLM에서 발견된 CVE-2026-42271 명령어 주입(Command Injection) 취약점인데, 단순히 "AI가 이상한 말 한다" 수준이 아니라 서버에서 임의 명령이 돌아갈 수 있는 결입니다. 과연 우리 환경은 안전할까요?

핵심 요약

• LiteLLM(LLM 프록시/게이트웨이)에서 외부 입력이 시스템 명령으로 흘러드는 명령어 주입 취약점(CVE-2026-42271)이 보고됨.
• 성공 시 게이트웨이 호스트에서 임의 명령 실행 → API 키·내부망 자격증명 유출, 측면 이동으로 번질 수 있음.
• 대응 핵심은 "최신 버전 패치 + 입력 검증 + 게이트웨이 격리·최소권한 + 명령 실행 로그 탐지" 네 가지.

LiteLLM이 뭐길래 이게 위험한가

LiteLLM은 OpenAI·Anthropic·Azure 등 수십 개 LLM 제공자를 하나의 OpenAI 호환 API로 묶어주는 프록시 게이트웨이임. 즉 회사 안의 여러 서비스가 이 게이트웨이 하나를 거쳐 모델을 호출하게 되는 구조라, 여기엔 보통 각 제공자의 API 키, 사용량 정보, 라우팅 설정이 전부 모여 있음. 한마디로 "열쇠 꾸러미"인 셈인데, 이 열쇠 꾸러미가 도는 호스트에서 명령이 실행된다면 피해 범위가 게이트웨이 한 대로 끝나지 않는다는 게 문제임.

명령어 주입, 개념만 짚고 가기

명령어 주입은 애플리케이션이 외부에서 들어온 값을 검증 없이 시스템 셸 명령의 일부로 갖다 쓸 때 발생함. 공격자가 정상 값처럼 보이는 입력에 셸이 해석하는 구분 기호를 슬쩍 끼워 넣으면, 의도한 명령 뒤에 공격자의 명령이 이어붙어 실행되는 식임. CVE-2026-42271 계열도 결국 "신뢰할 수 없는 입력 → 셸/명령 실행 경로로 도달"이라는 같은 뿌리에서 나온 것으로 봄.

• 설정값·파일 경로·외부 연동 파라미터 등 "설마 여기로?" 싶은 입력이 명령에 섞이는 경우가 많음.
• 실행 가능한 페이로드는 여기서 다루지 않음. 방어자 입장에선 "어떤 입력이 명령 실행 경로까지 가느냐"만 추적하면 됨.

중요한 건 공격을 재현하는 게 아니라, 우리 환경의 어느 입력이 명령 실행으로 이어질 수 있는지를 먼저 찾아두는 것이라 생각함.

그래서, 어떻게 탐지하나

방어자 관점에서 가장 먼저 볼 곳은 게이트웨이 호스트의 프로세스 생성 로그임. LLM 프록시 같은 서비스 계정이 갑자기 sh, bash, curl, wget 같은 자식 프로세스를 띄운다면 그 자체가 강한 신호임.

• LiteLLM 프로세스의 비정상 자식 프로세스 생성을 EDR·auditd(리눅스 execve 감사)로 탐지함.
• 게이트웨이에서 평소 안 나가던 목적지로의 아웃바운드 연결(역방향 셸·외부 다운로드 의심)을 네트워크단에서 모니터링함.
• API 키가 갑자기 비정상 시간대·비정상 위치에서 쓰이면 키 유출 정황으로 보고 즉시 회수·재발급함.
• 요청 본문·파라미터에 셸 구분 기호나 명령형 문자열이 섞여 들어오는 패턴을 WAF·로그에서 룰로 잡음.

완화는 이렇게 — 우선순위대로

개인적으로는 아래 순서대로 손대는 걸 추천함. 패치가 1번인 건 당연하지만, 패치 한 번으로 안심하지 말고 구조적인 격리까지 같이 가는 게 핵심이라 봄.

• 1) 최신 버전으로 업데이트. CVE-2026-42271의 정확한 영향 버전·패치 버전은 BerriAI 공식 어드바이저리/릴리스 노트와 NVD 항목에서 반드시 확인하고 적용하기 바람.
• 2) 입력 검증·허용목록. 게이트웨이로 들어오는 설정·파라미터는 화이트리스트 기반으로 검증하고, 명령 실행이 꼭 필요하면 셸을 거치지 말고 인자 배열로 직접 호출하는 방식을 택함.
• 3) 최소권한·격리. 게이트웨이를 전용 컨테이너/네임스페이스에서 비루트로 돌리고, 아웃바운드를 필요한 제공자 도메인으로만 제한함. 한 대가 뚫려도 측면 이동을 끊는 게 목적임.
• 4) 비밀정보 분리. API 키를 환경변수에 평문으로 두지 말고 시크릿 매니저로 옮기고, 정기 회전 정책을 둠.
• 5) 인터넷 직접 노출 금지. 관리·API 엔드포인트는 인증·네트워크 경계 뒤에 두기.

마무리하며

AI를 빠르게 붙이다 보니 정작 그 트래픽이 모이는 길목의 보안은 뒤로 밀리는 경우가 많은 것 같음. CVE-2026-42271은 "LLM 보안 = 프롬프트 인젝션"이라는 좁은 시야를 넘어, 게이트웨이라는 인프라 자체가 전통적인 RCE 표적이 될 수 있다는 걸 다시 알려준 사례라 생각함. 알고 계셨나요? 결국 막는 방법은 새롭지 않습니다 — 패치하고, 입력 믿지 말고, 권한 줄이고, 로그를 본다. 우리 환경의 LiteLLM부터 같이 점검해보아요!

핵심 요약 3줄

• CVE-2026-42271은 LiteLLM 게이트웨이의 명령어 주입 취약점으로, 성공 시 호스트 임의 명령 실행과 API 키 유출로 이어질 수 있음.
• 탐지는 프로세스 생성 로그·비정상 아웃바운드·키 오남용 모니터링이 핵심.
• 완화는 최신 패치 + 입력 검증 + 최소권한·격리 + 비밀정보 분리를 함께 적용하는 것이 정답임.