CVE-2026-70659 in stable-diffusion.cpp
Summary
by MITRE • 11/05/2026
stable-diffusion.cpp is a pure C/C++ library for running diffusion model (Stable Diffusion, Flux, Wan, Qwen Image, Z-Image, and more) inference. From master-742-1a13107 until master-763-4fcc6fe, IMatrixCollector::load_imatrix in src/runtime/imatrix.cpp reuses the values and counts vectors for entries with the same tensor name but resizes them only when they are empty. An untrusted .imatrix file can provide a small nval for the first entry and a larger nval for a second entry with the same name, causing the accumulation loop to write attacker-controlled floating-point and integer values beyond both heap buffers. Loading the file through the --imat-in conversion path can corrupt the heap or crash the process before a model is required. This issue is fixed in master-763-4fcc6fe.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability resides within stable-diffusion.cpp, a widely adopted pure C and C++ library designed to facilitate inference for various diffusion models including Stable Diffusion, Flux, Wan, Qwen Image, and Z-Image. Specifically, the flaw is located in the IMatrixCollector::load_imatrix function found in src/runtime/imatrix.cpp. This component is responsible for handling imatrix files, which are used to store calibration data or matrix statistics essential for optimizing model performance during inference. The vulnerability affects versions ranging from master commit 742-1a13107 up to and including master commit 763-4fcc6fe.
The technical root cause of this issue is an improper validation of vector resizing logic when processing entries with identical tensor names within the imatrix file structure. The implementation reuses existing values and counts vectors for subsequent entries that share the same name as a previous entry, but it only resizes these buffers if they are currently empty. This design assumes that all entries with the same tensor name will have consistent dimensions or sizes. However, an attacker can craft a malicious .imatrix file where the first entry specifies a small number of values (nval), while a subsequent entry with the identical tensor name specifies a significantly larger nval. Because the buffer was not resized due to being non-empty from the initial load, it retains its smaller capacity.
When the accumulation loop processes these entries, it attempts to write the attacker-controlled floating-point and integer data corresponding to the second, larger entry into the undersized heap buffers allocated for the first entry. This results in a classic out-of-bounds write condition. Since the memory allocation is managed on the heap, writing beyond the buffer boundaries corrupts adjacent heap metadata or other critical data structures stored nearby. This corruption can lead to severe operational impacts, including process crashes due to segmentation faults or more sophisticated exploitation vectors such as arbitrary code execution if the attacker can precisely control the overwritten memory regions and trigger specific allocator behaviors.
The attack vector is particularly concerning because it leverages the --imat-in conversion path, which allows users to load external imatrix files for model optimization. An untrusted actor could distribute a maliciously crafted .imatrix file disguised as legitimate calibration data. If a victim loads this file through the specified command-line interface, the vulnerability can be triggered immediately during the loading phase, potentially crashing the application or corrupting memory before any actual model inference is even required. This lowers the barrier for exploitation compared to vulnerabilities that require complex state transitions or specific model configurations.
From a classification perspective, this flaw aligns with CWE-787: Out-of-bounds Write and CWE-120: Buffer Copy without Checking Size of Input in C/C++. The lack of bounds checking when resizing buffers based on external input is a fundamental security anti-pattern. In the context of the MITRE ATT&CK framework, this vulnerability facilitates initial access or execution phases by allowing an attacker to crash services (Denial of Service) or potentially achieve code execution through heap exploitation techniques such as heap spraying or metadata corruption.
Mitigation strategies primarily involve upgrading stable-diffusion.cpp to version master-763-4fcc6fe or later, where the resizing logic has been corrected to properly handle varying sizes for entries with duplicate tensor names. For environments unable to upgrade immediately, strict input validation should be implemented at any proxying layer that handles imatrix files, ensuring that all entries conform to expected size constraints relative to previously seen data. Additionally, enabling heap protection mechanisms such as AddressSanitizer during development and testing phases can help detect similar out-of-bounds writes in other components of the codebase before they reach production deployments.