LMDeploy under SSRF threat exploited in hours exposes domestic remedies

Less than 13 hours after becoming public, a high-gravity vulnerability in LMDeploy - the open source toolkit to compress, deploy and serve language and vision models - was already being exploited in real environments. The failure, recorded as CVE-2026-33626 with CVSS 7.5 score, is a variant of Server-Side Request Forgery (SSRF) in the vision-language module: a function that downloads images from URLs not valid if these addresses belong to internal networks or cloud metadata services, opening the door to unauthorized access to sensitive resources.

The vector is simple and dangerous: the image loader accepts arbitrary URLs. An input-control attacker may force the server to request internal resources such as the AWS instance metadata service (IMDS), local databases, administrative interfaces in loopback or internal endpoints that are normally not accessible from the Internet. In the reported case, the attackers combined internal port scanning and exfiltration by DNS OOB to confirm and exploit the SSRF capacity as "HTTP primitive."

The fact that the holding took place in a matter of hours is no coincidence. In practice, technical divulgations that include the vulnerable code fragment, the parameter name and functional examples act as precise instructions for malicious actors - and today also as prompts for commercial models - accelerating the translation of a detected problem to an operational explosion. This shows a worrying dynamic in the IA infrastructure ecosystem: extremely short response time between publication and attack.

The potential consequences are material and multifaceted. Cloud credentials theft by IMDS, recognition and lateral movement to internal services, commitment of databases or queues, and the possibility of persistence if the server concerned has extended permissions are plausible scenarios. For industrial environments or that run exposed controllers and PLCs, the combination of massive tests and selective scans is a recipe for interruptions and manipulation.

From the operational point of view, the first immediate priority should be to contain the exposure. If your organization uses LMDeploy with vision-language support, apply the official correction if it is already available or temporarily disable the remote image loading features. As an additional containment measure, block or restrict outgoing traffic from inference servers, implement egress rules that allow only explicitly necessary domains and ranges and ensure that there is no direct access to 169.254.169.254 (IMDS) or to loopback interfaces from processes that accept customer URLs.

There are specific mitigation in the cloud that reduce the impact of this type of SSRF. For AWS instances, enable IMDSv2 and set the hop limit or disable access to metadata when it is not necessary to limit an attacker's ability to steal credentials. It is also recommended to apply strict network segmentation, apply white lists of domains for outgoing fets and use inverse or validator proxies that check all / blacklist of IPs and RFC1918 ranges before allowing an external application. In general terms, validating and normalizing URLs entries is mandatory; avoiding this validation was the root of the incident.

In detection and response, look for clear indicators: server requests about 169.254.169.254, loopback connections 127.0.0.1 from processes that do not normally perform them, consultation chains containing URLs provided by third parties, and atypical DNS consultations to OOB domains (out-of-band). Check the models service for request patterns that change between different models or show attempts to scan internal ports. If you suspect commitment, isolate the instance, collect evidence and rotate exposed credentials.

This incident should serve as a reminder that security in model infrastructure is not just traditional hardening: it involves considering how functions designed for flexibility (such as loading a remote image) can become vectors of access to the internal network. Product managers and safety equipment should incorporate network exposure-oriented design reviews, SSRF tests and default output controls in any component that processes external URLs.

To deepen SSRF prevention and mitigation patterns, please refer to the OWASP guide on the subject and AWS documentation for the metadata service, which describe specific production controls: OWASP SSRF Prevention Cheat Sheet and AWS Instance Metadata Service (IMDS) documentation. In addition, the very publication of the finding and the correction can be found in the public advice of the project: GitHub Advisory GHSA-6w67-hwm5-92mq.

In short, organizations that deploy inference models and gateways must assume that the exploits will arrive very quickly after disclosure and prepare both patches and compensatory measures and detection capabilities. Update, segment, monitor and validate inputs are the pillars for reducing immediate risk; sustained improvement requires integrating these practices into the IA infrastructure development and deployment cycle.