/

CVE-2026-15969

Severity:

CRITICAL RISK

(9.8)

Unauthenticated RCE via Pickle (CWE-502) in SGLang API

CVE-2026-15969

Analyzed

Vulnerability type

Category:

Unsafe Deserialization

CWE:

CWE-502

Impact:

Remote Code Execution

Severity:

CRITICAL RISK

(9.8)

CVSS version:

3.1

Catch this CVE while code is being written

Detect vulnerable code directly in pull requests, so CVEs are fixed before merge.

Summary

SGLang exposes an unauthenticated remote code execution flaw in the /load_lora_adapter_from_tensors endpoint due to unsafe pickle deserialization.

By bypassing SafeUnpickler's incomplete denylist with crafted base64-encoded pickle payloads, an attacker can execute arbitrary commands on the server when the endpoint is invoked.

Affected context

This vulnerability occurs in SGLang deployments that expose the /load_lora_adapter_from_tensors functionality over a network-accessible API, especially when reachable without strong authentication or network segmentation.

It is most relevant in environments where LoRA adapter loading is performed from externally supplied, base64-encoded pickle data, and the application relies on SafeUnpickler's denylist as the primary control against malicious object deserialization.

Exploit preconditions

  • Attack surface: Network-accessible SGLang API endpoint /load_lora_adapter_from_tensors
  • Required access: Ability to send HTTP requests to the vulnerable endpoint; no authentication required in typical misconfigurations
  • Trigger point: Server-side deserialization of attacker-controlled base64-encoded pickle data during LoRA adapter loading
  • Why exploitation is possible: SafeUnpickler relies on an incomplete denylist, allowing malicious object types or opcodes to slip through and execute arbitrary code during unpickling

Why this happens

The core issue is unsafe deserialization of untrusted data using Python's pickle mechanism under the assumption that SafeUnpickler fully neutralizes dangerous behaviors.

Rather than enforcing a strict allowlist of benign, data-only types, the implementation depends on a partial denylist, leaving exploitable gaps where crafted payloads can still trigger object construction or special methods that run code on deserialization.

This maps directly to CWE-502: Unsafe Deserialization, where attacker-controlled serialized data is treated as trusted input and processed by powerful deserialization routines that can instantiate and execute logic.

Potential impact

  • Remote execution of arbitrary OS commands on the SGLang host
  • Full compromise of the application runtime and underlying server
  • Exfiltration or corruption of model weights and configuration data
  • Lateral movement within the hosting environment or internal network
  • Manipulation of inference behavior, data poisoning, or supply-chain style attacks via tampered adapters

General mitigation guidance

Effective mitigation focuses on removing unsafe deserialization paths and reducing trust in external adapter inputs.

Recommended patterns include:

  • Avoid using pickle (or equivalent code-capable formats) for data received over network interfaces; prefer data-only encodings such as JSON or well-defined binary schemas.
  • Replace denylist-based unpickling with a strict allowlist model that only permits simple, immutable data structures required for the feature.
  • Enforce strong authentication and authorization for any endpoint that loads or modifies model-related artifacts.
  • Run the SGLang process with least privilege and hardened OS-level controls (sandboxing, isolation) so that unexpected code execution is constrained.
  • Treat adapter and model payloads as untrusted input, applying validation or transformation before using them to affect runtime behavior.

How teams detect issues like this

Detection typically relies on a combination of code-level and operational signals:

  • Static analysis rules that flag use of pickle and custom unpicklers on data originating from HTTP requests or other external channels.
  • Code review practices that scrutinize deserialization logic, checking for denylist-based safety rather than strict type allowlists.
  • Application-layer monitoring for unusual calls to adapter-loading endpoints, including anomalous payload sizes or patterns.
  • Runtime security tools that detect suspicious subprocess creation, file operations, or network activity originating from deserialization routines.
  • Policy enforcement in CI/CD that blocks introduction of new unsafe deserialization mechanisms or unreviewed security wrappers around pickle.

Sources

SourceLink
github.comgithub.com/sgl-project/sglang/security/advisories/GHSA-2wvm-gjg7-5jfm
thoughts.apoorvdayal.comthoughts.apoorvdayal.com/posts/sglang-disclosures/

Frequently asked

questions

Yes. When the /load_lora_adapter_from_tensors endpoint is exposed over the network without adequate access controls, an attacker can send crafted base64-encoded pickle payloads to trigger remote code execution.

The attacker generally needs only the ability to reach the vulnerable endpoint. If the API is unauthenticated or accessible from the public internet, no prior credentials or local access are required.

The safest pattern is to completely avoid pickle-based deserialization of untrusted data and implement a strict, data-only serialization format with explicit type allowlists. Additionally, ensure that all adapter-loading or model-management endpoints are authenticated and authorized.

Architect APIs so that they never accept code-capable serialization formats from clients, enforce strong authentication on sensitive endpoints, and adopt secure-by-default patterns like strict schema validation and least-privilege execution. Combine these with automated checks in development pipelines to catch unsafe deserialization early.

Find out what's already
exploitable in your codebase.