CVE-2026-115922 in ONNX
Summary
by MITRE • 10/26/2026
Open Neural Network Exchange (ONNX) is an open standard for machine learning interoperability. Prior to 1.22.0, _unpack_2bit() and _unpack_4bit() resize unpacked arrays according to attacker-controlled TensorProto.dims without verifying that raw_data or int32_data encodes the declared number of elements. Materializing an untrusted UINT2, INT2, UINT4, INT4, or FLOAT4E2M1 tensor through onnx.numpy_helper.to_array() or onnx.reference.ReferenceEvaluator can therefore expand a small packed payload into a disproportionately large allocation and exhaust memory. This issue is fixed in version 1.22.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The Open Neural Network Exchange, commonly known as ONNX, serves as a critical open standard designed to facilitate interoperability among various machine learning frameworks by providing a unified format for model representation. Within this ecosystem, the efficient handling of tensor data is paramount, particularly when dealing with quantized or compressed formats that reduce memory footprint and computational overhead. The vulnerability identified in versions prior to 1.22.0 resides within the core parsing logic responsible for unpacking low-bit-width integer types, specifically targeting functions such as _unpack_2bit() and _unpack_4bit(). These internal routines are tasked with converting packed binary data into standard array formats that can be utilized by downstream machine learning operations or converted via utilities like onnx.numpy_helper.to_array() and the ReferenceEvaluator.
The fundamental technical flaw is a lack of input validation regarding the consistency between declared dimensions and actual encoded data size. When an attacker constructs a malicious TensorProto, they can specify arbitrary values in the dims field to define the shape of the tensor after unpacking. However, the parsing functions fail to verify that the raw_data or int32_data fields actually contain enough bytes to support the number of elements implied by those dimensions. This discrepancy allows for a scenario where a minimal amount of packed data is interpreted as representing a vastly larger array of individual elements. Because the system trusts the dimensional metadata without cross-referencing it against the actual payload size, it proceeds with memory allocation based on the inflated dimension count rather than the physical constraints of the input file.
This architectural oversight leads directly to a severe resource exhaustion vulnerability, often categorized under CWE-789 as an Out-of-bounds Allocation or CWE-400 for Uncontrolled Resource Consumption. By exploiting this logic error, an attacker can trigger a disproportionate memory expansion where a small, easily transmissible payload results in the allocation of gigabytes or terabytes of system memory depending on the specified dimensions and data type width. This behavior effectively constitutes a Denial of Service attack against any service that processes untrusted ONNX models, such as model serving endpoints, inference engines, or automated pipeline systems that ingest external model files without rigorous sanitization. The impact is particularly acute in cloud-native environments where resource limits may be bypassed through rapid memory exhaustion before defensive mechanisms can intervene.
The vulnerability affects the handling of specific low-precision data types including UINT2, INT2, UINT4, INT4, and FLOAT4E2M1 formats. These quantized representations are increasingly common in edge computing and mobile inference scenarios due to their efficiency, making this flaw relevant for a wide range of production deployments. The attack vector typically involves submitting a crafted ONNX model file through an API or interface that accepts external inputs without sufficient validation at the ingestion layer. Once parsed by vulnerable versions of the library, the internal unpacking routines allocate memory based on the maliciously inflated dimensions, leading to system instability, application crashes, or complete service unavailability due to out-of-memory conditions.
To mitigate this risk, organizations must immediately upgrade to ONNX version 1.22.0 or later, where the parsing logic has been hardened to validate that the encoded data size matches the requirements of the declared tensor dimensions before proceeding with memory allocation. In environments where upgrading is not immediately feasible, defensive measures should include implementing strict input validation at the network perimeter to reject model files with suspiciously large dimension-to-size ratios. Additionally, deploying resource limits such as container memory constraints or process-level quotas can help contain the impact of a successful exploitation attempt by preventing any single process from consuming all available system resources. Monitoring for abnormal spikes in memory usage during model loading operations can also serve as an effective detection mechanism for this type of abuse.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1496 Resource Hijacking, specifically the sub-technique related to computational cycle or bandwidth consumption through resource exhaustion attacks. It highlights the importance of treating all external model inputs as untrusted and applying rigorous schema validation that goes beyond simple syntax checks to include semantic consistency between metadata and payload content. Security teams should audit their ML pipelines for similar assumptions about data integrity, ensuring that dimensionality constraints are strictly enforced against actual binary sizes across all supported tensor types to prevent future instances of this class of vulnerability.