LMDeploy SSRF exploited in 12 hours

LMDeploy is one of those tools that sits behind AI apps and quietly does the heavy lifting — serving models, handling multimodal inputs, and turning prompts into outputs. That makes this bug more than “just another SSRF.” A server-side request forgery flaw in LMDeploy let attackers make the model server reach into places the public internet should never touch, including cloud metadata services and internal databases. The news is how fast that moved from advisory to real traffic: Sysdig saw exploitation 12 hours and 31 minutes after public disclosure on April 21, 2026. (sysdig.com) ### What was the bug, exactly? The vulnerable code lived in LMDeploy’s vision-language image handling. If an attacker supplied a URL for an image, the `load_image` path would fetch it without blocking private or internal destinations. In plain English, the server could be tricked into requesting `169.254(sysdig.com)re 0.12.3. (github.com) ### Why is SSRF so nasty here? Because an AI inference box often has better network access than the user talking to it. It may sit inside a VPC, hold temporary cloud credentials, and talk to storage, queues, vector databases, or internal APIs. So an SSRF on that box is less like “fetch the wrong webpage” and more like handing an outsider a remote-controlled arm ins(github.com) much — they can expose short-lived IAM credentials that open the next door. (sysdig.com) ### What did attackers actually do? The first activity Sysdig saw hit a honeypot at 03:35 UTC on April 22. The probing was not random. It targeted AWS instance metadata, then scanned internal ports tied to services like Redis and MySQL. Sysdig said there was no public GitHub proof-of-concept at the time, which makes the speed more striking — attackers were clearly watching disclosures and building their own exploit flow fast. (sysdig.com) ### Why did the timeline matter so much? Security teams still tend to think in patch cycles measured in days. This one compressed into half a day. The GitHub advisory went public on April 21 at 15:04 UTC, and exploitation showed up 12 hours 31 minutes later. That means the old comfort blanket — “we’ll patch tomorrow morning” — is getting thinner, especially for exposed AI infrastructure. (sysdig.com) ### Was there a fix? Yes. LMDeploy 0.12.3 shipped with security fixes, and multiple advisory databases list that version as the patched release. If a deployment is still on anything earlier, the safe assumption is that it is exposed if the vulnerable image-loading path is reachable. (github.com) already have been reachable. That means rotating cloud credentials, reviewing access to metadata services, and checking logs for requests to link-local or RFC1918 addresses. Edge filtering helps too — block outbound requests to internal IP ranges from components that only need public (github.com) IMDSv2 reduces the blast radius. (sysdig.com) ### Why is this bigger than one bug? Because it says something ugly about the new attack surface. AI serving stacks are getting dropped into production fast, often with broad permissions and rich network paths. Attackers have noticed. The lesson is not just “patch LMDeploy.” It’s that LLM infrastructure now belongs in the same urgent bucket as internet-facing VPNs, firewalls, and CI systems. (sysdig.com) ### Bottom line The scary part is not that LMDeploy had an SSRF. Plenty of software ships bugs. The scary part is that a flaw in AI inference infrastructure turned into live exploitation in 12 and a half hours — fast enough that disclosure and attack now almost blur together. (sysdig.com)