How a 302 redirect bypass in LMDeploy turns an AI inference server into an internal proxy — and why 36 days of maintainer silence is a warning sign
Overview
lmdeploy’s OpenAI-compatible API server (≤ 0.14.0) validates the initial image_url host but then follows HTTP redirects without re-checking each hop. An unauthenticated attacker can host a public URL that passes the safety guard, then returns a 302 pointing at 127.0.0.1 or the cloud metadata endpoint (169.254.169.254). The server follows it inward, exposing internal services and IAM credentials.
The fix merged to main via PR #4734, but no tagged/versioned release includes it.
Affected Versions
| Affected Product | Versions | Patched Version |
| InternLM LMDeploy | <= 0.14.0 | NoneFixed on main in PR #4734 |
Vulnerability Details
CVE: CVE-2026-63764
CWE: CWE-918: Server-Side Request Forgery (SSRF)
CVSS Source: GHSA
CVSS Base score: 9.2
CVSS Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:H/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Description: lmdeploy’s OpenAI-compatible API server contains a server-side request forgery vulnerability that allows unauthenticated attackers to access internal services and cloud metadata endpoints by supplying a crafted image_url that redirects to internal targets. Attackers can send a POST request to the chat completions endpoint with an image_url pointing to an attacker-controlled server that responds with an HTTP 302 redirect to internal addresses such as loopback or instance-metadata endpoints, bypassing the initial URL safety check because redirects are followed without re-validating each hop through the safety guard.
Timeline
- Reported by George Chen (geo-chen) on June 12, 2026 via GHSA
- Disclosed publicly on GitHub on Jul 18, 2026 after the GHSA remained unanswered
- Fix added on GitHub’s main branch on Jul 20, 2026 – version not yet released
Impact Breakdown:
- Cloud Credential Theft: A crafted `image_url` redirects the server to the cloud metadata endpoint (169.254.169.254), exposing IAM tokens and instance credentials.
- Internal Network Pivot: The server can be coerced into reaching internal-only services (loopback, private ranges, admin panels), using the trusted host as a proxy behind the perimeter.
- Zero-Click, Unauthenticated Bypass: No login or victim interaction is needed – the guard passes the attacker’s public host and then follows the 302 redirect inward automatically.
Recommended Actions
- Immediate Mitigation: Implement strict egress network filtering immediately to block outbound requests to private IP ranges and cloud metadata endpoints (169.254.169.254) until a patch can be deployed.
Technical Analysis
Root Cause
LMDeploy is a toolkit for compressing, deploying, and serving LLMs. It exposes models through an HTTP API – including an OpenAI-compatible server – and, for vision models, fetches remote content such as images over HTTP on the server side. Because an inference server like this typically runs inside a trusted production or cloud environment, a flaw that lets an attacker steer its outbound requests can reach far beyond the model itself, exposing internal-only services and cloud credentials such as IAM tokens.
The HTTP media loader in connection.py validates only the initial URL and then lets `requests` follow redirects automatically. In the latest release v0.14.0:
The function _is_safe_url() resolves the host and blocks any non-globally-routable IP (loopback, private, link-local, metadata), but with `allow_redirects=True`, an attacker-controlled public host – which passes the guard – can return a `302` redirect to `127.0.0.1` or the cloud metadata address `169.254.169.254`.
The guard is never consulted on the redirect target, so the internal request goes through. Reachable unauthenticated via `image_url` on `/v1/chat/completions`.
Impact:
- An unauthenticated attacker can make the server issue requests to internal-only addresses, including the cloud metadata endpoint (`169.254.169.254`), by supplying a crafted `image_url` that redirects inward.
- This can expose internal services and cloud credentials/IAM tokens, enabling further lateral movement or privilege escalation in the hosting environment.
- No authentication and no user interaction are required, and any deployment that exposes the OpenAI-compatible vision endpoint to untrusted input is affected.
The OX Research team verified this exploitation locally on the latest release version v0.14.0.
The Fix
The patch was implemented in PR #4734 which stops auto-following redirects and re-validates every hop:
The OX Research team verified it locally and on `main` the redirect hop is rejected with:
URL is blocked for security reasons: Blocked non-global IP detected: 127.0.0.1
Conclusion
The LMDeploy SSRF vulnerability raises critical concerns not just from a technical standpoint, but because it highlights a growing friction in open-source vulnerability management: uncoordinated public disclosure following maintainer silence.
You can see how the issue was reported publicly after the GHSA remained closed.
From the vulnerability’s GitHub page, we can see that geo-chen reported this bug 36 days before publicly disclosing it, after he didn’t receive any response from the maintainers.
We previously documented this trend in our paper, One Step Away From a Massive Data Breach: What We Found Inside MoltBot,, and the pattern continues to grow.
A standard security disclosure process typically gives a vendor 30 to 90 days from the disclosure date to patch, and the disclosure stays private until the maintainer decides otherwise. Some disclosures stay private well past 90 days for several reasons:
- A maintainer wants to coordinate a patch with a specific version release.
- The vulnerability affects a large number of organizations that need time to patch.
- The maintainer knows other projects share the same flaw and needs to coordinate across maintainers and organizations.
Publicly disclosing a vulnerability with a proof of concept isn’t just poor practice. It’s a warning to defenders: keep watching the open-source projects and services running inside your infrastructure.
It’s also a red flag to maintainers working on widely used projects — ignoring a security disclosure for 30+ days is simply unacceptable.
