CVE-2026-115922: ONNX: unbounded alloc in 2/4-bit unpack causes DoS

GHSA-q69g-f4f5-v8m7MEDIUM
Published October 26, 2026
CISO Take

ONNX versions before 1.22.0 let a tiny crafted model file declare huge tensor dimensions for 2-bit and 4-bit data types, and the library then allocates memory for the declared size without checking the payload, so a few bytes can exhaust RAM and crash the process. The CVSS is a moderate 6.2 because it needs local file processing and only affects availability, with no data exposure or code execution. There is no KEV listing, no public exploit, no Nuclei template and no EPSS score yet, so exploitation is not currently observed. However, the package has 1,124 downstream dependents and the flaw is trivial to trigger wherever untrusted models are loaded, such as model hubs, upload-based MLOps platforms and CI validation jobs. Upgrade onnx to 1.22.0 or later, and in the meantime avoid converting untrusted quantized models and run model parsing under memory limits.

Sources:NVDGitHub AdvisoryATLASOpenSSF

What is the risk?

Medium overall. Exploitation is low-complexity and needs no privileges or user interaction beyond getting a crafted model processed by to_array() or ReferenceEvaluator. Impact is limited to availability (memory exhaustion, process crash or OOM kill). The CVSS vector is local, but in practice the exposure is higher for services that ingest user-supplied or third-party ONNX models automatically, such as model conversion, scanning or validation pipelines. No active exploitation, public exploit or KEV listing is known, and EPSS data is not available. The package has 19 other CVEs, an OpenSSF score of 8.3/10 and an active maintenance cadence, which lowers long-term risk.

How does the attack unfold?

Craft malicious model
Attacker builds an ONNX file with a UINT4 or INT2 tensor whose dims declare a huge size but whose raw_data is tiny.
AML.T0017
Delivery
The model is uploaded to a registry or hub, or handed to a victim as a shared model file.
AML.T0011.000
Trigger unpacking
A pipeline calls to_array() or ReferenceEvaluator, and _unpack_2bit()/_unpack_4bit() resize the array to the declared dims without checking the data length.
AML.T0011.000
Resource exhaustion
Memory is exhausted, the process is OOM-killed and the model processing service becomes unavailable.
AML.T0029

What systems are affected?

PackageEcosystemVulnerable RangePatched
ONNXpip<= 1.21.01.22.0
21.6KOpenSSF 8.31.1K dependentsPushed 6d ago82% patched~33d to patchFull package profile →

Do you use ONNX? You're affected.

How severe is it?

CVSS 3.1
6.2 / 10
EPSS
0.1%
chance of exploitation in 30 days
Higher than 3% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AVACPRUISCIA
AVLocal
ACLow
PRNone
UINone
SUnchanged
CNone
INone
AHigh

What should I do?

1 step
  1. 1) Upgrade onnx to 1.22.0 or later (fixes in PRs 8033, 8038 and 8066). 2) Until patched, do not call to_array() or use ReferenceEvaluator on untrusted models that contain 2-bit or 4-bit tensor types. 3) Run model parsing and conversion in isolated workers or containers with memory limits (cgroup or ulimit) and automatic restart. 4) Validate TensorProto.dims against raw_data length before processing untrusted models. 5) Inventory with pip list or SBOM tooling for onnx versions below 1.22.0, including transitive dependencies. 6) Monitor for OOM kills and abnormal memory spikes in model ingestion services.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15-Accuracy, robustness and cybersecurity
ISO 42001
A.7.4-Quality of data for AI systems
NIST AI RMF
MANAGE 2.3-Responses to previously unknown risks and mechanisms to supersede or deactivate AI systems
OWASP LLM Top 10
LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-115922?

ONNX versions before 1.22.0 let a tiny crafted model file declare huge tensor dimensions for 2-bit and 4-bit data types, and the library then allocates memory for the declared size without checking the payload, so a few bytes can exhaust RAM and crash the process. The CVSS is a moderate 6.2 because it needs local file processing and only affects availability, with no data exposure or code execution. There is no KEV listing, no public exploit, no Nuclei template and no EPSS score yet, so exploitation is not currently observed. However, the package has 1,124 downstream dependents and the flaw is trivial to trigger wherever untrusted models are loaded, such as model hubs, upload-based MLOps platforms and CI validation jobs. Upgrade onnx to 1.22.0 or later, and in the meantime avoid converting untrusted quantized models and run model parsing under memory limits.

Is CVE-2026-115922 actively exploited?

No confirmed active exploitation of CVE-2026-115922 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-115922?

1) Upgrade onnx to 1.22.0 or later (fixes in PRs 8033, 8038 and 8066). 2) Until patched, do not call to_array() or use ReferenceEvaluator on untrusted models that contain 2-bit or 4-bit tensor types. 3) Run model parsing and conversion in isolated workers or containers with memory limits (cgroup or ulimit) and automatic restart. 4) Validate TensorProto.dims against raw_data length before processing untrusted models. 5) Inventory with pip list or SBOM tooling for onnx versions below 1.22.0, including transitive dependencies. 6) Monitor for OOM kills and abnormal memory spikes in model ingestion services.

What systems are affected by CVE-2026-115922?

This vulnerability affects the following AI/ML architecture patterns: model conversion pipelines, model registries and hubs, MLOps validation and CI pipelines, model scanning tools, notebook and research environments.

What is the CVSS score for CVE-2026-115922?

CVE-2026-115922 has a CVSS v3.1 base score of 6.2 (MEDIUM). The EPSS exploitation probability is 0.13%.

What is the AI security impact?

Affected AI Architectures

model conversion pipelinesmodel registries and hubsMLOps validation and CI pipelinesmodel scanning toolsnotebook and research environments

MITRE ATLAS Techniques

AML.T0010.003Model
AML.T0011.000Unsafe AI Artifacts
AML.T0029Denial of AI Service

Compliance Controls Affected

EU AI Act: Art. 15
ISO 42001: A.7.4
NIST AI RMF: MANAGE 2.3
OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker uploads a crafted ONNX model to a public model hub or a company's internal model registry. The model contains a UINT4 tensor with a few bytes of raw_data but dims declaring billions of elements. When the platform's automated validation or conversion job calls onnx.numpy_helper.to_array(), the unpacking routine resizes the array to the declared size, memory is exhausted and the worker is OOM-killed. The attacker repeats the upload to keep the ingestion pipeline down or to degrade other services on the shared host.

Weaknesses (CWE)

CWE-789 — Memory Allocation with Excessive Size Value: The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

  • [Implementation, Architecture and Design] Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
  • [Operation] Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Timeline

Published
October 26, 2026
Last Modified
October 30, 2026
First Seen
October 26, 2026

Related Vulnerabilities