CVE-2026-115922: Denial of Service via Unchecked Expansion of Packed Sub-Byte Tensors in ONNX

Open Neural Network Exchange (onnx) is an open format and library ecosystem used to represent and exchange machine learning models across frameworks. To optimize model storage and memory bandwidth for quantized neural networks, ONNX supports sub-byte tensor data types, including 4-bit types (UINT4, INT4, FLOAT4E2M1) and 2-bit types (UINT2, INT2). Because standard byte-addressable memory cannot directly index single 2-bit or 4-bit elements, ONNX packs multiple sub-byte values into contiguous byte arrays (raw_data) or 32-bit integer arrays (int32_data) inside the TensorProto protobuf structure.

When Python applications inspect, transform, or evaluate ONNX models using APIs such as onnx.numpy_helper.to_array(), onnx.reference.ReferenceEvaluator, or onnx.reference.op_run, the library unpacks these dense bitstreams into standard 8-bit NumPy arrays (numpy.uint8) before reshaping them to the dimensions declared in TensorProto.dims. This deserialization path represents a primary attack surface for machine learning pipelines, model registries, and automated inference servers that ingest external or untrusted .onnx model artifacts.

In ONNX versions prior to 1.22.0, the unpacking routines _unpack_4bit() and _unpack_2bit() in onnx/numpy_helper.py failed to verify that the physical size of the packed data buffer was sufficient to populate the number of elements specified by TensorProto.dims. Instead, the functions performed bit extraction on the available bytes and subsequently called ndarray.resize(dims, refcheck=False) unconditionally.

Tracked as CVE-2026-115922 (GHSA-q69g-f4f5-v8m7) and classified under CWE-789 (Memory Allocation with Excessive Size Value), this flaw enables an asymmetric memory exhaustion attack. A maliciously crafted TensorProto containing a 1-byte raw_data buffer alongside a dims array specifying ratusan of millions of elements causes the Python runtime to reallocate and zero-fill gigabytes of memory in place. This unchecked allocation bypasses pre-execution validation in onnx.checker.check_model() and terminates the host process via an out-of-memory (OOM) condition.

The root cause of CVE-2026-115922 lies in the misuse of numpy.ndarray.resize() on unvalidated dimension metadata combined with missing bounds checks in both the Python helper module and the C++ model validator. In ONNX's sub-byte packing scheme, each byte in raw_data holds either two 4-bit elements (low and high nibbles) or four 2-bit elements (two-bit crumbs). Similarly, when stored in int32_data, each 32-bit integer stores 4 packed bytes, corresponding to eight 4-bit elements or sixteen 2-bit elements.

During unpacking in onnx/numpy_helper.py, _unpack_4bit() allocates an initial flat buffer result = np.empty(data.size * 2, dtype=np.uint8) and populates the even and odd indices using bitwise AND and right-shift operations. If the declared element count (np.prod(dims)) is odd, a single trailing padding nibble is stripped via result = result[:-1]. Likewise, _unpack_2bit() allocates np.empty(data.size * 4, dtype=np.uint8) and truncates excess padding elements when result.size > np.prod(dims). However, neither function checked the inverse condition: whether result.size was smaller than np.prod(dims).

Following the padding adjustment, both functions executed result.resize(dims, refcheck=False). Unlike numpy.ndarray.reshape(), which raises a ValueError if the total number of elements in the new shape does not exactly match the existing array size, ndarray.resize() modifies the array memory buffer in-place. When the target shape passed to resize() requires more elements than currently allocated, NumPy calls PyDataMem_RENEW (wrapping realloc) to expand the underlying heap buffer to the requested size and fills all newly allocated elements with zeros.

This vulnerability was compounded by two secondary issues. First, calculating total elements via np.prod(dims, dtype=np.int64) used fixed-width 64-bit integers rather than Python's arbitrary-precision integers, creating potential integer overflow edge cases with crafted multi-dimensional shapes. Second, the C++ validation logic in onnx/checker.cc (check_tensor()) contained a blind spot: for raw_data, it returned early after checking that the type was not TensorProto::STRING, performing zero length verification for sub-byte types. For int32_data, it invoked check_field(int32_data) to verify the field was non-empty, without verifying that int32_data().size() contained enough integers to satisfy the tensor element count (nelem).

The remediation for CVE-2026-115922 was implemented across two pull requests: PR #8033 (commit dce5876d6cc6cc30157af7d26a752ef44976da8e), which hardened the Python unpacking functions, and PR #8038 (commit 05c1bc3bceceb8d3cf11e9e7fc7f19f971c44988), which enforced strict buffer size invariants in the C++ model checker. Both commits were subsequently cherry-picked into the rel-1.22.0 release branch via PR #8066 (commit 8de2cf6aa47928e6515ac6d9e1a8b4758886a7df).

In onnx/numpy_helper.py, the patch replaces np.prod(dims, dtype=np.int64) with Python's built-in math.prod(dims) to compute expected_elements using arbitrary-precision integer arithmetic. Before calling result.resize(dims, refcheck=False), both _unpack_4bit() and _unpack_2bit() now explicitly verify whether expected_elements > result.size and raise a ValueError if the unpacked buffer cannot satisfy the declared shape.

# File: onnx/numpy_helper.py (Patched in commit dce5876d6cc6cc30157af7d26a752ef44976da8e)
def _unpack_4bit(
    data: np.ndarray, dims: Sequence[int | str]
) -> np.ndarray:
    result = np.empty(data.size * 2, dtype=np.uint8)
    array_low = data & np.uint8(0x0F)
    array_high = data & np.uint8(0xF0)
    array_high >>= np.uint8(4)
    result[0::2] = array_low
    result[1::2] = array_high
    # Use arbitrary-precision math.prod instead of fixed-width np.prod
    expected_elements = math.prod(dims)
    if result.size == expected_elements + 1:
        # handle single-element padding due to odd number of elements
        result = result[:-1]
    # FIX: Reject tensors where declared dimensions exceed unpacked element count
    if expected_elements > result.size:
        raise ValueError(
            f"Packed 4-bit data ({data.size} bytes, {result.size} elements unpacked) "
            f"is too small for the declared shape {list(dims)} "
            f"({expected_elements} elements required)."
        )
    result.resize(dims, refcheck=False)
    return result

To provide defense-in-depth and ensure onnx.checker.check_model() catches malformed sub-byte tensors prior to execution, onnx/checker.cc was updated in commit 05c1bc3bceceb8d3cf11e9e7fc7f19f971c44988. Inside check_tensor(), when tensor.has_raw_data() is true, a switch statement now computes the minimum required byte length (expected_bytes) using ceiling division: (nelem + 1) / 2 for 4-bit types and (nelem + 3) / 4 for 2-bit types. When raw_data is absent and int32_data is used instead, check_tensor() validates that tensor.int32_data().size() meets the ceiling division thresholds of (nelem + 7) / 8 for 4-bit types and (nelem + 15) / 16 for 2-bit types.

// File: onnx/checker.cc (Patched in commit 05c1bc3bceceb8d3cf11e9e7fc7f19f971c44988)
if (tensor.has_raw_data()) {
  if (tensor.data_type() == TensorProto::STRING) {
    fail_check("STRING data (tensor name: ", tensor.name(), ") should not be stored in raw_data field");
  }
  // FIX: Validate that raw_data is large enough for the declared packed sub-byte type and shape.
  int64_t expected_bytes = 0;
  switch (tensor.data_type()) {
    case TensorProto::UINT4:
    case TensorProto::INT4:
    case TensorProto::FLOAT4E2M1:
      expected_bytes = (nelem + 1) / 2; // 2 elements per byte, ceiling division
      break;
    case TensorProto::UINT2:
    case TensorProto::INT2:
      expected_bytes = (nelem + 3) / 4; // 4 elements per byte, ceiling division
      break;
    default:
      break;
  }
  if (expected_bytes > 0 && static_cast<int64_t>(tensor.raw_data().size()) < expected_bytes) {
    fail_check(
        "TensorProto (tensor name: ", tensor.name(), ") raw_data size (",
        tensor.raw_data().size(), " bytes) is too small for the declared shape and packed type (",
        expected_bytes, " bytes required).");
  }
  return;
}

The combination of these two patches completely resolves the vulnerability across both the C++ validation layer and the Python runtime materialization layer. Note that PR #8038 also moved TensorProto::FLOAT4E2M1 into the 4-bit int32_data validation case block alongside UINT4 and INT4, ensuring consistent enforcement across all three 4-bit data types.

Exploiting CVE-2026-115922 requires an attacker to supply a crafted .onnx model file or serialized TensorProto message to an application that invokes onnx.numpy_helper.to_array(), onnx.reference.ReferenceEvaluator, or onnx.reference.op_run. No authentication, elevated privileges, or specific runtime configurations are required beyond the target service processing the untrusted tensor.

Because onnx.reference.ReferenceEvaluator automatically materializes all graph initializers in its constructor (__init__), simply instantiating the evaluator on a malicious model triggers the flaw before any inference call (run()) is made. Furthermore, because onnx.checker.check_model() prior to 1.22.0 did not verify sub-byte buffer lengths, pipelines that validate incoming models with check_model() before loading them into ReferenceEvaluator remain vulnerable.

The following proof-of-concept demonstrates how a 1-byte raw_data payload in an INT4 tensor can force an immediate 700 MB heap allocation when passed to onnx.numpy_helper.to_array():

import onnx
from onnx import numpy_helper, TensorProto
 
def trigger_memory_exhaustion():
    # Construct a TensorProto with data_type INT4 (4-bit signed integer)
    tensor = TensorProto()
    tensor.name = "malicious_int4_tensor"
    tensor.data_type = TensorProto.INT4
    
    # Declare 700,000,000 elements (~700 MB when unpacked to uint8)
    tensor.dims.extend([700_000_000])
    
    # Provide only 1 byte of packed data (encodes at most 2 4-bit elements)
    tensor.raw_data = b"\x00"
 
    # In ONNX < 1.22.0, this passes C++ validation without error
    onnx.checker.check_tensor(tensor)
 
    # Trigger unchecked ndarray.resize() in _unpack_4bit()
    arr = numpy_helper.to_array(tensor)
    print(f"Allocated shape: {arr.shape}, Memory: {arr.nbytes / (1024**2):.2f} MB")
 
if __name__ == "__main__":
    trigger_memory_exhaustion()

When executed against ONNX < 1.22.0, _unpack_4bit() creates a 2-byte uint8 array from b"\x00" and immediately resizes it to 700,000,000 bytes. By increasing dims to [100_000_000_000] (100 GB) or embedding multiple such initializers inside a tiny protobuf file (under 1 KB on disk), an attacker can exhaust available system RAM or trigger the Linux kernel OOM killer, terminating the Python worker process. On ONNX >= 1.22.0, check_tensor() raises a ValidationError and to_array() raises a ValueError immediately without allocating the expanded buffer.

CVE-2026-115922 is rated Medium severity with a CVSS v3.1 base score of 6.2 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The Local (AV:L) vector reflects that the vulnerability is triggered via file or payload ingestion rather than direct network protocol framing, while User Interaction is None (UI:N) because automated MLOps validation pipelines, model conversion microservices, and inference servers typically process uploaded model artifacts without manual intervention.

The security impact is strictly confined to Availability (A:H). Because numpy.ndarray.resize() zeroes out all newly allocated memory cells via memset after reallocating the heap block, the vulnerability does not expose uninitialized heap memory (Confidentiality C:N) and does not permit out-of-bounds writes or arbitrary code execution (Integrity I:N).

However, the amplification factor of this denial-of-service condition is high. A serialized TensorProto requires less than 30 bytes of protobuf overhead to specify a 64-bit dimension value alongside a 1-byte payload, yielding an amplification ratio exceeding $10^9 : 1$ between disk size and heap allocation request. In multi-tenant MLOps platforms or shared Kubernetes clusters where worker pods lack strict memory limits, a single malformed model upload can starve co-located processes of memory.

According to threat intelligence metrics, the Exploit Prediction Scoring System (EPSS) score for CVE-2026-115922 is 0.131% (2.68th percentile), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No weaponized exploits outside of the regression test cases committed to the official ONNX repository have been observed in the wild.

To remediate CVE-2026-115922, organizations and developers should upgrade the onnx Python package and C++ library to version 1.22.0 or later. Version 1.22.0 incorporates both the Python bounds validation in onnx.numpy_helper and the C++ tensor size validation in onnx.checker.

pip install --upgrade "onnx>=1.22.0"

> [!NOTE] > Relying solely on onnx.checker.check_model() or onnx.checker.check_tensor() in versions prior to 1.22.0 does not mitigate this vulnerability, as the C++ checker previously skipped size verification for packed sub-byte raw_data and int32_data fields.

For environments that cannot immediately upgrade to onnx >= 1.22.0, applications ingesting untrusted ONNX models should implement a pre-processing validation function in Python before calling numpy_helper.to_array() or ReferenceEvaluator. Specifically, iterate over model.graph.initializer (and any Constant node tensor attributes) and verify that for UINT4, INT4, and FLOAT4E2M1 tensors, len(tensor.raw_data) >= (math.prod(tensor.dims) + 1) // 2 (or len(tensor.int32_data) >= (math.prod(tensor.dims) + 7) // 8), and for UINT2 and INT2 tensors, len(tensor.raw_data) >= (math.prod(tensor.dims) + 3) // 4 (or len(tensor.int32_data) >= (math.prod(tensor.dims) + 15) // 16).

Additionally, model ingestion and evaluation workloads should be isolated within sandboxed worker processes or containers configured with explicit memory limits (such as Linux cgroups / Docker --memory flags or POSIX resource.setrlimit(resource.RLIMIT_AS, ...) in Python) so that unexpected allocation spikes raise a catchable MemoryError rather than destabilizing the host operating system.