Safeguard
Vulnerability Analysis•

CVE-2026-111160: High Unauthenticated DoS in LightLLM

CVE-2026-111160 lets one unauthenticated request crash a LightLLM 1.2.0 or earlier inference worker. No fix is confirmed; block the field at your gateway.

Safeguard Security Team
4 min read

CVE-2026-111160 is a High severity (CVSS 7.5) denial of service in LightLLM through 1.2.0. A single request to the generate endpoint can kill the inference worker while the health check keeps passing. We could not confirm a fixed version, so filter requests at a gateway.

What's affected

The record says LightLLM through 1.2.0 is affected. VulnCheck gives the same range. The project's issue number 1629 is linked as the report. Neither the issue nor VulnCheck names a fixed release, so we do not state one. Check the ModelTC/LightLLM releases.

The weakness is CWE-502, deserialization of untrusted data. Per the record, an internal field named pd_kv_trans_params can be supplied by an outside caller to the generate endpoint. The value is later passed to pickle.loads inside InferSamplingParams. When it fails, the inference thread dies. The HTTP server and the health endpoint stay up, so the service looks healthy while every later request hangs until a restart.

Severity differs by source. The record gives 7.5 (High). VulnCheck lists 8.7 on a CVSS 4.0 vector. The record describes a denial of service only, with no code execution claim.

How to check if you're exposed

Check the version.

pip show lightllm

If it is 1.2.0 or lower, you are in range. Then check who can reach the generate endpoint. A server bound to an internal network behind an authenticating gateway is much safer than one on a public address.

Because the health check keeps passing, a normal liveness probe will not catch this. Test with a request that should return a result, and alert when responses stop while the process is still up. Check logs for an inference thread exception followed by silence. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.

What to do now

  1. Do not expose the LightLLM server directly. Put an authenticating gateway in front of it.
  2. At the gateway, drop or reject requests that contain the pd_kv_trans_params field, since it is an internal parameter.
  3. Add a readiness probe that runs a tiny real inference, so a dead worker with a live HTTP server is detected and restarted.
  4. Check the ModelTC/LightLLM repository for a fix and upgrade once you have confirmed which release includes it.
  5. Set request timeouts at the gateway so clients do not hang indefinitely.

Why it matters

Pickle is a format that can run code when it is loaded, which is why loading it from user influenced data is a long standing warning in Python security guidance. Here the record describes a crash, not code execution, but the design choice is the same: an internal field is reachable from the public API.

There is also an operations lesson. A health check that only proves the web server is alive will hide a dead worker. For model servers, health should mean that the worker can complete a request. The record does not mark this CVE as known exploited, and none of the pages we read say it is.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Does this give code execution?

The record describes denial of service only: the inference worker dies and later requests hang.

Why does the health check still pass?

According to the record, the health endpoint keeps answering while the inference thread is dead, so it does not reflect real readiness.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.