"A server-side request forgery (SSRF) vulnerability exists in LMDeploy's vision-language module," the project's advisory warned, after maintainers disclosed a flaw that was weaponized in the wild less than 13 hours later.
CVE-2026-33626 and the vulnerable load_image() function
The flaw, tracked as CVE-2026-33626 (CVSS score: 7.5), is an SSRF weakness in LMDeploy's vision-language code. According to the advisory published by the project maintainers, the load_image() function in lmdeploy/vl/utils.py "fetches arbitrary URLs without validating internal/private IP addresses, allowing attackers to access cloud metadata services, internal networks, and sensitive resources." The shortcoming affects all versions of the toolkit (0.12.0 and prior) that include vision-language support. Orca Security researcher Igor Stepansky is credited with discovering and reporting the bug.
Sysdig honeypot: exploitation detected within 12 hours, 31 minutes
Cloud security firm Sysdig reported detecting an exploitation attempt against its honeypot systems 12 hours and 31 minutes after the vulnerability was published on GitHub. The activity, detected on Apr 22, 2026, at 03:35 a.m. UTC, originated from IP address 103.116.72[.]119 and unfolded over a single eight-minute session comprising 10 distinct requests across three phases.
Rather than a single validation probe, the attacker used the vision-language image loader "as a generic HTTP SSRF primitive" to perform a range of actions: probing the AWS Instance Metadata Service (IMDS), scanning Redis and MySQL ports, enumerating an administrative HTTP interface, and confirming egress via an out-of-band (OOB) DNS callback to requestrepo[.]com. Sysdig noted the attacker switched between vision language models such as internlm-xcomposer2 and OpenGVLab/InternVL2-8B during the sequence, likely to avoid detection.
What the adversary probed: IMDS, local services, and OOB exfiltration
Sysdig's analysis lays out a clear exploitation pattern. The attacker targeted cloud metadata (AWS IMDS) and local services on the server, verified external reachability with an OOB DNS request to requestrepo[.]com, then went on to port-scan the loopback interface (127.0.0[.]1). The firm observed enumeration of the model server's API surface and explicit attempts at lateral discovery, actions that "could permit an attacker to steal cloud credentials, reach internal services that aren't exposed to the internet, port scan internal networks, and create lateral movement opportunities," per the project advisory.
Sysdig framed the finding as consistent with a broader set of rapid weaponizations in the AI-infrastructure space, noting that an advisory that includes "the affected file, parameter name, root-cause explanation, and sample vulnerable code" — such as GHSA-6w67-hwm5-92mq — serves as an input for exploit development. "Generative AI (GenAI) is accelerating this collapse," the company wrote.
Concurrent activity: WordPress plugin exploits and Modbus PLC scanning
The LMDeploy exploitation arrived amid other active campaigns. Threat actors have been observed exploiting two WordPress plugin vulnerabilities — Ninja Forms - File Upload (CVE-2026-0740, CVSS 9.8) and Breeze Cache (CVE-2026-3844, CVSS 9.8) — to upload arbitrary files and achieve code execution that can lead to full site takeover.
Separately, Cato Networks researchers linked unknown attackers to a global campaign targeting internet-exposed, Modbus-enabled programmable logic controllers (PLCs) from September to November 2025. That campaign spanned 70 countries and 14,426 distinct targeted IPs, with most targets located in the U.S., France, Japan, Canada, and India; a subset of requests was geolocated to China. Cato noted the activity mixed broad automated probing with more selective fingerprinting and disruption attempts, and many source IPs had low or zero public reputation scores, consistent with fresh or rotating scanning hosts.
What technologists, open-source maintainers, and cloud operators should watch
- Technologists and security teams: prioritize patching LMDeploy instances that include vision-language support (all versions 0.12.0 and prior are affected), and monitor logs for SSRF indicators described in the analysis — unexpected IMDS requests, attempts to reach requestrepo[.]com, scans of loopback services (127.0.0[.]1), and probes of Redis/MySQL ports.
- Open-source maintainers and deployers: review the load_image() implementation in lmdeploy/vl/utils.py for proper internal/private IP validation and consider removing or constraining arbitrary URL fetch behavior; maintainers have already published an advisory acknowledging the vulnerability and credited Igor Stepansky for reporting it.
- Cloud operators and infrastructure owners: watch for attempts to access instance metadata services and for other lateral-discovery behaviors originating from model-serving endpoints, and treat model gateways and inference servers as potential SSRF vectors when exposed to untrusted inputs.
The LMDeploy incident is a stark example of a recurring pattern: detailed advisories that name files and include sample code can accelerate exploit development, and adversaries are watching disclosures closely. As Sysdig observed, the combination of precise public advisories and automated or assisted exploit generation makes hours — not days — the relevant window for some vulnerabilities. The question left by this episode is practical and urgent: given how fast exploit attempts appear, can detection and patching cadence keep up with the next disclosure?
Original reporting: The Hacker News — LMDeploy CVE-2026-33626 Flaw Exploited
