CVE-2026-15976: SGLang: RCE via unsafe pickle deserialization on weight load
AWAITING NVDSGLang'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.
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?
How severe is it?
What should I do?
1 step-
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:
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
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
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.
References
Timeline
Related Vulnerabilities
CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply Chain CVE-2024-2912 10.0 BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply Chain CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same attack type: Supply Chain CVE-2025-5120 10.0 smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Supply Chain CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same attack type: Code Execution