CVE-2026-33626
SSRF Vulnerability in LMDeploy Vision-Language Module Allows Internal Access
Publication date: 2026-04-20
Last updated on: 2026-04-23
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| internlm | lmdeploy | to 0.12.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | 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. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability is a Server-Side Request Forgery (SSRF) in LMDeploy versions prior to 0.12.3, specifically in the vision-language module. The function load_image() in lmdeploy/vl/utils.py fetches URLs without checking if they point to internal or private IP addresses. This allows attackers to make the server request internal resources or cloud metadata services that should not be accessible externally.
How can this vulnerability impact me? :
This vulnerability can allow attackers to access sensitive internal resources and cloud metadata services by tricking the server into making unauthorized requests. This can lead to exposure of confidential information, unauthorized access to internal networks, and potential further exploitation of internal systems.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, upgrade LMDeploy to version 0.12.3 or later, which contains the patch for the Server-Side Request Forgery (SSRF) issue in the vision-language module.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The SSRF vulnerability in LMDeploy allows attackers to access internal networks and sensitive resources, including cloud metadata services that may contain credentials. This unauthorized access and potential data exfiltration can lead to exposure of sensitive personal or organizational data.
Such exposure and unauthorized access can violate data protection regulations like GDPR and HIPAA, which require strict controls over personal and sensitive data to prevent unauthorized disclosure.
Therefore, the vulnerability poses a risk to compliance with these standards by enabling attackers to bypass network boundaries and access protected information without authorization.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
The vulnerability involves the LMDeploy toolkit fetching arbitrary URLs without validating whether they point to internal or private IP addresses, enabling SSRF attacks. Detection involves monitoring for suspicious requests to the vulnerable LMDeploy endpoints, especially those containing image URLs pointing to internal IP ranges or cloud metadata service IPs.
To detect exploitation attempts on your network or system, you can:
- Monitor HTTP requests to the LMDeploy service, particularly to the `/v1/chat/completions` endpoint, for parameters like `image_url` containing IPs in private or reserved ranges (e.g., 127.0.0.1, 10.x.x.x, 169.254.x.x, 192.168.x.x).
- Check logs for outgoing HTTP requests from LMDeploy to internal IP addresses or cloud metadata IPs such as 169.254.169.254.
- Use network monitoring tools or firewall logs to detect unexpected outbound connections from the LMDeploy server to internal or metadata IP addresses.
Suggested commands to help detect this vulnerability or its exploitation attempts include:
- Using `grep` on LMDeploy logs to find suspicious image URL requests: `grep -E 'image_url=.*(127\.0\.0\.1|10\.|169\.254\.|192\.168\.)' /path/to/lmdeploy/logs/*`
- Using `tcpdump` or `wireshark` to capture outgoing traffic from the LMDeploy server to internal IP ranges: `sudo tcpdump -i eth0 dst net 10.0.0.0/8 or dst net 192.168.0.0/16 or dst host 169.254.169.254`
- Checking active network connections from the LMDeploy process: `netstat -tunp | grep lmdeploy` or `ss -tunp | grep lmdeploy`
- Using curl or wget to test if the LMDeploy server can access internal metadata services (only on a test environment): `curl http://169.254.169.254/latest/meta-data/`
Note that the vulnerability is fixed in version 0.12.3 by adding strict URL validation and blocking requests to non-global IP addresses, so upgrading to this version is strongly recommended.