LMDeploy SSRF exposes cloud metadata and internal services

At a glance

What this is: LMDeploy’s OpenAI-compatible API server can be tricked into following a redirect from a public URL to internal targets, turning an unauthenticated image fetch into SSRF against cloud metadata and private services.

Why it matters: This matters because AI inference servers often sit inside trusted cloud networks, so a single redirect-handling flaw can expose IAM tokens, internal panels, and other high-value identity-bearing resources.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read OXSecurity's analysis of the LMDeploy SSRF redirect bypass

Context

Server-side request forgery happens when a service makes outbound requests on an attacker’s behalf and trusts the response path too much. In this case, the primary failure is not model logic but URL validation that stops at the first hop, which makes the primary keyword, LMDeploy SSRF, a governance issue for AI platforms running inside trusted cloud estates.

That matters to IAM and security teams because inference servers frequently inherit broad network reach and access to instance metadata, secrets, and internal APIs. Once an AI-serving component can be induced to fetch internal locations, it behaves like an unreviewed network proxy with identity-bearing side effects, which is a familiar NHI and workload trust problem in modern cloud programmes.

The starting position here is not unusual: teams often harden the application edge while assuming the fetch layer is benign. That assumption breaks as soon as redirects, metadata endpoints, or private ranges are reachable from the service runtime.

Key questions

Q: What breaks when an AI service follows redirects after validating only the first URL?

A: A first-hop URL check does not protect against server-side request forgery if the HTTP client automatically follows redirects. An attacker can pass validation with a public host and then pivot the request to internal services or cloud metadata on the next hop. The right control is hop-by-hop validation combined with redirect restrictions on untrusted fetch paths.

Q: Why do AI inference servers increase the risk of cloud credential exposure?

A: Inference servers often run inside trusted cloud networks and can reach metadata endpoints, internal APIs, and other services that users cannot access directly. If the server is tricked into making outbound requests, its own workload identity becomes the entry point to credentials or internal data. Treat these services as privileged workloads with tightly scoped egress.

Q: What do security teams get wrong about SSRF in model-serving platforms?

A: Teams often focus on whether the external URL is public and miss what happens after the first request is sent. Redirects, chained fetches, and library defaults can move the request into internal ranges even when the initial input looks safe. That is why application validation alone is not enough without network egress controls.

Q: Who is accountable when an AI endpoint exposes IAM tokens through metadata access?

A: Accountability usually sits with both the platform owner and the team operating the workload identity. The platform owner must prevent unsafe request paths, while the service owner must constrain permissions, egress, and metadata access. Frameworks such as NIST SP 800-53 and zero trust architecture place that responsibility on control owners, not on attackers.

Technical breakdown

How redirect-following turns a safe URL check into SSRF

LMDeploy validates the initial image_url host, but if the server follows redirects automatically, the attacker can move the request after the check has already passed. That creates a classic SSRF bypass: the application believes it approved a public destination, while the HTTP client actually reaches an internal address on the next hop. The security flaw sits in the boundary between application-layer validation and transport-layer behavior, where redirect handling is often delegated to libraries. In AI inference services, this becomes more dangerous because the fetch path may be used for images, documents, or retrieval inputs that trigger server-side network access.

Practical implication: re-validate every redirect hop and disable automatic redirect following for untrusted fetch paths.

Why cloud metadata endpoints are high-value targets

Cloud metadata services such as 169.254.169.254 often expose temporary credentials, instance profile details, or other identity material available to the workload. If an attacker can coerce a server into reaching that endpoint, the service becomes a credential oracle. This is especially risky in AI-serving infrastructure because the application is typically deployed with network access that users do not have directly. The issue is not just data exposure; it is the possibility of turning a model endpoint into a path to workload identity theft and privilege expansion inside the cloud environment.

Practical implication: block metadata endpoints and private ranges at egress, not only at the application layer.

Why unauthenticated AI endpoints amplify the blast radius

The attack requires no login and no victim interaction, which means exposure depends entirely on network reach and application trust boundaries. When an OpenAI-compatible endpoint accepts remote image URLs from untrusted callers, the service inherits the caller’s intent while retaining its own internal privileges. That combination makes the runtime a proxy for internal reconnaissance and credential access. The broader lesson for IAM and NHI governance is that service accounts and workload identities assigned to AI services must be treated as privileged identities, because they can be used to retrieve secrets, query internal systems, or expand access if the platform’s outbound requests are not constrained.

Practical implication: classify AI inference services as privileged workloads and scope their outbound access accordingly.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI inference server into a proxy for internal reconnaissance and cloud credential theft.

1. Entry occurs when an unauthenticated attacker submits a crafted image_url to the OpenAI-compatible chat completions endpoint.
2. Credential access follows when the server is redirected to the cloud metadata service or internal-only services, exposing IAM tokens or other sensitive responses.
3. Impact occurs when the attacker uses the exposed credentials or internal reach to pivot deeper into the hosting environment and broaden access.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

LMDeploy SSRF is a workload identity problem, not only an application bug. Once an inference server can be steered into internal requests, the real asset at risk is the workload’s access path into the cloud estate. That makes the issue directly relevant to IAM, PAM, and NHI governance because the service identity becomes the vehicle for lateral access. Practitioners should treat outbound request control as part of identity governance, not as an optional network hardening layer.

Redirect-hop validation should be treated as a named control gap: redirect-trust drift. The flaw exists because the security decision is made once, but the actual destination changes later in the request lifecycle. This pattern is common in systems that rely on library defaults and assume the first URL check is sufficient. For AI platforms and other workload services, the practical conclusion is that URL allowlisting without hop-by-hop enforcement is a false boundary.

Cloud metadata exposure remains one of the fastest routes from SSRF to privilege expansion. If an attacker can reach instance metadata, they often move from request control to identity control in a single step. That is why network egress, instance profile scoping, and metadata endpoint protection belong in the same control discussion as secrets management and service account governance. Teams should align this risk to least privilege and workload boundary design.

Open-source disclosure latency is now part of the operational risk surface. The article’s 36-day maintainer silence shows how long a known flaw can sit in circulation before remediation becomes visible to defenders. That does not change the exploit mechanics, but it does change patch prioritisation and exposure management for teams running open-source AI services. Practitioners should assume that unmaintained disclosure channels can extend the vulnerable window.

AI service sprawl increases the chance that one fetch path becomes a shared trust assumption. As more model gateways, multimodal endpoints, and tool-integrated inference servers appear, the same redirect and fetch logic is reused across environments. That creates a broader class of hidden SSRF exposure points than teams usually inventory. Security owners should look for shared HTTP client defaults, not just individual CVEs, when they assess AI platform risk.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Service accounts and API keys remain deeply overexposed in enterprise environments, which is why workload identity abuse can turn a single SSRF flaw into a cloud compromise.
• For related guidance: Ultimate Guide to NHIs explains the visibility, rotation, and offboarding gaps that make these exposures harder to contain.

What this signals

Redirect-safe fetch control is becoming a core AI platform requirement. Teams should assume that any service able to retrieve remote media can also be turned into a proxy if redirects, metadata access, or private-range requests are not blocked. That makes outbound request policy part of the workload identity perimeter, not just an application coding concern. The practical signal is to review AI-serving paths with the same scrutiny used for privileged automation and NHI governance, then align them with the MITRE ATT&CK Enterprise Matrix and NIST SP 800-53 Rev 5 Security and Privacy Controls.

Redirect-trust drift: this is the control gap where a request is approved once but allowed to change destination later in the chain. It is a useful shorthand for AI infrastructure teams because it captures why single-point allowlists fail under real HTTP behavior. If a service can fetch from the internet, assume it can be guided toward internal identity assets unless egress policy and hop validation are explicit.

The operational takeaway is that AI platforms need the same secrets discipline applied to any privileged workload. If an endpoint can reach metadata or internal APIs, its permissions, network reach, and observability should be reviewed as a single control set. That posture is especially important where model-serving systems are deployed quickly and inherited from open-source defaults without a dedicated identity review.

For practitioners

• Block metadata and private-range egress from AI runtimes Enforce outbound filtering for 169.254.169.254, loopback, and private IP ranges at the network layer so a redirect cannot reach identity-bearing services even if the application fails open.
• Disable automatic redirect following on untrusted fetches Configure image, document, and retrieval loaders to reject redirect chains unless every hop is revalidated against the same security policy, especially in OpenAI-compatible endpoints.
• Reduce workload privilege for inference services Strip unnecessary IAM permissions from model-serving identities and separate fetch-only components from components that can access metadata, secrets, or internal APIs.
• Inventory AI endpoints that fetch remote content Find every service that accepts user-controlled URLs or media references, then classify them as SSRF-sensitive and place them under the same controls used for other privileged workloads.
• Track disclosure age as an exposure signal Prioritise open-source findings that have sat unresolved for weeks, because maintainer silence can mean the vulnerable path remains present across deployed versions and forks.

Key takeaways

• LMDeploy SSRF shows how a single redirect-handling flaw can convert an AI inference server into an internal proxy and credential exposure path.
• Cloud metadata access is the critical escalation point because it turns request abuse into workload identity theft and broader lateral risk.
• The limiting controls are hop-by-hop URL validation, egress filtering, and tight scoping of the AI service’s IAM permissions.

Key terms

• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Cloud metadata endpoint: A cloud metadata endpoint is a local service that exposes instance details and, in some environments, temporary credentials to workloads running on that instance. It is highly sensitive because SSRF can sometimes reach it from within the application and extract information meant only for trusted code.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Redirect Hop Validation: Redirect hop validation is the practice of re-checking a request after every HTTP redirect before allowing it to proceed. It prevents attackers from using a safe first URL to reach unsafe internal destinations through chained redirects.

What's in the full analysis

OXSecurity's full article covers the exploit mechanics this post intentionally leaves for the source:

• The exact redirect sequence used to bypass the initial URL safety check.
• The verified proof-of-concept behavior against the latest release version.
• The patch behavior in PR #4734 and the hop-by-hop rejection result.
• The disclosure timeline showing the 36-day maintainer silence before public release.

👉 OXSecurity's full post covers the redirect chain, metadata exposure path, and fix behavior.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the broader security programmes that run their platforms.