Notifications
Clear all
Topic starter
02/08/2026 9:44 am
TL;DR: LMDeploy’s OpenAI-compatible API server follows HTTP redirects after validating only the first image_url host, allowing unauthenticated attackers to pivot requests to internal services or cloud metadata endpoints and expose IAM credentials, according to OXSecurity. The flaw shows how SSRF in inference infrastructure can become an identity and network trust failure, not just an application bug.
NHIMG editorial — based on content published by OXSecurity: How a 302 redirect bypass in LMDeploy turns an AI inference server into an internal proxy
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read OXSecurity's analysis of the LMDeploy SSRF redirect bypass →
LMDeploy SSRF and metadata exposure: what IAM teams need to know?
Explore further
02/08/2026 12:37 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: LMDeploy SSRF exposes cloud metadata and internal services
