A critical security flaw in a popular open-source LLM toolkit was published on GitHub. Within half a day, attackers were already using it in the wild.
The vulnerability, tracked as CVE-2026-33626, carries a CVSS score of 7.5. It affects LMDeploy, a toolkit used for compressing, deploying, and serving large language models. The LMDeploy SSRF vulnerability exploitation began just 12 hours and 31 minutes after public disclosure.
That's not a typo. Attackers had a working exploit before most developers even read the advisory.
What Is the Vulnerability?
The flaw exists in LMDeploy's vision-language module. Specifically, the load_image() function inside lmdeploy/vl/utils.py fetches images from URLs without validating those addresses.
An attacker can provide any URL to the application, including the URL of an internal IP address, a metadata endpoint in the Cloud, or even resources on a private network.
If an attacker has access to an LMDeploy SSRF vulnerability, they could:
1. Steal AWS, GCP, or Azure cloud credentials from metadata services.
2. Access internal services that should never be accessed via public internet connectivity.
3. Conduct port-scanning on internal networks.
4. Lateral movement to other systems.
Orca Security researcher Igor Stepansky discovered and reported the bug. It affects LMDeploy versions 0.12.0 and earlier that have vision-language support enabled.
How the Attack Unfolded
Cloud security firm Sysdig detected the first LMDeploy SSRF vulnerability exploitation attempt against its honeypot systems on April 22, 2026, at 3:35 a.m. UTC.
The attack came from IP address 103.116.72[.]119.
What happened next was not a simple proof-of-concept test. Over a single eight-minute session, the attacker used the vision-language image loader as a generic HTTP SSRF primitive to perform a systematic internal reconnaissance.
Exploitation of the LMDeploy SSRF vulnerability occurred in three phases using a total of 10 requests.
Phase One: Attacker targeting AWS IMDS and redis on the server. The attacker first targeted the IMDS and redis running on the server as a means of accessing the cloud credentials stored within the IMDS, which provide access to many cloud environments.
Phase Two: Attacker uses OOB DNS Callbacks to test exfiltration paths. The attacker made a DNS request to reqestrepo[.]com to determine if the SSRF vulnerability would allow communication with arbitrary external hosts. This step is routinely performed to test possible paths for future exfiltration of data.
Phase Three: Attacker scans internal network. The attacker executed a port scan of the loopback interface at the address 127.0.0[.]1 and used multiple different vision-language models (e.g., internlm-xcomposer2, OpenGVLab/internVL2-8B) within the requests to avoid detection.
Why So Fast?
The speed of this LMDeploy SSRF vulnerability exploitation fits a disturbing trend. Over the past six months, critical vulnerabilities in inference servers, model gateways, and agent orchestration tools have been weaponized within hours of public disclosure.
Sysdig researchers pointed to a specific reason: generative AI itself is accelerating the attack timeline.
An advisory that includes the affected file name, parameter name, root-cause explanation, and sample vulnerable code is effectively an input prompt for any commercial LLM. Attackers can paste the advisory into an LLM and ask it to generate a working exploit. No human reverse-engineering required.
In this case, the LMDeploy SSRF vulnerability exploitation occurred without any public proof-of-concept code being available at the time of the attack.
Not an Isolated Incident
While the LMDeploy SSRF vulnerability exploitation was unfolding, threat actors were also busy elsewhere.
WordPress plugins under fire. Two WordPress plugins: Ninja Forms – File Upload (CVE-2026-0740) and Breeze Cache (CVE-2026-3844) are being actively exploited. Both have CVSS scores of 9.8. Attackers are uploading arbitrary files to vulnerable sites, leading to complete site takeover.
Modbus PLCs targeted globally. Between September and November 2025, unknown attackers targeted internet-exposed, Modbus-enabled programmable logic controllers across 70 countries. A total of 14,426 distinct IPs were hit, with most in the U.S., France, Japan, Canada, and India. Some of the scanning activity originated from China.
Cato Networks researchers noted that the activity blended large-scale automated probing with selective patterns suggesting deeper device fingerprinting and potential disruption attempts.
How to Protect Your LMDeploy Instance
If you are running LMDeploy with vision-language support, here is what you need to do immediately.
First, upgrade. The LMDeploy maintainers have released a fix. Update to the latest patched version as soon as possible. This is the only complete mitigation.
Second, restrict network access. If you cannot upgrade immediately, place your LMDeploy instance behind a firewall or API gateway that blocks requests to internal IP addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.0.0/16). Also block access to cloud metadata endpoints like 169.254.169.254.
Third, monitor for unusual image requests. Look for load_image() calls requesting internal IP addresses or metadata endpoints in your logs. Any such request is suspicious because legitimate image loading should only fetch public URLs.
Fourth, rotate cloud credentials. If your LMDeploy instance has been exposed to the public internet, assume it has been probed. Rotate any cloud credentials that instance had access to.
Final Thoughts
The ongoing exploitation of this LMDeploy SSRF vulnerability should really make everyone stand up and pay attention. The time between a disclosure and an exploit being released is now hours (not days or weeks) instead of days or weeks, with attackers closely monitoring GitHub releases and security advisories/commit logs in "real-time."Generative AI has democratized exploit development.
An advisory that once required a skilled reverse engineer to weaponized can now be handed to an LLM that produces working code in minutes.
For defenders, this means one thing: you cannot wait to patch. The LMDeploy SSRF vulnerability exploitation timeline proves that waiting even half a day is too long. Automated patch management, network segmentation, and runtime monitoring are no longer optional, they are the bare minimum.
FAQ Section
Q1: Which LMDeploy releases are affected by CVE-2026-33626?
All prior 0.12.0 LMDeploy build/version releases with vision-language capability are exposed to this vulnerability. The load_image() method does not validate IP addresses on the inside of the application and can therefore be exploited with SSRF.
Q2: Can LMDeploy SSRF vulnerability exploitation allow an attacker to take control over a cloud account?
Yes. An attacker can use SSRF to access the IMDS cloud metadata service (e.g., AWS at 169.254.169.254) to obtain temporary cloud access credentials and use them to access S3 storage, launch more cloud resources, or move laterally through cloud systems.
Q3: Prior to the attack, was any publicly available proof-of-concept (PoC) exploit for LMDeploy SSRF vulnerabilities?
No. There were no known publicly accessible LMDeploy SSRF PoC exploit attempts prior to the attacks. Attackers probably exploited LMDeploy by constructing the proof-of-concept using a commercial large language model based on (or similar to) the description contained in the detailed advisory alert for the LMDeploy SSRF exploit.
Q4: What are the ways to determine whether or not my LMDeploy agent has been compromised?
You can find compromised LMDeploy instances by examining your logs for load_image() calls directed at internal IP Networks (10.x.x.x, 172.16.x.x, and 192.168.x.x) or the instance metadata API at 169.254.169.254. In addition, you should also be on the lookout for any out-of-band DNS requests made to suspicious domains such as requestrepo[.]com.
Q5: Are LMDeploy instances that provide only text LLMs susceptible to this vulnerability?
No, they are not affected. The load_image() function that is vulnerable resides only within the vision-language module. If you utilize LMDeploy solely for text-based LLMs without any vision-language functionality, you will not experience this SSRF vulnerability at this time.
