CVE-2026-103040: LightLLM RCE Vulnerability

CVE-2026-103040 Overview

CVE-2026-103040 is an unauthenticated remote code execution vulnerability in LightLLM through version 1.2.0. The flaw resides in the router profiler service, which is activated when the server is started with the --enable_profiling flag. LightLLM exposes an RPyC (Remote Python Call) server without authentication and accepts pickle-serialized objects on the profiler command queue. Attackers can submit crafted serialized payloads that trigger arbitrary code execution during deserialization [CWE-502]. Because LightLLM is deployed as a large language model inference server, successful exploitation grants control over GPU-backed inference infrastructure and any data or model weights accessible to the process.

Critical Impact
Unauthenticated network attackers can execute arbitrary code on LightLLM inference hosts by sending crafted pickle payloads to the exposed RPyC profiler service.

Affected Products

LightLLM versions up to and including 1.2.0
Deployments started with the --enable_profiling flag
Router profiler service component (lightllm/server/router/profiler_service.py)

Discovery Timeline

2026-09-29 - CVE-2026-103040 published to NVD
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-103040

Vulnerability Analysis

LightLLM is an open-source Python-based inference server for large language models maintained by ModelTC. When operators enable profiling, the router process starts a profiler service that listens on an RPyC endpoint. RPyC is a symmetric Python remote procedure call library that, by default, transports objects using Python's pickle module.

The profiler service accepts commands placed on an internal queue and deserializes them without any authentication, authorization, or integrity check. Any network client that can reach the profiler port can push a malicious pickle blob. Deserialization instantiates attacker-controlled objects whose __reduce__ methods execute arbitrary Python callables, giving the attacker native code execution in the LightLLM process context.

Root Cause

The root cause is insecure deserialization of untrusted data [CWE-502] combined with a missing authentication layer on the RPyC listener. The profiler service, defined around lines 32-50 of profiler_service.py in the v1.2.0 tree, exposes the RPyC classic service and pulls pickled commands off a queue for processing. Python's pickle format is not a safe transport for untrusted input, and RPyC's classic mode compounds the risk by permitting remote object access.

Attack Vector

Exploitation requires only network reachability to the profiler port. No credentials, tokens, or user interaction are needed. An attacker connects to the RPyC endpoint, submits a serialized payload containing a __reduce__ gadget that invokes os.system, subprocess.Popen, or an equivalent primitive, and the LightLLM process executes the embedded command. In production deployments, this typically yields code execution as the service account running inference, with access to model weights, prompts, cached responses, and adjacent GPU resources.

For technical details, see the VulnCheck Advisory: LightLLM RCE and the vulnerable code in the LightLLM Profiler Service source.

Detection Methods for CVE-2026-103040

Indicators of Compromise

LightLLM processes spawning unexpected child processes such as sh, bash, python, curl, or wget
Outbound network connections from the LightLLM host to unknown IPs shortly after inbound traffic on the RPyC profiler port
Presence of the --enable_profiling flag in LightLLM launch arguments on internet-exposed or broadly reachable hosts
Unexpected file writes under model cache, configuration, or /tmp directories by the LightLLM service account

Detection Strategies

Inventory all LightLLM deployments and flag any instance launched with --enable_profiling
Inspect network flows for connections to LightLLM RPyC ports originating outside trusted management subnets
Alert on Python processes belonging to LightLLM that invoke shell utilities or execute code from writable directories
Monitor for RPyC protocol traffic on non-standard ports associated with inference nodes

Monitoring Recommendations

Enable process lineage telemetry on GPU inference hosts to capture parent-child relationships from the LightLLM router process
Forward LightLLM stdout, stderr, and application logs to a centralized data lake for correlation with network events
Track command-line arguments for inference services to detect the presence of --enable_profiling in production

How to Mitigate CVE-2026-103040

Immediate Actions Required

Disable the profiler by removing the --enable_profiling flag from all LightLLM startup configurations
Restrict inbound access to LightLLM hosts using host firewalls or network security groups so only trusted management systems can reach service ports
Audit running LightLLM processes for the --enable_profiling argument and terminate exposed instances
Rotate any credentials, API keys, or model artifacts that were accessible to a potentially compromised LightLLM host

Patch Information

At the time of publication, the GitHub Issue #1597 for LightLLM tracks the vulnerable behavior and the LightLLM repository should be monitored for a fixed release beyond 1.2.0. Until a patched version is available, operators must not run LightLLM with profiling enabled on any network-reachable interface.

Workarounds

Run LightLLM without the --enable_profiling flag in all production environments
Bind the profiler service to 127.0.0.1 and require SSH tunneling for any profiling session
Place LightLLM behind an authenticating reverse proxy and block direct access to RPyC ports at the network edge
Segment inference workloads onto isolated VLANs with strict egress filtering to limit blast radius if exploitation occurs

bash

# Configuration example: launch LightLLM without the vulnerable profiler
python -m lightllm.server.api_server \
  --model_dir /models/my-llm \
  --host 0.0.0.0 \
  --port 8000
  # NOTE: do NOT pass --enable_profiling on network-reachable hosts

# If profiling is required, restrict access at the firewall (example: iptables)
iptables -A INPUT -p tcp --dport <profiler_port> -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport <profiler_port> -j DROP