From Disclosure to Exploitation in Hours: LMDeploy SSRF Vulnerability Exploited in the Wild

In the rapidly evolving landscape of AI infrastructure, the window between vulnerability disclosure and active exploitation is shrinking to a matter of hours. A recent case study involving LMDeploy—an open-source toolkit from the Shanghai AI Laboratory designed for serving large language models (LLMs)—serves as a stark warning. A high-severity Server-Side Request Forgery (SSRF) vulnerability was weaponized in the wild just 12 hours and 31 minutes after its public disclosure, requiring no pre-existing proof-of-concept (PoC) code to succeed.

On April 21, 2026, the security advisory GHSA-6w67-hwm5-92mq was published, eventually assigned CVE-2026-33626. The flaw, carrying a CVSS score of 7.5, strikes at the heart of LMDeploy’s vision-language capabilities.

Technical Root Cause: Unsanitized URL Fetching

The vulnerability resides within the load_image() function located in lmdeploy/vl/utils.py. When the vision-language module receives an API request containing an image URL, the function fetches the content to process it for the model. However, the implementation fails to implement a “deny-list” or “allow-list” for the destination IP addresses.

Because the function does not validate whether the provided URL points to a public internet address or a sensitive internal network resource, an attacker can substitute a legitimate image URL with an internal endpoint. This allows them to force the inference server to act as a proxy, fetching data from local databases, internal microservices, or cloud metadata services, and returning the response to the attacker.

Timeline of an Exploitation: From Advisory to Attack

The speed of the attack highlights a critical shift in threat actor behavior. According to the Sysdig Threat Research Team (TRT), who monitored the exploit via a specialized honeypot, the first malicious attempt occurred at 03:35 UTC on April 22, 2026. The traffic was traced to IP 103.116.72.119, originating from Hong Kong.

Interestingly, the attacker did not need a leaked exploit script. The technical specificity of the GitHub advisory—which explicitly named the vulnerable file, the unvalidated parameter, and the logic error—provided a complete roadmap for construction.

The Sysdig TRT observed a highly tactical eight-minute session consisting of three distinct phases:

• Phase 1: Reconnaissance & Credential Probing: The actor immediately targeted the AWS Instance Metadata Service (IMDS) via the link-local address 169.254.169.254. The goal was to exfiltrate IAM role credentials. Simultaneously, they probed 127.0.0.1:6379 to verify if a local Redis instance was reachable.
• Phase 2: Out-of-Band (OOB) Validation: To confirm that the SSRF was “blind” (meaning the attacker couldn’t see the direct response) but still functional, they triggered a DNS callback to cw2mhnbd.requestrepo.com. This confirmed the server had unrestricted egress to the internet.
• Phase 3: Lateral Movement & Denial of Service: The attacker pivoted to internal management endpoints, hitting /distserve/p2p_drop_connect to disrupt internal ZMQ inference routing. They concluded with a rapid-fire sweep of common ports (8080, 3306, 80) to map the internal landscape.

The “AI Infrastructure” Blind Spot

This incident exposes a systemic risk in modern AI deployments. Most LLM inference engines run on heavy-duty GPU cloud instances. These instances are often granted expansive IAM roles to allow seamless access to S3 buckets for model weights and training datasets. An SSRF in this context isn’t just a web bug; it is a gateway to the entire data lake.

Furthermore, while LMDeploy is a significant project with nearly 7,800 GitHub stars, it remains largely invisible to traditional enterprise security scanners that prioritize legacy enterprise software over niche AI-infrastructure tools. This lack of visibility makes such tools “soft targets” for sophisticated actors.

Remediation and Best Practices

Immediate Action: Upgrade to LMDeploy v0.12.3 or later. This version implements a _is_safe_url() validation check designed to intercept and block requests directed at private IP ranges and link-local addresses.

Defense-in-Depth Strategies:

• Egress Filtering: Implement strict firewall rules on your GPU instances. Inference nodes should generally not be able to initiate outbound connections to arbitrary internet addresses or sensitive internal subnets.
• Reverse Proxy Architecture: Use a hardened reverse proxy to sanitize incoming API requests, ensuring that any image or data URLs are validated before they reach the inference engine.
• Expanded Software Inventory: Incorporate AI-specific libraries (vLLM, TGI, Ray Serve, LMDeploy) into your formal CVE scanning and vulnerability management workflows.

Indicators of Compromise (IOCs)