At 03:35 UTC on April 22, 2026, Sysdig honeypots recorded an eight-minute burst of hostile traffic: from IP 103.116.72[.]119, ten carefully shaped requests against an open-source LLM inference server, methodically probing the internal network behind it. Only 12 hours and 31 minutes had passed since the vulnerability details landed on GitHub — and no proof-of-concept exploit existed at the time.
The target was LMDeploy, the open-source toolkit maintained by the InternLM team for compressing, deploying, and serving large language models. The flaw, tracked as CVE-2026-33626, is a high-severity server-side request forgery (SSRF) rated CVSS 7.5. What makes the case notable is the attack surface: not a jailbroken model, but the inference server itself, repurposed as a tunnel into the internal network. For every team self-hosting vision-language models, this is a wake-up call measured in hours, not days.
The Bug: An Image Loader With No IP Validation
The root of the problem is load_image() in lmdeploy/vl/utils.py. Vision-language model (VLM) inference requests let callers pass in an image_url, which the server fetches before handing it to the model. But the function fires the HTTP request without checking whether the destination is an internal or private address, and encode_image_base64() is affected the same way. The maintainers’ advisory GHSA-6w67-hwm5-92mq lists the root cause bluntly: zero validation before fetching, and no blocklist for internal ranges (127.0.0.1, 169.254.x.x, 10.x.x.x, 192.168.x.x).
The defaults make it worse: api_server.py binds to 0.0.0.0 out of the box and API keys are disabled by default, which means an internet-reachable LLM server that will happily make HTTP requests on anyone’s behalf. All versions up to and including 0.12.0 with vision-language support are affected. The bug was discovered and reported by Orca Security researcher Igor Stepansky.
Hit Within 13 Hours: What the Honeypot Recorded
The timeline in Sysdig’s analysis deserves a careful read from every ops team. The honeypot network logged the first exploitation attempt just 12 hours and 31 minutes after the vulnerability was published on GitHub, on April 22 at 03:35 UTC — one eight-minute session, ten requests, three phases:
- Phase one went straight after the AWS Instance Metadata Service (IMDS) and Redis instances on the server
- Phase two sent an out-of-band DNS callback to requestrepo[.]com to confirm the SSRF could reach arbitrary external hosts, then enumerated the API surface
- Phase three port-scanned the loopback interface (127.0.0[.]1)
The attacker also rotated between two VLMs, internlm-xcomposer2 and OpenGVLab/InternVL2-8B, wrapping the probing in ordinary-looking model calls to reduce the odds of tripping detection rules.
Turning an Inference Server Into an SSRF Springboard
The advisory’s attack scenario lays out the full chain: send a “describe this image” request to /v1/chat/completions, but point image_url at http://169.254.169.254/latest/meta-data/iam/security-credentials/. The server fetches it, the model answers, and cloud IAM credentials walk out through the model’s own response. The officially listed impacts include stealing cloud credentials, reaching internal services that are never exposed to the internet, port-scanning internal networks, and creating lateral movement opportunities.
Put differently: the “fetch this URL for the user” feature of an LLM server is a ready-made SSRF primitive. The attacker never has to bypass the firewall, because the malicious requests originate from inside it.
Why AI Infrastructure Gets Weaponized Fastest
Sysdig’s broader observation matters more than any single incident: over the past six months, critical vulnerabilities in inference servers, model gateways, and agent orchestration tools have been weaponized within hours of advisory publication, regardless of the size of the install base. And generative AI is accelerating the collapse. An advisory as specific as GHSA-6w67-hwm5-92mq — affected file, parameter name, root-cause explanation, sample vulnerable code included — is, in Sysdig’s words, “effectively an input prompt for any commercial LLM to generate a potential exploit.”
The structural reasons are not complicated. The AI toolchain leans heavily on open-source components, deployment cycles are fast, and services routinely come up in minimum-friction mode — no authentication, bound to 0.0.0.0, directly exposed. Teams self-hosting open models will only multiply this year (we touched on the open-source route divergence in our opening outlook for 2026), yet the security posture of these inference stacks clearly lags their adoption curve.
A Checklist for Self-Hosted Inference Stacks
- Inventory every internet-exposed LMDeploy instance now: anything at or below 0.12.0 with vision-language support is in scope. The advisory’s patched-versions field reads “None,” so waiting for an upgrade is not a plan
- Stop the bleeding at the network layer: enforce IMDSv2, block egress from inference services to 169.254.169.254 and private ranges, and filter egress at the gateway
- Turn API-key auth on and stop binding to 0.0.0.0; apply allowlists to “server fetches this for you” parameters like image_url
- Make honeypots and out-of-band detection routine: this incident had a live visitor within 12.5 hours, so the detection window has to be measured in hours
Sources
- LMDeploy CVE-2026-33626 Flaw Exploited Within 13 Hours of Disclosure — The Hacker News
- CVE-2026-33626: How Attackers Exploited LMDeploy LLM Inference Engines in 12 Hours — Sysdig
- Server-Side Request Forgery (SSRF) in Vision-Language Image Loading — GitHub Advisory
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.