CVE-2026-115922

What it actually does

The flaw permits an attacker-controlled TensorProto.dims value to dictate the size of unpacked arrays in _unpack_2bit() and _unpack_4bit() without validating that the supplied raw_data or int32_data contains the declared element count, enabling a small payload for UINT2/INT2/UINT4/INT4/FLOAT4E2M1 tensors to trigger a disproportionately large memory allocation when materialized through onnx.numpy_helper.to_array() or onnx.reference.ReferenceEvaluator.

Why it matters to the business

Processing of untrusted ONNX models can exhaust memory and crash machine-learning applications or services, resulting in denial of service, pipeline failures, and operational disruption; the issue is four days old with no observed exploitation or ransomware use.

How an attack unfolds

An attacker creates an ONNX model containing a quantized tensor whose dims field declares a very large element count while the corresponding packed data remains small, then supplies the model to any application that invokes to_array() or ReferenceEvaluator on it, causing the library to allocate a massive array and exhaust available memory.

How to fix it

Upgrade the ONNX package to version 1.22.0 or later, which adds verification that the packed data length matches the declared dims before allocation; validate all model sources and consider sandboxing or resource limits on model processing until upgraded.

How to confirm the fix worked

Confirm the installed ONNX version is 1.22.0 or newer; attempt to load a test model containing an undersized payload with oversized dims and verify that an exception or rejection occurs instead of a large allocation.

Typical attack path

1. Construct ONNX model with attacker-chosen large dims and undersized raw_data/int32_data for 2-bit or 4-bit tensor
2. Deliver the model file to a target that uses onnx.numpy_helper.to_array() or ReferenceEvaluator
3. Trigger deserialization or evaluation of the tensor
4. Induce out-of-memory condition and application crash

How to detect it

Watch application and system logs for abrupt out-of-memory errors or sudden memory spikes coinciding with ONNX model loading; inspect process traces for calls to _unpack_2bit, _unpack_4bit, to_array, or ReferenceEvaluator immediately before resource exhaustion.

What your security team should do

• Upgrade ONNX to 1.22.0 or later across all environments
• Reject or sanitize ONNX models originating from untrusted sources
• Apply memory limits and monitoring to processes that load ONNX models
• Review ML pipelines for direct use of numpy_helper.to_array() or ReferenceEvaluator on external input