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:NVDGitHubvulncheck.comCISA KEVATLAS

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.1K1 dependentsPushed 4d ago46% patched~18d to patchFull package profile →

Do you use LMDeploy? You're affected.

How severe is it?

CVSS 3.1

8.6 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 44% 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?

AVNetwork

ACLow

PRNone

UINone

SChanged

CHigh

INone

ANone

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?

DecisionTrack*

Exploitationpoc

AutomatableYes

Technical Impactpartial

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

How is it classified?

Auth BypassData LeakageAPIInferenceAML.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.51%.

What is the AI security impact?

Affected AI Architectures

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

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

AML.T0075Cloud 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-918Server-Side Request ForgeryPrimary CWE-918Server-Side Request Forgery

CWE-918 — Server-Side Request Forgery: 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.

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.