A critical security flaw in LMDeploy, an open source toolkit for compression, deployment, and deployment of LLMs, has come under active exploitation in the wild less than 13 hours after it was publicly disclosed.
Vulnerability, tracked as CVE-2026-33626 (CVSS Score: 7.5), is related to a Server-Side Request Forgery (SSRF) vulnerability that can be used to access sensitive data.
“A server-side application forgery (SSRF) vulnerability exists in the LMDeploy language module,” according to an advisory published by project maintainers last week. “The load_image() function in lmdeploy/vl/utils.py downloads arbitrary URLs without validating internal/private IP addresses, allowing attackers to access cloud metadata resources, internal networks, and sensitive resources.”
The flaw affects all versions of the toolkit (0.12.0 and earlier) with support for the vision language. Orca Security researcher Igor Stepansky is credited with finding and reporting the bug.
Successful exploitation of the vulnerability could allow an attacker to steal cloud credentials, access internal services not exposed to the Internet, probe internal networks, and create lateral movement opportunities.
Cloud security firm Sysdig, in an analysis published this week, said it detected the first LMDeploy exploit attempt against its honeypot systems within 12 hours and 31 minutes of the vulnerability being published on GitHub. The exploit attempt originates from the IP address 103.116.72[.]119.
“The attacker doesn’t just confirm the error and move on. Instead, over a single eight-minute session, they used a visual language image loader like a generic HTTP SSRF classic to test the internal network behind the model server: AWS Instance Metadata Service (IMDS), Redis, MySQL, a secondary HTTP interface for out-of-band management, an HTTP out-of-band interface, and a DNS export. it said.
The actions taken by the enemy, detected on Apr 22, 2026, at 03:35 am UTC, revealed more than 10 different requests in three phases, with requests switching between visual language models (VLMs) such as internlm-xcomposer2 and OpenGVLab/InternVL to avoid any possible -8B avoidance.
- Point the AWS IMDS and Redis instances to the server.
- Check out the out-of-band (OOB) DNS callback to request the repo[.]com to ensure the SSRF vulnerability can reach unsuspecting external hosts, followed by calculating the API location.
- Port scan loopback interface (“127.0.0[.]1”)
The findings are another reminder of how threat actors closely monitor new vulnerability disclosures and exploit them before downstream users apply fixes, even in cases where there is no proof-of-concept (PoC) exploit during the attack.
“CVE-2026-33626 fits a pattern we’ve seen repeatedly in the AI infrastructure space over the past six months: significant vulnerabilities in index servers, model gateways, and agent orchestration tools are deployed within hours of the advisory’s publication, regardless of the size or level of its installation base,” Sysdig said.
“Generative AI (GenAI) accelerates this rollout. A clear advisory like GHSA-6w67-hwm5-92mq, which includes the affected file, parameter name, cause description, and vulnerable code sample, is an effective message to include in any commercial LLM to generate a potential exploit.”
WordPress plugins and Modbus devices are targeted
This disclosure comes as malicious actors have also been seen exploiting vulnerabilities in two WordPress plugins – Ninja Forms – File Upload (CVE-2026-0740, CVSS score: 9.8) and Breeze Cache (CVE-2026-3844, CVSS score: 9.8bit) available to load sites without code extraction and full takeover.
The unknown attackers have also been linked to a global campaign targeting exposed, Modbus-enabled PLCs (PLCs) from September to November 2025 that covered 70 countries and 14,426 targeted IPs, mostly located in the US, France, Japan, Canada, and India. A subset of these requests were found to originate from sources in China.
“The work included extensive automated checks and selected patterns that suggest the depth of device fingerprinting, tampering attempts, and potential spoofing methods when PLCs are located on the public Internet,” Cato Networks researchers said. “Many source IPs had low or zero public reputation results, consistent with new hosts or rotating scans.”
