Summary: Sysdig recorded the first live exploitation of the LMDeploy SSRF flaw CVE-2026-33626 12 hours and 31 minutes after disclosure, before a public proof of concept existed. The flaw let an attacker use a vision-language image loader to reach cloud metadata, internal services, and internal ports. Affected versions run through 0.12.0, and the advisory listed no patched version at the time.
Look at the timing first. Sysdig’s honeypots logged their first live attack just 12 hours and 31 minutes after the vulnerability details landed on GitHub: at 03:35 UTC on April 22, 2026, IP 103.116.72[.]119 began sending ten requests at an open-source LLM inference server across an eight-minute session, feeling out the internal network behind it step by step. At that point, no proof-of-concept exploit existed. The server that took the hit was running LMDeploy, the open-source toolkit the InternLM team maintains for compressing, deploying, and serving large language models. The flaw carries the identifier CVE-2026-33626: server-side request forgery (SSRF), rated CVSS 7.5 and classed high severity. What deserves attention is the surface that came under attack. No model was jailbroken; the inference server itself was repurposed as a tunnel into the internal network. For any team running self-hosted vision-language model services, the takeaway is blunt — attackers now reach the AI supply chain on a clock measured in hours rather than days.
Where the Flaw Lives: An Image Loader With No IP Checks
The defect sits in load_image() in lmdeploy/vl/utils.py. Requests to a vision-language model (VLM) may carry an image_url from the caller, and the server retrieves that address before handing the result to the model. Nothing checks whether the destination is an internal or private address before the HTTP request goes out, and encode_image_base64() fails in exactly the same way. In advisory GHSA-6w67-hwm5-92mq, the maintainers state the root cause plainly: no validation at all before the fetch, and no blocklist covering the internal ranges (127.0.0.1, 169.254.x.x, 10.x.x.x, 192.168.x.x). The shipped defaults deepen the exposure: api_server.py binds to 0.0.0.0 out of the box and API keys start disabled, which leaves an internet-reachable LLM server ready to issue HTTP requests for whoever asks. Every release up to and including 0.12.0 that supports vision-language models is affected. Igor Stepansky, a researcher at Orca Security, found the bug and reported it.
The Honeypot Record: First Exploitation Inside 13 Hours
Sysdig’s analysis rewards a careful read, especially from whoever operates these stacks. Its honeypot network caught the first exploitation attempt 12 hours and 31 minutes after the vulnerability appeared on GitHub, at 03:35 UTC on April 22 — a single eight-minute session of ten requests, run in three phases:
- Phase one aimed straight at the AWS Instance Metadata Service (IMDS) and the Redis instances on the server
- Phase two fired an out-of-band DNS callback to requestrepo[.]com, proving the SSRF could reach arbitrary external hosts, then enumerated the API surface
- Phase three ran a port scan across the loopback interface (127.0.0[.]1) All the while, the attacker alternated between two VLMs, internlm-xcomposer2 and OpenGVLab/InternVL2-8B, dressing each probing step as an ordinary model call to cut the chance of tripping a detection rule.
From Inference Server to Internal Springboard: the SSRF Chain
The attack scenario in the advisory walks the whole chain: a “describe this image” request goes to /v1/chat/completions while image_url points at http://169.254.169.254/latest/meta-data/iam/security-credentials/. The server retrieves the address as asked, the model answers as designed, and the cloud IAM credentials ride out inside the reply. The impacts listed officially cover theft of cloud credentials, contact with internal services that have no internet exposure, port scans across internal networks, and openings for lateral movement.
Viewed that way, the LLM server’s “fetch this URL for the user” feature is an SSRF primitive already sitting in the codebase. The attacker never has to get past the firewall, because the malicious requests are issued from inside it.
Why Weaponization Reaches AI Infrastructure First
Sysdig’s wider finding outweighs this single incident: over the past six months, critical vulnerabilities in inference servers, model gateways, and agent orchestration tools have been turned into working attacks within hours of the advisory’s publication, however small the install base. Generative AI keeps speeding the collapse. An advisory as specific as GHSA-6w67-hwm5-92mq — file named, parameter named, root cause explained, sample vulnerable code attached — is, in Sysdig’s words, “effectively an input prompt for any commercial LLM to generate a potential exploit.” The structural drivers are straightforward. The AI toolchain is built on open-source components, release cycles are fast, and services tend to start in the least-protected configuration that still works — authentication off, bound to 0.0.0.0, exposed straight to the internet. More teams will self-host open models as the year runs on (we mapped the open-source route divergence in our opening outlook for 2026), while the security posture of these inference stacks is plainly trailing their adoption curve.
Hardening Steps for a Self-Hosted Inference Stack
- Enumerate every internet-exposed LMDeploy instance first: everything at or below 0.12.0 with vision-language support counts. The advisory’s patched-versions field reads “None,” so holding out for an upgrade is not a plan
- Contain it at the network layer: enforce IMDSv2, block egress from inference services toward 169.254.169.254 and private ranges, and filter egress at the gateway
- Switch on API-key auth and drop the 0.0.0.0 binding; put allowlists on parameters of the “server fetches this for you” kind, image_url included
- Treat honeypots and out-of-band detection as standard equipment: this incident drew a live visitor in 12.5 hours, so the detection window has to be planned in hours