LMDeploy SSRF in load_image() Vision-Language Module (CVE-2026-33626) — Actively Exploited Within 13 Hours of Disclosure

LMDeploy SSRF in load_image() Vision-Language Module (TL-2026-0426), also tracked as GHSA-6w67-hwm5-92mq, is a high-severity software vulnerability scored CVSS 7.5, first published 2026-04-27. It has no confirmed attribution, affects InternLM LMDeploy, references 1 CVE (CVE-2026-33626), maps to 20 MITRE ATT&CK techniques (T1018, T1046, T1048.003), and is covered by 9 detection rules and 18 indicators of compromise.

Key facts for TL-2026-0426

Threat ID
TL-2026-0426
Also known as
GHSA-6w67-hwm5-92mq, LMDeploy load_image SSRF
Severity
HIGH
CVSS
7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
Status
ACTIVE
Category
VULNERABILITY
First published
2026-04-27
Last reviewed
2026-04-27
Attribution confidence
NONE
Motivation
FINANCIAL
Target sectors
technology, ai-ml, cloud-services, research, education, financial, healthcare, media
Target regions
Global, North America, Europe, Asia-Pacific
Detection rules
9
Indicators of compromise
18

Malware and tooling in LMDeploy SSRF in load_image() Vision-Language Module

Malware and tooling: requestrepo

InternLM LMDeploy <= 0.12.0 contains a server-side request forgery (SSRF) vulnerability in the load_image() helper of lmdeploy/vl/utils.py. The function fetches arbitrary URLs supplied to vision-language models without validating the destination, allowing unauthenticated attackers to coerce the inference server into requesting AWS Instance Metadata Service (169.254.169.254), loopback admin interfaces, internal Redis/MySQL services, and arbitrary intranet hosts. Active exploitation was observed 12 hours 31 minutes after public disclosure, with attackers using out-of-band DNS exfiltration via requestrepo[.]com to steal IMDS-issued cloud credentials.

How LMDeploy SSRF in load_image() Vision-Language Module works

CVE-2026-33626 is a server-side request forgery (SSRF) vulnerability in InternLM's LMDeploy, a widely deployed open-source toolkit for compressing, deploying, and serving large language and vision-language models (VLMs). The flaw resides in the helper function load_image() located at lmdeploy/vl/utils.py, which is invoked whenever a vision-capable endpoint (such as the OpenAI-compatible /v1/chat/completions API) receives an image_url field referencing an HTTP(S) URL. The function passes the URL directly to a Python urllib/requests fetch without validating the scheme, host, or resolved IP, and without enforcing an allowlist or blocking link-local, loopback, or RFC1918 destinations.

An unauthenticated remote attacker who can reach the LMDeploy inference endpoint can supply a crafted message such as { "role": "user", "content": [{"type": "image_url", "image_url": {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}}] }. The server fetches the URL server-side and returns the body (or a fetch error containing the body) to the client, leaking AWS Instance Metadata Service v1 (IMDSv1) responses including STS-issued temporary credentials when the EC2 instance role permits it. The same primitive is abused to enumerate internal services (Redis 6379, MySQL 3306, Kubernetes API 6443, admin dashboards on 127.0.0.1), to perform out-of-band DNS-based data exfiltration via requestrepo[.]com subdomains, and to scan internal CIDR ranges from inside the victim's VPC.

The vulnerability was reported privately by Igor Stepansky of Orca Security to InternLM on 2026-04-15. InternLM published GitHub Security Advisory GHSA-6w67-hwm5-92mq and released LMDeploy 0.12.1 with the patch on 2026-04-21, adding hostname/IP validation that rejects link-local, loopback, multicast, and private ranges before any network fetch. CVE-2026-33626 was assigned by MITRE on 2026-04-22 and active exploitation began the same day at 03:35 UTC — 12 hours and 31 minutes after the public advisory — sourced from 103.116.72.119. Sysdig threat researchers documented the exploitation pattern on 2026-04-23, observing wide internet-scale scanning for exposed LMDeploy endpoints (default port 23333 and 8000) and image_url SSRF probes against discovered hosts.

The attack chain is: (1) discover an internet-exposed LMDeploy server hosting a vision-capable model such as internlm-xcomposer2 or OpenGVLab/InternVL2-8B; (2) send a crafted chat completion request with a malicious image_url; (3) confirm SSRF reachability via OOB DNS callback to attacker-controlled requestrepo[.]com; (4) read /latest/meta-data/iam/security-credentials/ from IMDS to obtain AWS STS access/secret/session tokens; (5) pivot using the stolen credentials to S3, ECR, and other cloud resources, and use the same SSRF to enumerate internal services for data theft and lateral movement. Defenders should treat any exposed LMDeploy inference endpoint as compromised until proven otherwise, rotate all IAM role credentials issued to the host, and patch to LMDeploy >= 0.12.1 immediately. EC2 hosts running LMDeploy should be migrated to IMDSv2 (token-required) which mitigates basic SSRF retrieval of credentials.

MITRE ATT&CK techniques used in TL-2026-0426

Discovery

T1018 Remote System Discovery; T1046 Network Service Discovery; T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery

Exfiltration

T1048.003 Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol; T1567 Exfiltration Over Web Service

Command and Control

T1071.001 Application Layer Protocol: Web Protocols; T1071.004 Application Layer Protocol: DNS

Initial Access

T1190 Exploit Public-Facing Application

Execution

T1203 Exploitation for Client Execution

Collection

T1213 Data from Information Repositories; T1530 Data from Cloud Storage

Impact

T1496 Resource Hijacking

Credential Access

T1528 Steal Application Access Token; T1552.005 Unsecured Credentials: Cloud Instance Metadata API

Lateral Movement

T1550.001 Use Alternate Authentication Material: Application Access Token

Resource Development

T1583.001 Acquire Infrastructure: Domains

Reconnaissance

T1592 Gather Victim Host Information; T1595 Active Scanning; T1595.002 Active Scanning: Vulnerability Scanning

Affected products and versions in LMDeploy SSRF in load_image() Vision-Language Module

  • InternLM — LMDeploy
    Vulnerable versions: <= 0.12.0; all releases prior to 0.12.1
    Fixed in: 0.12.1; >= 0.12.1
  • InternLM — lmdeploy (PyPI)
    Vulnerable versions: <= 0.12.0
    Fixed in: 0.12.1
  • InternLM — openmmlab/lmdeploy (Docker Hub image)
    Vulnerable versions: <= v0.12.0; latest tag prior to 2026-04-21
    Fixed in: v0.12.1

Remediation for LMDeploy SSRF in load_image() Vision-Language Module

Patches

  • LMDeploy 0.12.1 — https://github.com/InternLM/lmdeploy/releases/tag/v0.12.1
  • Backported fix commit adds is_safe_url() validator that rejects private/loopback/link-local/multicast IPs after DNS resolution

Immediate actions

  • Upgrade LMDeploy to 0.12.1 or later — git pull && pip install -U lmdeploy>=0.12.1
  • Restrict LMDeploy inference endpoints to authenticated, internal traffic only; never expose port 23333/8000 directly to the internet
  • Migrate all EC2 hosts running LMDeploy to IMDSv2 (token-required) via aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1
  • Block egress from LMDeploy hosts to 169.254.169.254 except where explicitly required, and to all RFC1918/loopback ranges from inference worker processes
  • Rotate IAM role credentials issued to any host that ran a vulnerable LMDeploy version exposed to untrusted input
  • Add DNS sinkhole or egress block for requestrepo.com and *.requestrepo.com
  • Block source IP 103.116.72.119 at perimeter and check NetFlow/proxy logs for inbound traffic from this address since 2026-04-22 03:35 UTC

Workarounds

  • If patching is blocked, monkeypatch lmdeploy.vl.utils.load_image to call a wrapper that validates the resolved IP against ipaddress.ip_address(host).is_global before fetching
  • Place LMDeploy behind an authenticating reverse proxy (e.g., OAuth2 Proxy, Pomerium) with WAF rules that strip image_url fields containing private hosts
  • Run LMDeploy with --network=none in Docker and provide image inputs via volume mount only, eliminating the SSRF primitive entirely
  • Configure host-level egress firewall (iptables/nftables) to drop traffic from inference processes to 169.254.169.254/32 and RFC1918 ranges

Longer-term hardening

  • Deploy WAF rules that inspect image_url fields in JSON request bodies and reject link-local/loopback/RFC1918 URLs
  • Place all LLM inference workloads in a dedicated VPC subnet with strict egress controls and no IMDS access where possible
  • Adopt a default-deny egress policy for AI inference workloads with allowlists for required model registries (huggingface.co, modelscope.cn) only
  • Implement SSRF-aware HTTP libraries (e.g., gohttpclient/safeurl-go equivalents in Python) for any service that fetches user-supplied URLs
  • Run AI inference services as non-root with seccomp/AppArmor profiles that block raw socket access
  • Continuously scan internet-facing assets with Shodan/Censys queries for LMDeploy banners and remediate exposure

CVEs associated with LMDeploy SSRF in load_image() Vision-Language Module

CVE-2026-33626

Weaknesses (CWE) in LMDeploy SSRF in load_image() Vision-Language Module

CWE-918, CWE-20, CWE-200, CWE-441

Timeline of LMDeploy SSRF in load_image() Vision-Language Module

  • Igor Stepansky of Orca Security privately reports SSRF vulnerability in LMDeploy load_image() to the InternLM security team via GitHub Security Advisory channel.
  • InternLM maintainers acknowledge the report, confirm reproduction on LMDeploy 0.12.0 against internlm-xcomposer2 and OpenGVLab/InternVL2-8B, and begin patch development adding URL validation to lmdeploy/vl/utils.py.
  • GitHub Security Advisory GHSA-6w67-hwm5-92mq published; LMDeploy 0.12.1 released with patched is_safe_url() validator rejecting link-local, loopback, multicast, and private IP ranges. Public disclosure timestamp: 15:04 UTC.
  • First in-the-wild exploitation observed at 03:35 UTC — 12 hours 31 minutes after public disclosure — from source IP 103.116.72.119, using OOB DNS callbacks to requestrepo[.]com to confirm SSRF reachability before stealing AWS IMDS credentials from /latest/meta-data/iam/security-credentials/.
  • MITRE assigns CVE-2026-33626 with CVSS 3.1 base score 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).
  • Sysdig Threat Research publishes detailed exploitation analysis with payload examples, IOC list, and detection guidance; documents internet-scale scanning for exposed LMDeploy instances on default ports 23333 and 8000.
  • The Hacker News publishes coverage emphasizing the 13-hour exploitation window and risk to AI infrastructure operators. Scanner activity from secondary IPs increases.
  • Honeypot data shows scanning has expanded beyond the initial source IP, with multiple distinct payload variants targeting both Hugging Face-hosted and locally hosted vision models. Some payloads now attempt to read /latest/dynamic/instance-identity/document for richer metadata.
  • Check Point Research's 27th April 2026 weekly Threat Intelligence Report features CVE-2026-33626 as a top emerging threat, urging immediate patching of LMDeploy across enterprise AI/ML environments.
  • As of 2026-05-29, CVE-2026-33626 (LMDeploy SSRF) remains an actively exploited n-day: patched in 0.12.3 (record says 0.12.1; actual fix is 0.12.3 per GHSA-6w67-hwm5-92mq), yet in-the-wild exploitation since 13h post-disclosure plus public PoC/lab code keep exposed, unpatched inference hosts at risk. Not in CISA KEV; no takedown.

Sources cited for LMDeploy SSRF in load_image() Vision-Language Module

Threats related to LMDeploy SSRF in load_image() Vision-Language Module

Detection coverage for TL-2026-0426

As of 2026-04-27, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0426 across Splunk SPL, Microsoft KQL and Sigma, covering 18 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats