On this page (7 sections)
A critical vulnerability, CVE-2026-119706, affects InternLM LMDeploy 0.9.0 through 0.18.0. According to the GitHub Advisory Database, a remote attacker with no credentials can run operating system commands by sending pickled data to the /update_weights endpoint of the API server.
If you run LMDeploy to serve language models, especially on a host reachable from the internet or from a shared network, you should treat this as urgent. The sources we reviewed do not name a fixed version, so the safest steps right now are limiting exposure and tracking the project for a fix.
What happened
The advisory was published on October 30, 2026 and describes an unauthenticated remote code execution flaw in LMDeploy's API server. The affected range is 0.9.0 through 0.18.0. The NVD entry carries the same description, so it is a mirror of the same record rather than a separate confirmation.
Only one independent publisher covers this story so far, and the GitHub entry is marked as unreviewed. Treat the details below as the current published record, and expect them to be refined as the maintainers respond.
Technical details in plain terms
The advisory says an attacker can submit a base64-encoded, specially crafted pickle in a field called serialized_named_tensors. The server then passes it to ForkingPickler.loads, which deserializes it without validation. The resulting commands run with the privileges of the api_server process.
Pickle is Python's native object serialization format. Unlike JSON, loading a pickle can cause arbitrary code to execute, because the format can describe how to rebuild objects by calling functions. That is why loading pickle data from an untrusted source is a well-known dangerous pattern, tracked as CWE-502. The endpoint is meant for updating model weights, which is an administrative action, but the advisory states that no authentication is required to reach it.
The CVSS v4 metrics listed in the advisory are: network attack vector, low attack complexity, no attack requirements, no privileges required and no user interaction. Impact on confidentiality, integrity and availability of the vulnerable system is rated high. The advisory points to the management endpoint source and the turbomind module in v0.18.0, plus an upstream issue and a pull request. We have not confirmed whether that pull request is the fix, so check its status yourself.
Who is realistically exposed
- Teams running the LMDeploy api_server (the OpenAI-compatible serving mode) on a cloud VM, GPU box or container.
- Deployments where the port is published to the internet, or reachable from a broad internal network, VPN or shared cluster.
- Setups with no reverse proxy, API gateway or firewall rule in front of the server.
- Development and demo instances that were started quickly and never locked down.
Because code runs as the api_server process, the damage depends on that process's rights. A server that holds model files, API keys, cloud credentials or access to internal networks gives an attacker a lot to work with. Running as root or with broad cloud permissions makes it worse.
How to check your exposure
First, find out whether LMDeploy is installed and which version. This read-only command lists the installed package version in the Python environment where you run it. A result between 0.9.0 and 0.18.0 means you are in the affected range.
pip show lmdeployNext, confirm whether the server is listening and on which address. This standard command lists listening TCP sockets with the owning process. Look for the api_server port bound to 0.0.0.0 or a public interface rather than 127.0.0.1.
sudo ss -tlnpFinally, check from a machine outside your network whether that port answers at all. If it does, assume anyone on the internet can reach the endpoint.
What to do now
Because no fixed version is named in the sources, focus on removing network access and watching for an upstream release.
0 of 8 done
Detection and monitoring
No indicators of compromise are published in the sources, so detection relies on general signals. If you log HTTP requests, this search lists any requests to the vulnerable path in a log file. Replace the path with your own proxy or application log location. Requests from unknown addresses deserve a closer look.
grep "/update_weights" /var/log/nginx/access.log- Unexpected child processes spawned by the api_server process, such as shells or download tools.
- Outbound connections from the model server to unfamiliar hosts.
- New files, cron entries or SSH keys on the host.
- Unusual GPU or CPU load not tied to your own workloads.
For public-facing sites and servers, a regular outside-in check helps you notice unintended open ports and services. Webforta Scan runs read-only scans of sites you verify, and Webforta Monitor tracks uptime, certificate and DNS changes. Neither is a substitute for patching or for restricting access to the LMDeploy server itself.
Status and what is still unknown
| Question | Current answer |
|---|---|
| Affected versions | 0.9.0 through 0.18.0 |
| Patched version | Not stated; listed as unknown in the GitHub advisory |
| Exploitation in the wild | Not reported in the sources |
| Public proof of concept | Not stated in the sources |
| Package listed in advisory | None |
| Independent confirmation | Limited; the NVD entry repeats the same record |
We will not guess at a fixed version. Check the project's releases and the linked issue and pull request, and confirm the fix before relying on an upgrade. For general guidance on responding if you suspect a compromise, see website hacked: what to do.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.