AI Threat AlertCVE-2026-70660: stable-diffusion.cpp: OOB read via crafted safetensors
AWAITING NVDstable-diffusion.cpp, a C/C++ library for running Stable Diffusion, Flux and similar diffusion models, trusts the tensor offsets declared in a .safetensors file without checking them against the real file size. A crafted model file can make the loader read adjacent process memory into tensor buffers or crash the process (CWE-125). Risk is moderate: there is no CVSS or EPSS score yet, no KEV listing, no public exploit and no Nuclei template, and exploitation needs a victim to load an attacker-supplied model. Teams that pull community models from Hugging Face, Civitai or user uploads should care most, because the model file is the attack vector. Upgrade to master-764-e22272e or later, and only load models from trusted, hash-verified sources until you have patched.
What is the risk?
Medium. The attacker must get a malicious .safetensors file loaded, so this is local or user-interaction exploitation of the model-loading path, not remote unauthenticated access. No exploitation is known: EPSS is not available, the CVE is not in CISA KEV, and no public exploit or scanner template exists. Impact is a crash (availability) and possible disclosure of process memory into tensor buffers. Disclosure only matters if those buffers can later be observed, for example through generated outputs. Exposure rises sharply for services that accept user-uploaded models, LoRAs or checkpoints. Package risk score is 0/100, and no dependents or scorecard data are available, so blast radius is Unknown.
How does the attack unfold?
How severe is it?
What should I do?
1 step1) Upgrade to master-764-e22272e or later (commit e22272e, PR #1754, GHSA-v2m4-h57v-fr6w). 2) Until patched, load only models from trusted publishers and verify SHA-256 hashes. 3) Do not let untrusted users upload or select arbitrary model files or LoRAs in hosted services. 4) Validate safetensors headers before loading, checking that every data_offsets end is within the file size. 5) Run inference in sandboxed, least-privilege containers with memory and restart limits, and keep secrets out of the inference process. 6) Monitor for repeated crashes or segfaults at model-load time, and inventory where stable-diffusion.cpp is embedded or vendored.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-70660?
stable-diffusion.cpp, a C/C++ library for running Stable Diffusion, Flux and similar diffusion models, trusts the tensor offsets declared in a .safetensors file without checking them against the real file size. A crafted model file can make the loader read adjacent process memory into tensor buffers or crash the process (CWE-125). Risk is moderate: there is no CVSS or EPSS score yet, no KEV listing, no public exploit and no Nuclei template, and exploitation needs a victim to load an attacker-supplied model. Teams that pull community models from Hugging Face, Civitai or user uploads should care most, because the model file is the attack vector. Upgrade to master-764-e22272e or later, and only load models from trusted, hash-verified sources until you have patched.
Is CVE-2026-70660 actively exploited?
No confirmed active exploitation of CVE-2026-70660 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-70660?
1) Upgrade to master-764-e22272e or later (commit e22272e, PR #1754, GHSA-v2m4-h57v-fr6w). 2) Until patched, load only models from trusted publishers and verify SHA-256 hashes. 3) Do not let untrusted users upload or select arbitrary model files or LoRAs in hosted services. 4) Validate safetensors headers before loading, checking that every data_offsets end is within the file size. 5) Run inference in sandboxed, least-privilege containers with memory and restart limits, and keep secrets out of the inference process. 6) Monitor for repeated crashes or segfaults at model-load time, and inventory where stable-diffusion.cpp is embedded or vendored.
What systems are affected by CVE-2026-70660?
This vulnerability affects the following AI/ML architecture patterns: Model serving, Local inference engines, Image generation pipelines, Model loading and checkpoint handling.
What is the CVSS score for CVE-2026-70660?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.003ModelAML.T0011.000Unsafe AI ArtifactsAML.T0029Denial of AI ServiceCompliance Controls Affected
What are the technical details?
Original Advisory
stable-diffusion.cpp is a pure C/C++ library for running diffusion model (Stable Diffusion, Flux, Wan, Qwen Image, Z-Image, and more) inference. Prior to master-764-e22272e, the safetensors loader in src/model_io/safetensors_io.cpp trusts each tensor's data_offsets after checking only that nbytes equals end - begin. A crafted .safetensors file can declare a byte range beyond the file's data section, causing src/model_loader.cpp to consume an attacker-chosen length from an unchecked mapped-file offset. Loading the model can read adjacent process memory into tensor buffers or crash the process. This issue is fixed in master-764-e22272e.
Exploitation Scenario
An attacker publishes a popular-looking fine-tune or LoRA as a .safetensors file on a public model hub. The header declares a tensor with data_offsets that extend past the end of the data section. A user or an image-generation service downloads and loads it with a vulnerable stable-diffusion.cpp build. The loader reads attacker-chosen length bytes from beyond the mapped region into tensor buffers, which either crashes the process or leaves adjacent process memory in model buffers. In a shared generation service, repeated crashes cause denial of service, and leaked memory may expose data from the same process.
Weaknesses (CWE)
CWE-125 — Out-of-bounds Read: The product reads data past the end, or before the beginning, of the intended buffer.
- [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
- [Architecture and Design] Use a language that provides appropriate memory abstractions.
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2024-291210.0BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply ChainCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply ChainCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same attack type: Data LeakageCVE-2025-512010.0smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Data LeakageGHSA-vvpj-8cmc-gx3910.0picklescan: security flaw enables exploitation
Same attack type: Supply Chain