External risk intelligence

LightLLM Unauthenticated RPyC Remote Code Execution

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-103395

The vulnerability involves an RPyC service, which is typically an internal-facing component used for inter-process or distributed communication. While the service may be reachable over a network, it is not designed to be a public-facing web or API endpoint. Exposure is possible in specific distributed deployments, but public internet reachability is not a standard or intended configuration.

Deserialization

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

The LightLLM software, in certain visual-only deployments, has a critical vulnerability that could allow unauthorized access to execute arbitrary code with service account privileges. This occurs because an unauthenticated remote procedure call service within the software improperly handles serialized data, enabling attackers to exploit this weakness. The main concern is confirming if this specific type of deployment is in use and if it is exposed to potential attackers.

An unauthenticated service allows code execution.
Confirms if our visual deployments are exposed.
Assess exposure and validate configurations.

Attack Path

How an attacker could exploit the issue

An attacker can exploit this vulnerability by reaching an unauthenticated RPyC service exposed by LightLLM deployments. By sending specially crafted arguments to the `remote_infer_images` method, an attacker can trigger a deserialization flaw, leading to arbitrary code execution with the privileges of the service account.

Unauthenticated network access to RPyC port.
Calling the `remote_infer_images` method.
Arbitrary code execution with service account privileges.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow an unauthenticated attacker to execute arbitrary code on systems running vulnerable versions of LightLLM, specifically those with visual-only deployments. The attacker could achieve this by interacting with an exposed RPyC service and sending specially crafted data that exploits the deserialization of arguments. This could lead to unauthorized actions being performed with the privileges of the service account running LightLLM.

Service account privileges and system access.
Unauthenticated network access to RPyC service.
Arbitrary code execution on the service.

Operational Fix

Recommended remediation, mitigation, and detection steps

The unauthenticated RPyC service in visual-only deployments of LightLLM presents a critical risk. Teams responsible for AI/ML platforms, application development, or infrastructure managing these deployments should prioritize identifying and securing these services. The immediate first step is to locate all instances, assess their network exposure and business criticality, and then confirm the accountable owner to initiate a planned remediation.

Platform or application owners should manage this.
Verify RPyC service network exposure.
Plan remediation based on exposure risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is LightLLM?

LightLLM is a high-performance Python-based framework designed for serving Large Language Models (LLMs). It helps developers manage model inference efficiently, including specific configurations for processing visual data in multi-modal AI applications. The software organizes communication between system components using various services, including RPyC for distributed tasks.

What does CWE-502 mean for CVE-2026-103395?

CWE-502 refers to Deserialization of Untrusted Data. In this vulnerability, the software accepts data sent from a remote source and reconstructs it into an object without verifying its safety. Because the RPyC service is configured to allow 'pickle'—a mechanism that can execute code during object reconstruction—the application inadvertently runs malicious commands embedded in the data.

How is the RPyC service triggered?

An attacker triggers the vulnerability by connecting to the exposed RPyC port and calling the 'remote_infer_images' method with crafted arguments. The vulnerability does not trigger through standard web requests or API calls that do not interact with this specific visual-only RPyC service interface.

Is my LightLLM deployment at risk?

According to Halo Surface Signal, risk depends on your network architecture. This RPyC service is designed for internal communication between processes, not as a public-facing web endpoint. You are primarily at risk if your specific distributed deployment has accidentally made this internal service port reachable over an untrusted network.

What should I do first to address this?

Begin by auditing your infrastructure to locate all instances where LightLLM 'visual_only' deployments are running. Identify which systems have the RPyC service port active and verify if those ports are accessible from outside your secure internal network. Once identified, restrict access to these ports to authorized internal components only.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.