LMCache 다중 프로세스 모드에서 검증되지 않은 원격 코드 실행 취약점이 공개되어 대형 모델 추론 캐시 계층에 영향을 미침

2026년 10월 8일, iThome과 JFrog Security Research가 동시에 보도했으며, LMCache가 다중 프로세스(분산) 모드에서 검증되지 않은 원격 코드 실행 취약점(CVE‑2026‑105192)을 가지고 있으며, CVSS v3.1 기본 점수는 9.8로 위험 등급에 해당합니다. 이 보도는 양쪽 매체가 동일한 시점에 발표함으로써 취약점의 심각성을 강조했으며, 해당 점수는 산업 전반에서 높은 위험으로 분류되는 수준임을 의미합니다. 따라서 보안 담당자는 즉시 영향을 받는 시스템을 식별하고 대응 방안을 검토해야 할 필요가 있습니다.

취약점 개요

이 결함은 JFrog 연구팀(번호 JFSA‑2026‑001694382)이 2026년 10월 7일 공개했으며, LMCache 0.3.9부터 모든 버전에 영향을 미치고 최신 0.5.5 정식 버전, 0.5.6rc3 테스트 버전 및 개발 브랜치까지 모두 패치되지 않았습니다. 취약점의 근원은 LMCache가 프로세스 간 KV‑cache 공유를 위해 활성화한 ZeroMQ ROUTER 소켓으로, 기본적으로 TCP 5555 포트를 청취하며 CURVE, ZAP, 비밀번호 또는 HMAC과 같은 인증 메커니즘을 전혀 사용하지 않았습니다. 이러한 설계 선택은 초기 구현 단계에서 성능 최적화를 목표로 했지만, 결과적으로 인증이 전혀 적용되지 않은 상태에서 외부 연결을 허용하게 되었습니다. 따라서 공격자는 네트워크 레벨에서 해당 포트에 접근할 수 있는 경우, 추가적인 방어 메커니즘 없이도 악용이 가능하다는 점이 핵심 위험 요소로 지적됩니다.

기술 세부 사항

다중 노드 배포 시 사용자는 `--host` 매개변수를 통해 라우팅 가능한 주소를 제공해야 하며, ZeroMQ 소켓은 localhost에만 바인딩된 상태에서 외부 접근이 가능하도록 전환됩니다. LMCache는 전송 인코딩으로 msgpack을 사용하고, msgpack 확장 코드 1은 `DeviceIPCWrapper.Deserialize`에 매핑됩니다. 이 함수는 내부에서 Python 표준 라이브러리의 `pickle.loads`를 직접 호출합니다. 이 역직렬화는 서버가 `REGISTER_KV_CACHE` 매개변수를 파싱하는 단계에서 수행되며, 아직 어떤 요청 처리기로 진입하지 않았기 때문에 공격자가 악성 pickle 페이로드를 삽입하여 디코딩 시 임의의 Python 코드를 실행할 수 있습니다. 즉, 이 과정은 요청이 실제 비즈니스 로직으로 전달되기 전에 발생하므로, 악성 페이로드가 실행될 경우 시스템 전체의 신뢰 경계가 무너지는 결과를 초래합니다. 또한, msgpack 확장 코드와 pickle 결합 구조는 일반적인 직렬화 검증 절차와는 별개로 동작하므로, 기존 보안 도구가 이를 탐지하기 어려운 상황을 만들기도 합니다.

공격 흐름

사용자는 열려 있는 5555 포트로 특수 제작된 msgpack 메시지를 전송하기만 하면 되며, 해당 pickle 페이로드는 파일(예: `/tmp/zmq_pwn`)에 기록될 수 있고, 이후 타입 오류 로그 출력을 트리거하여 코드가 LMCache 프로세스 컨텍스트에서 실행되었음을 증명합니다. 공식 컨테이너 이미지에서는 기본적으로 root 권한으로 LMCache를 시작하므로, 공격이 성공하면 공격자는 컨테이너 내부에서 root 권한을 획득하고 동일한 호스트의 다른 서비스에 영향을 미칠 수 있습니다. 이와 같은 흐름은 네트워크 접근만으로도 전체 서비스 체인에 침투할 수 있음을 보여주며, 특히 컨테이너 환경에서 기본 사용자 권한이 root인 경우 위험도가 급격히 상승합니다. 로그에 남는 타입 오류는 공격 성공 여부를 확인하는 흔적으로 활용될 수 있으며, 이를 통해 공격자는 추가적인 권한 상승 단계나 지속성을 확보하는 전략을 구사할 수 있습니다.

영향 범위

영향을 받는 버전에는 0.3.9, 0.4.x, 0.5.x 시리즈가 포함되며, 공식 제공 컨테이너 이미지 역시 모두 패치되지 않았습니다. iThome은 LMCache가 독립적인 다중 프로세스 서비스로 실행될 때만 ZeroMQ 포트가 열리며, vLLM 프로세스 내부에서만 LMCache를 사용할 경우 해당 포트가 시작되지 않아 취약점이 노출되지 않는다고 지적했습니다. 기본 설정에서는 ZeroMQ가 localhost에만 바인딩되어 원격 공격자가 직접 접근할 수 없으며, 관리자가 `--host`를 라우팅 가능한 주소로 수동 설정해야만 접근이 가능합니다. 따라서 배포 환경에 따라 위험 노출 정도가 크게 달라질 수 있으며, 특히 다중 프로세스 모드를 활성화하고 외부 IP를 지정한 경우에는 즉시 공격 표면이 형성됩니다. 반면, 단일 프로세스 모드나 내부 전용 네트워크에서만 운영되는 경우에는 기본 바인딩 제한으로 인해 외부 위협이 차단되는 효과를 기대할 수 있습니다.

완화 및 권고 사항

JFrog는 다중 프로세스 서비스의 바인딩 주소를 즉시 localhost로 제한하고 방화벽이나 클러스터 네트워크 정책을 통해 TCP 5555 포트를 차단할 것을 권고합니다. 보안 패치를 받기 전까지 `--host` 매개변수에 외부 라우팅 가능한 IP를 사용하지 말아야 합니다. 장기적으로는 전송 계층을 재설계하여 검증되지 않은 네트워크 데이터에 pickle 역직렬화를 사용하지 않고, 보다 안전한 직렬화 형식을 채택하며 ZeroMQ 소켓에 인증(CURVE 또는 HMAC 등)을 추가해야 합니다. 또한, 운영자는 현재 실행 중인 컨테이너 이미지의 사용자 권한을 검토하고, 가능하면 비 root 사용자로 전환하는 것이 권장됩니다. 임시 완화 조치로는 서비스 재시작 시 `--host` 옵션을 생략하거나, 로컬 인터페이스에만 바인딩하도록 명시적으로 설정하는 방법이 있습니다. 이러한 조치는 공식 패치가 배포될 때까지 위험을 최소화하는 실질적인 방어선이 됩니다.

후속 조치 및 전망

2026년 10월 8일 현재, 업체는 아직 어떤 패치 버전도 발표하지 않았으며, 위험한 역직렬화를 비활성화한 업데이트된 컨테이너 이미지를 제공하지도 않았고, 복구 일정도 확정되지 않았습니다. 서드파티 배포판이 완화 조치를 이미 적용했는지도 불분명합니다. 환경이 기본 localhost 바인딩을 사용하거나 컨테이너를 신뢰할 수 없는 네트워크와 격리한 경우 원격 공격자로부터 직접적인 위협을 받지 않지만, 내부 직원이나 이미 침해된 호스트는 이 취약점을 이용해 컨테이너 내부에서 최고 권한을 얻을 수 있습니다. 보안 커뮤니티는 이러한 상황을 주시하며, 임시 방어 전략과 모니터링 강화를 촉구하고 있습니다. 특히 로그 분석과 네트워크 트래픽 감시를 통해 비정상적인 msgpack 메시지 전송 시도를 조기에 탐지하는 것이 중요합니다. 향후 공식 패치가 제공될 때까지 조직 차원에서 위험 평가를 재실시하고, 필요 시 서비스 중단이나 격리 조치를 고려하는 것이 바람직합니다.