/

CVE-2026-15976

Severity:

CRITICAL RISK

(9.8)

Unsafe Pickle Deserialization (CWE-502) in SGLang

CVE-2026-15976

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 contains an unsafe deserialization flaw when loading model weights from HuggingFace repositories, where a torch.load fallback path can deserialize attacker-controlled pickle data.

If an adversary can influence or replace the weight files, this condition may enable remote code execution during the /update_weights_from_disk operation.

Affected context

This issue arises in SGLang deployments that dynamically update or load model weights from disk using the /update_weights_from_disk path.

The vulnerable behavior occurs when torch.load is invoked with weights_only=False against .bin files sourced from HuggingFace or similar artifact repositories.

Environments that pull models from unverified sources, or allow modification of locally cached weight artifacts, are more exposed to this risk, especially where update endpoints are accessible or automated.

Exploit preconditions

  • Attack surface: The SGLang service endpoint or mechanism that triggers /update_weights_from_disk.
  • Required access: Ability to supply or modify model weight files (e.g., .bin) that SGLang later loads, such as via compromised repositories, poisoned artifacts, or write access to the model cache directory.
  • Trigger point: Invocation of the weight update routine that calls torch.load(..., weights_only=False) on these files.
  • Why exploitation is possible: torch.load uses pickle-based deserialization when weights_only=False, so crafted binary files can embed malicious Python objects whose constructors execute code as the weights are loaded.

Why this happens

The root cause is reliance on a general-purpose deserialization mechanism for loading model weights without constraining the input format or trust boundary.

By calling torch.load with weights_only=False, SGLang exposes a pickle-based deserialization path that treats the contents of .bin files as serialized Python objects rather than strictly structured tensors.

This maps directly to CWE-502 (Unsafe Deserialization), where untrusted or insufficiently validated data is processed by a deserializer capable of instantiating arbitrary objects, allowing embedded logic to run with the application's privileges.

Potential impact

  • Remote code execution within the SGLang process or hosting environment
  • Compromise of the underlying host machine running SGLang
  • Tampering with model behavior, responses, or embedded business logic
  • Lateral movement within the infrastructure using the compromised service
  • Data exfiltration or manipulation of sensitive configuration and secrets

General mitigation guidance

Effective mitigation focuses on narrowing deserialization behavior and reducing trust in external model artifacts.

Common defensive patterns include:

  • Avoiding pickle-capable loaders for untrusted weight files and preferring formats that represent tensors only, not arbitrary Python objects.
  • Enforcing strict validation of model weight formats and rejecting files that do not match expected non-executable schemas.
  • Separating model artifact download from loading, with integrity checks (signatures, hashes) before any deserialization step.
  • Running model-serving components with least privilege, isolated from sensitive systems, to limit the blast radius of any deserialization flaw.
  • Restricting who can modify or publish model artifacts, and treating repositories as part of the supply chain with appropriate controls.

How teams detect issues like this

Organizations can detect this class of vulnerability by:

  • Using static analysis rules to flag torch.load and other pickle-based APIs when applied to externally supplied artifacts or non-constant file paths.
  • Incorporating code review checklists that highlight deserialization of model weights, configuration, or cache files, requiring explicit justification and constraints.
  • Applying security policies that mandate non-executable formats for ML artifacts and prohibit pickle-backed serialization in runtime loading.
  • Leveraging automated application security testing tools that recognize unsafe deserialization patterns and alert on their presence in model-serving services.

Sources

SourceLink
github.comgithub.com/sgl-project/sglang/security/advisories/GHSA-wf98-gv64-5wrf
thoughts.apoorvdayal.comthoughts.apoorvdayal.com/posts/sglang-disclosures/

Frequently asked

questions

It can be, if an attacker can cause SGLang to load malicious weight files via exposed update endpoints, poisoned repositories, or automated workflows that trust external artifacts.

The attacker needs control over the model weight files SGLang loads—such as the ability to replace artifacts in a HuggingFace repository, write to the local model cache, or influence the path used by /update_weights_from_disk.

The safest pattern is to avoid pickle-backed deserialization for model weights entirely, use loaders that only handle raw tensor data, and enforce strict format and integrity checks before any artifact is loaded.

Treat model artifacts as part of the software supply chain: prohibit unsafe deserialization in loading paths, restrict artifact modification, require signature or hash verification, and include deserialization review in security and code review practices.

Find out what's already
exploitable in your codebase.