Act nowDisclosed

Advisory · CVE-2026-103040

Unauthenticated RCE in LightLLM via router profiler RPyC service

LightLLM through 1.2.0 exposes an unauthenticated RPyC server with pickle deserialization in the router profiler service when started with --enable_profiling, letting attackers execute arbitrary code by sending crafted serialized objects.

Vendor
ModelTC
Product
LightLLM
Identifier / CWE
CVE-2026-103040
CWE-502
Action timing
Immediate
ELI5

Explain it like I’m five

When LightLLM's profiler is switched on, it opens a side door that accepts mystery boxes and opens them without checking. An attacker mails a box that pops into shell commands the moment it is opened.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Profiling enabled

    The LightLLM server is started with the --enable_profiling flag, which starts the router profiler service.

  2. 02RPyC server exposed

    The profiler service listens on an unauthenticated RPyC server with Python pickle deserialization turned on.

  3. 03Crafted object sent

    A remote attacker sends a crafted serialized object into the profiler command queue.

  4. 04Pickle executes payload

    Deserialization runs the attacker's code with the privileges of the LightLLM server process.

What happened

LightLLM through 1.2.0 contains a remote code execution vulnerability in the router profiler service, which is started when the server runs with the --enable_profiling flag. The service exposes an unauthenticated RPyC server with pickle deserialization enabled. An attacker who can reach the service sends crafted serialized objects to the profiler command queue, and deserialization executes arbitrary code with the privileges of the LightLLM server.

No patch release is documented in the disclosure at the time of writing; the advisory states only that LightLLM through 1.2.0 is affected.

What to do

  1. Inventory LightLLM deployments and identify any started with the --enable_profiling flag.
  2. Stop running with --enable_profiling until a fixed release is published, or shut down affected profiling instances.
  3. Restrict network access to LightLLM services so they are not reachable from untrusted networks; RPyC traffic should never be Internet-facing.
  4. Upgrade to a fixed LightLLM release as soon as the vendor publishes one.
  5. Review host logs and GPU worker activity on exposed instances for signs of unexpected process execution.

Management note

This is an unauthenticated, network-reachable path to full code execution on LLM serving infrastructure, in the exact tier of systems that holds model weights and inference logs. Disabling the profiling feature and cutting network exposure are immediate, complete mitigations while waiting for a vendor fix.