LMDEPLOY · CVE-2026-123818 · Package
FIX → 0.15.0
LMDeploy's URL safety check parses a crafted URL to a public host, while the HTTP client connects to a loopback address, so a remote attacker can make the server fetch internal resources (SSRF). The impact stated in the advisory is server-side request forgery.
first public Sep 18, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Teams that run LMDeploy 0.12.3 up to but not including 0.15.0 and let users supply URLs that the server fetches. The flaw sits in the URL validation path, so deployments that never fetch user-supplied URLs are less exposed. unknown whether other code paths are affected.
Not affected if no-user-supplied-urls, version-0.15.0-or-later
Who cares lmdeploy, python, self-hosted
pip show lmdeploy_is_safe_url followed by requests fetches on user-supplied URLs in your LMDeploy deploymentUpgrade to 0.15.0
lmdeploy (fixed version per the product data; affected range )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)Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
0.15.0>= 0.12.3, < 0.15.0requests 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
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.