CVE-2026-63764: LMDeploy SSRF — HIGH

CISO Take

lmdeploy's OpenAI-compatible API server can be tricked into fetching internal resources: an unauthenticated attacker submits a chat completion request with an image_url pointing to a server they control, which responds with an HTTP 302 redirect to an internal target such as the loopback interface or cloud instance-metadata endpoint, and lmdeploy follows that redirect without re-validating it against its SSRF safety guard. This is a critical, network-exploitable, zero-privilege, zero-interaction bug (CVSS 9.3) against any AI inference deployment exposing this API publicly or on a shared network, with confidentiality impact that can include cloud IAM credential theft via metadata services. There is no CISA KEV listing, no EPSS score, and no known public exploit or Nuclei template yet, so exploitation looks theoretical for now rather than actively weaponized — but the bypass technique requires no specialized AI/ML knowledge, so that window is likely short. Until a patched release is confirmed upstream, restrict network egress from lmdeploy hosts, block loopback and cloud metadata IP ranges (e.g., 169.254.169.254) at the host firewall or via IMDSv2 enforcement, and alert on outbound requests to internal/metadata ranges triggered by image_url fetches.

Sources: NVD GitHub vulncheck.com CISA KEV ATLAS

What is the risk?

Critical. The combination of CVSS 9.3, network attack vector, no authentication, no user interaction, and low attack complexity makes this trivially reachable by any actor who can send HTTP requests to the exposed endpoint. Confidentiality impact is high because SSRF against cloud metadata endpoints commonly yields IAM credentials, enabling lateral movement well beyond the AI service itself. Mitigating factors are the absence of CISA KEV status, no EPSS score, and no public exploit or scanner template — indicating no confirmed mass exploitation yet — but the vulnerability class (redirect-based SSRF guard bypass) is well understood and easy to reproduce once the technique is public, so risk should be treated as high urgency despite the lack of current telemetry.

How does the attack unfold?

Initial Access

An unauthenticated attacker sends a POST request to lmdeploy's chat completions endpoint with an image_url pointing to an attacker-controlled server that passes the initial SSRF safety check.

AML.T0049

Redirect Bypass

The attacker's server responds with an HTTP 302 redirecting to an internal target such as a loopback address or the cloud instance-metadata endpoint; lmdeploy follows the redirect without re-validating it against the safety guard.

Internal Resource Access

lmdeploy fetches the internal or metadata resource on the server's behalf, exposing content that is normally unreachable from outside the host's network.

AML.T0075

Impact

Fetched content, such as cloud IAM credentials or internal service data, is reflected back through the model's response or error output, giving the attacker read access to sensitive internal information.

AML.T0024

Initial Access

An unauthenticated attacker sends a POST request to lmdeploy's chat completions endpoint with an image_url pointing to an attacker-controlled server that passes the initial SSRF safety check.

AML.T0049

Redirect Bypass

The attacker's server responds with an HTTP 302 redirecting to an internal target such as a loopback address or the cloud instance-metadata endpoint; lmdeploy follows the redirect without re-validating it against the safety guard.

Internal Resource Access

lmdeploy fetches the internal or metadata resource on the server's behalf, exposing content that is normally unreachable from outside the host's network.

AML.T0075

Impact

Fetched content, such as cloud IAM credentials or internal service data, is reflected back through the model's response or error output, giving the attacker read access to sensitive internal information.

AML.T0024

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LMDeploy	pip	—	No patch
8.1K 1 dependents Pushed 8d ago 60% patched ~17d to patch Full package profile →

Do you use LMDeploy? You're affected.

How severe is it?

CVSS 3.1

8.6 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 33% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Changed

C High

I None

A None

What should I do?

1 step

1) Track lmdeploy's GitHub repository and issue #4761 for a patched release, and upgrade as soon as one ships. 2) Until patched, do not expose the OpenAI-compatible API server directly to untrusted networks; place it behind an authenticating reverse proxy. 3) Enforce network-level egress controls from the lmdeploy host: block outbound requests to loopback (127.0.0.0/8), link-local (169.254.0.0/16, including cloud metadata IPs), and RFC1918 private ranges unless explicitly required. 4) Where supported, disable automatic HTTP redirect following in the image-fetch client, or re-validate the resolved destination IP against the safety guard on every hop (not just the initial URL). 5) Enforce IMDSv2 (or equivalent metadata-service hardening) on the underlying cloud instance so a successful SSRF cannot retrieve credentials via a simple GET. 6) Monitor/alert on outbound HTTP requests from the lmdeploy process to internal IP ranges or metadata endpoints as a detection signal for exploitation attempts.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable Yes

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage API Inference AML.T0049 - Exploit Public-Facing Application AML.T0075 - Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

ISO 42001

Annex A.6 - AI system technical security controls

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-63764?

lmdeploy's OpenAI-compatible API server can be tricked into fetching internal resources: an unauthenticated attacker submits a chat completion request with an image_url pointing to a server they control, which responds with an HTTP 302 redirect to an internal target such as the loopback interface or cloud instance-metadata endpoint, and lmdeploy follows that redirect without re-validating it against its SSRF safety guard. This is a critical, network-exploitable, zero-privilege, zero-interaction bug (CVSS 9.3) against any AI inference deployment exposing this API publicly or on a shared network, with confidentiality impact that can include cloud IAM credential theft via metadata services. There is no CISA KEV listing, no EPSS score, and no known public exploit or Nuclei template yet, so exploitation looks theoretical for now rather than actively weaponized — but the bypass technique requires no specialized AI/ML knowledge, so that window is likely short. Until a patched release is confirmed upstream, restrict network egress from lmdeploy hosts, block loopback and cloud metadata IP ranges (e.g., 169.254.169.254) at the host firewall or via IMDSv2 enforcement, and alert on outbound requests to internal/metadata ranges triggered by image_url fetches.

Is CVE-2026-63764 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-63764, increasing the risk of exploitation.

How to fix CVE-2026-63764?

1) Track lmdeploy's GitHub repository and issue #4761 for a patched release, and upgrade as soon as one ships. 2) Until patched, do not expose the OpenAI-compatible API server directly to untrusted networks; place it behind an authenticating reverse proxy. 3) Enforce network-level egress controls from the lmdeploy host: block outbound requests to loopback (127.0.0.0/8), link-local (169.254.0.0/16, including cloud metadata IPs), and RFC1918 private ranges unless explicitly required. 4) Where supported, disable automatic HTTP redirect following in the image-fetch client, or re-validate the resolved destination IP against the safety guard on every hop (not just the initial URL). 5) Enforce IMDSv2 (or equivalent metadata-service hardening) on the underlying cloud instance so a successful SSRF cannot retrieve credentials via a simple GET. 6) Monitor/alert on outbound HTTP requests from the lmdeploy process to internal IP ranges or metadata endpoints as a detection signal for exploitation attempts.

What systems are affected by CVE-2026-63764?

This vulnerability affects the following AI/ML architecture patterns: model serving, multimodal/vision-language inference, agent frameworks, cloud-hosted LLM API deployments.

What is the CVSS score for CVE-2026-63764?

CVE-2026-63764 has a CVSS v3.1 base score of 8.6 (HIGH). The EPSS exploitation probability is 0.39%.

What is the AI security impact?

Affected AI Architectures

model servingmultimodal/vision-language inferenceagent frameworkscloud-hosted LLM API deployments

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

LMDeploy through 0.14.0, fixed in commit 03c3130, contains a server-side request forgery (SSRF) vulnerability in the _load_http_url function within the connection.py media handler, where the private-IP guard validates only the original URL without re-validating hosts after HTTP redirects. An unauthenticated attacker can submit a crafted image_url to the chat completions endpoint pointing to an attacker-controlled host that returns a redirect to a private IP or cloud-metadata endpoint, causing the server to follow the redirect and expose internal service content through the model pipeline.

Exploitation Scenario

An unauthenticated attacker identifies an internet-facing lmdeploy OpenAI-compatible endpoint (e.g., via banner/service discovery). They stand up a server they control and send a POST to /v1/chat/completions with a multimodal message whose image_url points to that server — passing lmdeploy's initial SSRF safety check since the URL looks external and benign. Their server responds with an HTTP 302 redirecting to http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> (or another internal target such as a loopback admin port). lmdeploy follows the redirect without re-running the safety check against the new destination, fetches the metadata response, and the fetched content (or an error revealing it) is reflected back to the attacker through the model's response or logs — handing them temporary cloud credentials or internal service data they can use for further compromise of the hosting environment.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF)

CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

Source: MITRE CWE corpus.