CVE-2026-11329: weak hash enables model cache

CISO Take

The generate_hash_key function in onnx-mlir's PyTorch backend uses a cryptographically weak hashing algorithm (CWE-327/328) for its placeholder node compilation cache, creating conditions for hash collisions that could cause the compiler to serve incorrect or attacker-influenced cached artifacts. With a CVSS of 3.6 (Low), local-only attack vector, high complexity required, and no exploitation evidence — absent from CISA KEV, no EPSS data, no public exploits or scanner templates — this poses minimal operational risk in practice. The blast radius is confined to on-premises ML compilation pipelines running onnx-mlir up to version 0.5.0.0, with limited integrity and availability impact (I:L, A:L). Apply patch commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4 from PR #3427 or upgrade onnx-mlir beyond 0.5.0.0 when a fixed release is tagged.

Sources: NVD ATLAS

What is the risk?

Low operational risk. The attack is constrained to local access (AV:L) with high complexity (AC:H) and a low-privilege requirement — a profile where more direct attack paths typically exist. No public exploits, no CISA KEV entry, and no EPSS data are available. Both integrity and availability impacts are rated Low in CVSS, and confidentiality is unaffected (C:N). Practical exploitation requires an attacker with local access and deep familiarity with the onnx-mlir compilation cache internals and hash collision mechanics, making this an unlikely attack vector in real-world adversarial scenarios.

How does the attack unfold?

Local Access

Attacker obtains low-privilege local access to a system running onnx-mlir for ONNX model compilation.

AML.T0012

Hash Collision Crafting

Attacker engineers ONNX graph node identifiers that produce collisions under the weak hash algorithm used by the placeholder node cache handler.

AML.T0010.001

Cache Poisoning

The colliding hash keys cause the compilation cache to return a previously stored or attacker-staged artifact instead of recompiling the legitimate model node.

AML.T0031

Integrity Impact

The compiled model binary produces incorrect inference outputs silently, undermining model reliability in downstream deployment without triggering visible errors.

Local Access

Attacker obtains low-privilege local access to a system running onnx-mlir for ONNX model compilation.

AML.T0012

Hash Collision Crafting

Attacker engineers ONNX graph node identifiers that produce collisions under the weak hash algorithm used by the placeholder node cache handler.

AML.T0010.001

Cache Poisoning

The colliding hash keys cause the compilation cache to return a previously stored or attacker-staged artifact instead of recompiling the legitimate model node.

AML.T0031

Integrity Impact

The compiled model binary produces incorrect inference outputs silently, undermining model reliability in downstream deployment without triggering visible errors.

How severe is it?

CVSS 3.1

3.6 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 0% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Advanced

What is the attack surface?

AV Local

AC High

PR Low

UI None

S Unchanged

C None

I Low

A Low

What should I do?

5 steps

Apply patch commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4 from the onnx-mlir repository (PR #3427).
Upgrade onnx-mlir beyond version 0.5.0.0 once a fixed release is tagged upstream.
If patching is not immediately possible, restrict local system access to users who require onnx-mlir compilation.
Validate compiled model outputs against known-good baselines in CI/CD pipelines to detect anomalous behavior indicative of cache corruption.
Audit multi-tenant model compilation environments where different users share the same onnx-mlir cache directory.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Supply Chain Model Poisoning Framework Inference AML.T0010.001 - AI Software AML.T0031 - Erode AI Model Integrity

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

8.4 - AI system operation

NIST AI RMF

MEASURE 2.5 - AI system integrity and quality

Frequently Asked Questions

What is CVE-2026-11329?

The generate_hash_key function in onnx-mlir's PyTorch backend uses a cryptographically weak hashing algorithm (CWE-327/328) for its placeholder node compilation cache, creating conditions for hash collisions that could cause the compiler to serve incorrect or attacker-influenced cached artifacts. With a CVSS of 3.6 (Low), local-only attack vector, high complexity required, and no exploitation evidence — absent from CISA KEV, no EPSS data, no public exploits or scanner templates — this poses minimal operational risk in practice. The blast radius is confined to on-premises ML compilation pipelines running onnx-mlir up to version 0.5.0.0, with limited integrity and availability impact (I:L, A:L). Apply patch commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4 from PR #3427 or upgrade onnx-mlir beyond 0.5.0.0 when a fixed release is tagged.

Is CVE-2026-11329 actively exploited?

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

How to fix CVE-2026-11329?

1. Apply patch commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4 from the onnx-mlir repository (PR #3427). 2. Upgrade onnx-mlir beyond version 0.5.0.0 once a fixed release is tagged upstream. 3. If patching is not immediately possible, restrict local system access to users who require onnx-mlir compilation. 4. Validate compiled model outputs against known-good baselines in CI/CD pipelines to detect anomalous behavior indicative of cache corruption. 5. Audit multi-tenant model compilation environments where different users share the same onnx-mlir cache directory.

What systems are affected by CVE-2026-11329?

This vulnerability affects the following AI/ML architecture patterns: model compilation infrastructure, training pipelines, model serving.

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

CVE-2026-11329 has a CVSS v3.1 base score of 3.6 (LOW). The EPSS exploitation probability is 0.08%.

What is the AI security impact?

Affected AI Architectures

model compilation infrastructuretraining pipelinesmodel serving

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0031 Erode AI Model Integrity

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: 8.4

NIST AI RMF: MEASURE 2.5

What are the technical details?

Original Advisory

A vulnerability has been found in onnx onnx-mlir up to 0.5.0.0. Affected by this issue is the function generate_hash_key of the file src/Runtime/python/torch_onnxmlir/src/torch_onnxmlir/backend.py of the component Placeholder Node Cache Handler. Such manipulation leads to use of weak hash. An attack has to be approached locally. A high complexity level is associated with this attack. The exploitation is known to be difficult. The name of the patch is 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4. Applying a patch is advised to resolve this issue.

Exploitation Scenario

An attacker with low-privilege local access to a system running onnx-mlir crafts ONNX graph node identifiers designed to produce collisions under the weak hash algorithm used by the placeholder node cache handler. When the legitimate model is subsequently compiled, the cache returns a previously stored artifact — potentially one the attacker has staged — instead of recompiling the node. The resulting compiled model binary produces subtly incorrect inference outputs. Because the error manifests at inference time rather than compilation time, the integrity corruption may go undetected in pipelines that lack output validation or baseline regression testing.

Weaknesses (CWE)

CWE-327 Use of a Broken or Risky Cryptographic Algorithm Primary CWE-328 Use of Weak Hash Primary CWE-327 Use of a Broken or Risky Cryptographic Algorithm CWE-328 Use of Weak Hash

CWE-327 — Use of a Broken or Risky Cryptographic Algorithm: The product uses a broken or risky cryptographic algorithm or protocol.

[Architecture and Design] When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267
[Architecture and Design] Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.

Source: MITRE CWE corpus.