Two LightLLM Helper Ports Expose Code Execution on Inference Nodes
The model API is the obvious place to put authentication and network controls. Two LightLLM flaws disclosed on 29 September concern different listeners on the same inference nodes. Researchers found that an unauthenticated network peer could send a crafted object to an internal RPyC service and make the node run Python code with the LightLLM process's privileges. The reports cover LightLLM through version 1.2.0. They do not establish that anyone has exploited either flaw outside the researchers' tests.
The first path, CVE-2026-103041, is the embed-cache service used by multimodal deployments. LightLLM can enable that service automatically for vision and audio models. The second, CVE-2026-103040, is a router profiling service started when an operator enables profiling. Both reports describe a service bound to all network interfaces without authentication, with Python pickle deserialisation permitted. Each listens on a port allocated at startup, separate from the normal model API port.
That distinction is the operational point. A gateway in front of the model API does not necessarily guard these helper ports. Neither reported path requires a hostile model file, a prompt injection or a valid API token. The attacker does need network reachability to the particular RPyC listener. A node behind a correctly enforced network boundary may therefore be insulated from this route, while a node reachable by other workloads in a shared cluster may remain exposed.
Check the listeners, then the boundary
Start with an inventory of deployed LightLLM versions and model types. Flag vision and audio deployments for the embed-cache check, and find any node launched with profiling enabled. On each affected node, inspect the actual listening sockets and LightLLM startup logs rather than assuming that the documented model API port is the only ingress. Record which source networks can reach each RPyC port. The researchers reproduced both routes from a second host, so a test from another workload in the same network segment is more useful than a local-only check.
Restrict the helper listeners at the host firewall or network policy so only components that need them can connect. If profiling is not required, turn it off. For multimodal workloads, isolate the inference nodes until you can enforce and verify the port boundary. Keep the intended model API available through its normal controls, and confirm from an untrusted peer that connections to the helper ports fail. A successful health check is not a safety test: in the published reproductions, the node kept serving requests after the test payload ran.
Do not treat an unspecified upgrade as remediation. Verify the exact code and build deployed, and retain network restrictions until their effect has been tested. If an unexpected peer could already reach a helper port, investigate connection history and the permissions and secrets available to the LightLLM service account. The public reports show a route to code execution, not evidence of a breach in any particular deployment.
Update, 31 October 2026: two merged changes, with local limits
On 22 October, the project merged the embed-cache change into its main branch. It binds the cache service to 127.0.0.1, so it no longer listens on external host interfaces in that code. The final change retains pickle support and does not add authentication. Its author explicitly describes it as a mitigation: processes on the same host can still reach the service. The maintainer reports successful local connections and model requests, with non-loopback connections refused; those are the maintainer’s tests, not verification of a reader’s deployment.
The project also merged the router-profiler change on 22 October. Its final merged diff binds that listener to loopback and checks that a command is start or stop before it enters the queue. The proposal originally described disabling pickle, but the final merged version retains allow_pickle: True. It should therefore be described as local binding and command validation, not as removal of pickle deserialisation. The profiler issue remains open despite this merged work; the embed-cache issue is closed.
The project’s release index still marks the 10 August 1.2.0 release as latest. A merged change does not establish a newly published fixed release, its inclusion in a third-party package or its presence in a running node. Check the exact build and both live listeners. Continue to separate untrusted workloads at the host or network-namespace boundary, because loopback binding does not protect against another process with access to the same local endpoint. The original reachability, health-check and investigation guidance above still applies.
