CVE-2026-15976: SGLang: RCE via unsafe pickle deserialization on weight load

AWAITING NVD
Published July 30, 2026
CISO Take

SGLang's /update_weights_from_disk endpoint loads model weight files with torch.load(..., weights_only=False), which silently falls back to full pickle deserialization instead of the safe tensor-only path — meaning any .bin file loaded from a HuggingFace repo can execute arbitrary Python code on the inference server. No CVSS, EPSS, or KEV data has been published yet and there's no public exploit or scanner template, but this is a textbook, well-understood pickle RCE pattern in the exact spot AI teams least expect it: a routine model-refresh call. Because SGLang is a production-grade LLM inference engine (a common vLLM alternative), any deployment that dynamically reloads weights from disk or a remote repo — common in continuous fine-tuning, RLHF weight-sync loops, or multi-tenant model hosting — is a direct RCE target if that source isn't fully trusted. Patch to the fixed SGLang release referenced in GHSA-wf98-gv64-5wrf immediately, and until confirmed patched, lock down or disable the /update_weights_from_disk endpoint and restrict weight sources to a signed, internally-controlled registry rather than arbitrary HuggingFace repos. Detection-wise, alert on any torch.load call path resolving weights_only=False and audit which HF repos your serving fleet is configured to pull from.

Sources: GitHub Advisory thoughts.apoorvdayal.com ATLAS

What is the risk?

This is a critical-class vulnerability by exploitation mechanics (unauthenticated or low-friction pickle deserialization leading to arbitrary code execution), even though no CVSS/EPSS score is published yet and there is no known public exploit or Nuclei template. Real-world risk hinges entirely on exposure: if the /update_weights_from_disk endpoint is reachable by untrusted callers, or if the weight source path can point to attacker-influenced HuggingFace repos, exploitation is straightforward for anyone familiar with pickle-based Python RCE techniques. Organizations that treat HuggingFace as an implicitly trusted source for automated weight refresh are most exposed. Absent KEV listing or in-the-wild reports, urgency should be driven by exposure of the endpoint and the exploit class (pickle deserialization), not by current threat-intel signals.

How does the attack unfold?

Stage malicious weights
Adversary publishes or compromises a HuggingFace repository hosting a .bin weight file with an embedded pickle payload.
AML.T0058
Trigger weight reload
Victim's SGLang deployment calls /update_weights_from_disk pointing at the malicious repository or path as part of a routine or automated weight refresh.
AML.T0011.000
Unsafe deserialization
torch.load(..., weights_only=False) deserializes the .bin file, executing the embedded pickle payload as arbitrary code on the inference server.
AML.T0018.002
Host compromise
Adversary gains code execution on the GPU inference host, enabling data exfiltration, lateral movement, or further tampering with the serving pipeline.
AML.T0025

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

1 step
  1. 1) Upgrade SGLang to the version that fixes GHSA-wf98-gv64-5wrf as soon as it's confirmed available. 2) Until patched, disable or network-restrict the /update_weights_from_disk endpoint so only trusted internal callers can invoke it. 3) Only load weights from repos/paths you control and have integrity-verified — never point weight-reload paths at arbitrary or user-supplied HuggingFace repo names. 4) Prefer safetensors-format weights over pickle-based .bin files wherever the model supports it, since safetensors avoids arbitrary deserialization entirely. 5) If you must use torch.load on untrusted files, never pass weights_only=False; audit your fork/deployment for this exact call pattern. 6) Monitor inference-server processes for unexpected child processes or outbound connections immediately following a weight-reload event as a detection signal.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.4 - AI system security controls throughout the lifecycle
NIST AI RMF
MANAGE 2.3 - Mechanisms are in place to supersede, disengage, or deactivate AI systems with risks that exceed acceptable thresholds
OWASP LLM Top 10
LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-15976?

SGLang's /update_weights_from_disk endpoint loads model weight files with torch.load(..., weights_only=False), which silently falls back to full pickle deserialization instead of the safe tensor-only path — meaning any .bin file loaded from a HuggingFace repo can execute arbitrary Python code on the inference server. No CVSS, EPSS, or KEV data has been published yet and there's no public exploit or scanner template, but this is a textbook, well-understood pickle RCE pattern in the exact spot AI teams least expect it: a routine model-refresh call. Because SGLang is a production-grade LLM inference engine (a common vLLM alternative), any deployment that dynamically reloads weights from disk or a remote repo — common in continuous fine-tuning, RLHF weight-sync loops, or multi-tenant model hosting — is a direct RCE target if that source isn't fully trusted. Patch to the fixed SGLang release referenced in GHSA-wf98-gv64-5wrf immediately, and until confirmed patched, lock down or disable the /update_weights_from_disk endpoint and restrict weight sources to a signed, internally-controlled registry rather than arbitrary HuggingFace repos. Detection-wise, alert on any torch.load call path resolving weights_only=False and audit which HF repos your serving fleet is configured to pull from.

Is CVE-2026-15976 actively exploited?

No confirmed active exploitation of CVE-2026-15976 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-15976?

1) Upgrade SGLang to the version that fixes GHSA-wf98-gv64-5wrf as soon as it's confirmed available. 2) Until patched, disable or network-restrict the /update_weights_from_disk endpoint so only trusted internal callers can invoke it. 3) Only load weights from repos/paths you control and have integrity-verified — never point weight-reload paths at arbitrary or user-supplied HuggingFace repo names. 4) Prefer safetensors-format weights over pickle-based .bin files wherever the model supports it, since safetensors avoids arbitrary deserialization entirely. 5) If you must use torch.load on untrusted files, never pass weights_only=False; audit your fork/deployment for this exact call pattern. 6) Monitor inference-server processes for unexpected child processes or outbound connections immediately following a weight-reload event as a detection signal.

What systems are affected by CVE-2026-15976?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference, training pipelines.

What is the CVSS score for CVE-2026-15976?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

model servingLLM inferencetraining pipelines

MITRE ATLAS Techniques

AML.T0010.003 Model
AML.T0011.000 Unsafe AI Artifacts
AML.T0018.002 Embed Malware
AML.T0058 Publish Poisoned Models

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.4
NIST AI RMF: MANAGE 2.3
OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

SGLang contains a RCE vulnerability when attempting to load model weights from a HuggingFace repository, specifically within the /update_weights_from_disk, where torch.load(..., weights_only=False) fallback enables pickle deserialization of .bin files.

Exploitation Scenario

An adversary crafts a malicious .bin weight file containing a pickle payload (e.g., a __reduce__ method that spawns a reverse shell) and either publishes it as a lookalike/typosquat HuggingFace repo or compromises a legitimate repo the victim already trusts. The victim's SGLang deployment — as part of a routine RLHF weight-sync job, an automated retraining pipeline, or an exposed admin API — calls /update_weights_from_disk pointing at that repo. SGLang's torch.load(..., weights_only=False) fallback deserializes the file, executing the embedded payload and giving the adversary a foothold on the GPU inference host, from which they can pivot to other services, exfiltrate proprietary models, or tamper with future inference responses.

Timeline

Published
July 30, 2026
Last Modified
July 30, 2026
First Seen
July 30, 2026

Related Vulnerabilities