CVE-2026-33626: LMDeploy SSRF Exploited 13 Hours After Disclosure — Upgrade to 0.12.3 Now

CVE-2026-33626 — CVSS 7.5, High. Affects all LMDeploy versions below 0.12.3. Fix: upgrade immediately.

The flaw lives in lmdeploy/vl/utils.py, specifically in the load_image() function used by LMDeploy’s vision-language module. The function fetches arbitrary URLs without validating against internal or private IP ranges. That makes it a clean SSRF primitive: send a crafted image URL, and the server makes an outbound request to any target on the internal network — AWS IMDS, Redis, MySQL, internal admin interfaces, whatever is reachable from the inference host.

GitHub advisory GHSA-6w67-hwm5-92mq dropped on April 21. Sysdig detected the first exploit attempt against its honeypot at 03:35 AM UTC on April 22 — 12 hours and 31 minutes later.

The attacker ran a methodical, three-phase campaign. They rotated between two VLMs (internlm-xcomposer2 and OpenGVLab/InternVL2-8B) to blend into normal API traffic and evade detection. Then they probed the AWS Instance Metadata Service endpoint, followed by Redis, MySQL, and an internal HTTP admin interface. Finally, they used out-of-band DNS exfiltration to confirm data extraction without generating obvious outbound HTTP logs.

Ten distinct requests. Systematic. Professional.

This matters beyond LMDeploy. AI inference infrastructure has historically been treated as an internal-only, low-risk service — something you run inside a VPC and assume is safe. That assumption is wrong. LMDeploy, vLLM, Triton Inference Server, and similar tools are increasingly exposed at the edge or on shared Kubernetes clusters where network boundaries are not as clean as they appear on architecture diagrams.

The SSRF attack surface on AI serving systems is large. Vision-language models that accept image URLs as inputs are especially dangerous: the entire point of the feature is to make the server fetch external content, which is exactly what an SSRF attacker needs. Without strict SSRF controls — IP allowlisting, metadata endpoint blocking, outbound network policies — any VLM endpoint that accepts user-supplied URLs is a potential pivot point into the internal network.

What to patch:

• Upgrade to LMDeploy 0.12.3 or later (pip install lmdeploy --upgrade)
• Block outbound requests to 169.254.169.254 (AWS IMDS) at the network level regardless of software version
• If running LMDeploy on Kubernetes, enforce egress NetworkPolicies to restrict which subnets the inference pod can reach
• Audit logs for requests to load_image() with internal IP ranges or suspicious DNS names

The broader lesson: treat AI inference endpoints with the same paranoia you’d apply to any public-facing web service. Patch windows on AI-specific CVEs are compressing fast — 12 hours is not enough time to respond manually.