LMDeploy SSRF 취약점이 드러낸 LLM 서빙 인프라 보안

오픈소스 LLM 서빙 툴킷 LMDeploy의 SSRF(Server-Side Request Forgery) 취약점은 공개 뒤 13시간도 지나기 전에 실전 공격에 쓰였다. 2026년 4월 21일 GitHub 보안 어드바이저리로 게시된 CVE-2026-33626은 CVSS 7.5의 고위험 취약점이다. Sysdig 위협 연구팀은 공개 후 12시간 31분 만에 자사 허니팟에서 첫 익스플로잇 시도를 탐지했다.

이 사건은 AI 인프라의 확산 속도에 패치 적용이 따라가지 못하는 문제를 보여준다. 취약점 공개 정보 자체가 공격 설계에 필요한 단서가 될 수 있다는 점도 함께 드러났다.

이미지 URL 처리 경로가 SSRF 진입점이 된 이유

LMDeploy는 InternLM 팀이 개발한 오픈소스 LLM 압축·배포·서빙 툴킷이다. GPU 클러스터에서 대형 언어 모델을 효율적으로 운영하는 기능을 제공하며, 비전-언어 모델(Vision-Language Model, VLM) 지원도 포함한다. CVE-2026-33626은 이 VLM 이미지 로딩 모듈에서 발생했다.

문제의 중심은 lmdeploy/vl/utils.py에 있는 load_image() 함수다. 외부 입력 URL로 이미지를 불러오는 이 함수에는 URL 검증 로직이 없었다. http:// 또는 https:// 스킴을 포함한 URL이라면 서버가 그대로 요청을 전송하는 구조였다.

따라서 공격자는 http://169.254.169.254/의 AWS IMDS, http://127.0.0.1:3306의 로컬호스트 MySQL, RFC 1918 사설 IP 대역을 URL로 전달할 수 있다. LMDeploy 서버는 그 요청을 내부 목적지로 전송하게 된다.

SSRF는 서버를 공격자가 제어하는 HTTP 클라이언트로 바꾼다. 외부에서 직접 닿지 않는 내부 네트워크 리소스, 클라우드 메타데이터 엔드포인트, 인접 서비스가 모델 서버를 경유해 접근 가능한 대상이 된다. 이미지 URL을 받는 동작은 VLM 서비스에서 자연스러운 기능이므로, 악성 요청도 정상 트래픽과 구별하기 어려울 수 있다.

허니팟에서 확인된 내부 정찰 흐름

Sysdig 위협 연구팀이 허니팟에서 관찰한 세션은 8분 동안 10개 이상의 악성 요청으로 이뤄졌다. 요청은 내부 서비스 탐색, 외부 연결 확인, 관리 플레인과 포트 탐색으로 이어졌다.

⤢✕

세션 초반 공격자는 AWS IMDS 주소인 http://169.254.169.254/latest/meta-data/를 향하는 요청을 LMDeploy에 전달했다. 클라우드 인스턴스에서 모델 서버가 이 주소에 접근하면 IAM 역할 자격증명, 인스턴스 프로필, 리전 정보 같은 민감한 클라우드 구성 데이터를 얻을 수 있다. 이어 2분 이내에 Redis 기본 포트인 6379를 향한 SSRF 프로브도 발생했다. Redis는 LLM 서빙 환경에서 세션 캐시, 벡터 저장소, 작업 큐 등에 자주 쓰이므로 가치가 높은 표적이다.

공격자는 외부 DNS 콜백 서비스인 requestrepo.com에 OOB(Out-of-Band) 요청을 보내 SSRF 성공 여부를 확인했다. 응답을 직접 읽을 수 없는 블라인드 SSRF 환경에서도 원격으로 성공 여부를 판별하는 방식이다. 이후 /openapi.json을 열거해 모델 서버가 노출한 추가 API 공격 면을 탐색했다.

후반부에는 DistServe의 P2P 연결 드롭 엔드포인트인 /distserve/p2p_drop_connect를 대상으로 추론 클러스터 운영 장애를 유발하려는 시도가 관찰됐다. 마지막에는 로컬호스트의 8080 보조 HTTP 인터페이스, 3306 MySQL, 80 웹 서버 포트를 스캔해 내부 서비스 맵을 구성했다.

어드바이저리가 익스플로잇의 입력값이 될 때

CVE-2026-33626은 공개 PoC(Proof of Concept) 코드가 없는 상태에서도 공격이 시작됐다. 어드바이저리에 포함된 영향 파일명 lmdeploy/vl/utils.py, 취약 함수명 load_image(), 파라미터 구조만으로도 공격자는 익스플로잇을 구성할 수 있었다.

현재 상용 LLM은 구체적인 취약 코드 정보를 입력받아 잠재적 익스플로잇 코드를 생성할 수 있다. 이 때문에 어드바이저리 자체가 턴키 익스플로잇의 입력 프롬프트처럼 작동할 수 있다.

전통적인 Coordinated Vulnerability Disclosure 방식은 AI 도구가 보편화된 환경에서 다른 위험을 갖게 됐다. 취약점 공개와 패치 적용 사이의 Time-to-Patch가 더 중요해졌고, AI 인프라 운영자는 CVE 공개와 동시에 대응할 수 있는 체계를 갖춰야 한다.

모델 서버가 내부망 피벗이 되는 구조

LLM 서빙 인프라는 일반 웹 애플리케이션과 다른 공격 면을 갖는다.

⤢✕

LLM 서빙 서버는 외부 사용자 요청을 처리하는 동시에 내부 모델 스토리지, 캐시, 추론 클러스터와 통신한다. 이 배치 자체가 SSRF 피벗의 출발점이 된다.

VLM에서 이미지 URL 입력은 핵심 기능이다. 정상 기능을 유지하면서 SSRF 경로를 차단해야 한다는 점이 보안 설계를 어렵게 만든다. 대규모 추론용 GPU 클러스터도 노드 간 통신, 모델 파라미터 동기화, 분산 서빙 조정에 필요한 관리 포트를 가진다. 외부에서 직접 접근하지 못하는 포트라도 SSRF를 통해 간접 노출될 수 있다.

2025년 이후 빠르게 확산된 Model Context Protocol(MCP) 서버도 새로운 공격 면이다. MCP는 LLM에 외부 도구와 데이터 소스 접근 권한을 부여한다. 단일 노출 MCP 엔드포인트가 내부 인프라 전체로 이어지는 브리지가 될 수 있어, AI 인프라에서 가장 미보안 상태인 영역으로 꼽힌다.

URL 검증부터 런타임 탐지까지 이어지는 방어

CVE-2026-33626 같은 AI 인프라 SSRF 공격은 단일 패치만으로 막기 어렵다. 애플리케이션, 클라우드 메타데이터, 네트워크, 런타임을 함께 다루는 심층 방어가 필요하다.

load_image()처럼 URL을 처리하는 함수는 아웃바운드 요청 전에 화이트리스트 기반 검증을 수행해야 한다. 로컬호스트 127.0.0.0/8, 링크-로컬 169.254.0.0/16, RFC 1918 사설 대역인 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16은 차단 대상이다. LMDeploy 0.12.3 패치는 이 계층에서 IP 주소 필터링을 구현했다.

AWS에서는 IMDSv2(Instance Metadata Service v2)를 강제 적용하는 방식이 IMDS 보호에 효과적이다. IMDSv2는 메타데이터 접근 전에 PUT 요청으로 세션 토큰을 발급받는 토큰 기반 인증 방식이다. 단순 GET 기반 SSRF 프리미티브로는 이 토큰을 얻을 수 없으므로 httpTokens=required 설정은 자격증명 탈취의 핵심 경로를 차단한다. 컨테이너 환경에서는 httpPutResponseHopLimit=1을 설정해 기본 브리지 네트워크를 통한 컨테이너의 IMDS 접근을 막아야 한다.

추론 서버의 외부 접근은 모델 아티팩트 스토리지인 S3·GCS와 로깅 엔드포인트로 제한해야 한다. VPC 보안 그룹과 이그레스 필터링을 사용하고, Redis·MySQL·관리 인터페이스는 추론 서버와 별도 네트워크 세그먼트에 배치한다. 서버 간 불필요한 통신에는 기본 차단 정책을 적용하며, DNS 레벨 필터링으로 사설 IP 대역 리다이렉트도 차단한다.

링크-로컬과 RFC 1918 주소를 향하는 아웃바운드 연결은 실시간으로 모니터링할 대상이다. OOB DNS 콜백 패턴, 비정상 외부 도메인 접근, 짧은 시간에 반복되는 내부 IP 접근 시도는 탐지 규칙에 포함할 수 있다. Sysdig가 이번 공격을 발견한 배경도 허니팟 기반 이상 행동 탐지 체계였다.

취약점 대응을 수동 확인에 맡기지 않기

AI 오픈소스 툴킷은 빠른 기능 추가만큼 빠른 취약점 발생 가능성을 안고 있다. CVE-2026-33626처럼 공개 후 수 시간 안에 공격이 시작되는 환경에서는 수동 모니터링만으로 대응하기 어렵다.

NVD(National Vulnerability Database), GitHub Security Advisories, OSV(Open Source Vulnerabilities) 피드를 자동화 파이프라인에 연결하면 사용 중인 AI 툴킷 관련 CVE 게시 시 알림을 받을 수 있다. LMDeploy는 GitHub Advisory로 공개됐으므로 GitHub의 dependabot alerts 또는 security advisories 구독이 효과적이다.

SCA(소프트웨어 구성 분석) 도구를 CI/CD 파이프라인에 통합하면 의존성 패키지의 CVE를 빌드 단계에서 탐지할 수 있다. Snyk, Trivy, OWASP Dependency-Check가 대표적이며, 컨테이너 이미지 취약점 스캐닝도 배포 전 단계에 포함해야 한다.

고위험인 CVSS 7.0 이상 CVE에는 자동 패치 PR 생성과 스테이징 환경 배포를 트리거하는 체계를 둘 수 있다. 사람의 개입 없이도 빠르게 검토 가능한 상태를 만드는 것이 대응 시간 단축의 핵심이다.

LMDeploy를 사용 중인 환경이라면 0.12.3 이상으로 업그레이드하고 기존 자격증명 유출 여부를 점검해야 한다. CVE 모니터링 자동화, IMDSv2 강제 적용, 이그레스 필터링, 네트워크 분리, 런타임 이상 탐지를 결합해야 자동화된 공격에 대응할 수 있다.