CVE-2026-11329: ONNX ONNX-MLIR Weak Hash Vulnerability

CVE-2026-11329 Overview

CVE-2026-11329 affects the onnx-mlir project up to version 0.5.0.0. The vulnerability resides in the generate_hash_key function within src/Runtime/python/torch_onnxmlir/src/torch_onnxmlir/backend.py, part of the Placeholder Node Cache Handler component. The flaw stems from the use of a weak hash that omits tensor dtype information when constructing cache keys for placeholder nodes. This weakness is categorized under [CWE-327: Use of a Broken or Risky Cryptographic Algorithm]. Exploitation requires local access and is considered difficult, limiting practical impact. The maintainers released patch 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4 to address the issue.

Critical Impact

A local attacker with low privileges can trigger hash collisions in the placeholder node cache, potentially causing incorrect cached compilation artifacts to be reused across tensors of different data types.

Affected Products

• ONNX onnx-mlir versions up to and including 0.5.0.0
• The torch_onnxmlir Python backend component
• The generate_hash_key function in backend.py

Discovery Timeline

• 2026-06-05 - CVE-2026-11329 published to NVD
• 2026-06-05 - Last updated in NVD database

Technical Details for CVE-2026-11329

Vulnerability Analysis

The vulnerability sits in the placeholder node cache key generation logic of onnx-mlir's PyTorch backend. The generate_hash_key function builds a lightweight identifier for each placeholder node based on shape information only. Because tensor dtype was not included in the key, two placeholder nodes with identical shapes but different data types produced colliding hash keys. A local attacker who can influence the model graph fed into onnx-mlir may trigger reuse of cached artifacts compiled for an incompatible data type. The patch adds dtype to the constructed key string, restoring uniqueness across shape and type combinations.

Root Cause

The root cause is an incomplete hash key construction in generate_hash_key. Cache identity should encode every property that affects compilation output, but the original implementation serialized only the shape vector. This violates the cryptographic and cache-design principle that hash inputs must capture all semantically relevant fields.

Attack Vector

Exploitation requires local access with low privileges and high attack complexity. An attacker must craft or supply model inputs that cause the cache to associate compiled output from one dtype with a placeholder of a different dtype. Successful exploitation yields limited integrity and availability impact on the affected process, with no confidentiality exposure.

                         else:
                             shape.append(s)
                     shape_str = ",".join(shape)
+                    dtype = node.meta["example_value"].dtype
                     node_info.append(
-                        f"om_placeholder_{placeholder_counter}_[{shape_str}]"
+                        f"om_placeholder_{placeholder_counter}_[{shape_str}]_{dtype}"
                     )
                 else:
                     node_info.append(f"om_placeholder_{placeholder_counter}")
# Source: https://github.com/onnx/onnx-mlir/commit/72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4

The patch shown above appends the resolved dtype from node.meta["example_value"] to the placeholder key, eliminating shape-only collisions.

Detection Methods for CVE-2026-11329

Indicators of Compromise

• Anomalous reuse of cached compiled modules across model runs with differing tensor data types.
• Unexpected numerical results or type errors during onnx-mlir PyTorch backend execution that correlate with cache hits.
• Presence of onnx-mlir versions at or below 0.5.0.0 without the 72c5187 commit applied.

Detection Strategies

• Audit installed onnx-mlir builds and confirm whether commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4 is included.
• Add logging around generate_hash_key to record the full key string and verify dtype is part of every emitted key.
• Compare cache hit ratios and output checksums when running models that share shapes but differ in data type.

Monitoring Recommendations

• Monitor build pipelines that pin onnx-mlir to versions <= 0.5.0.0 and flag them for patch review.
• Track integrity of generated MLIR artifacts using stronger digests such as SHA-256 over the canonical graph representation.
• Alert on local user activity that drives unusual repeated compilation calls against the torch_onnxmlir backend.

How to Mitigate CVE-2026-11329

Immediate Actions Required

• Upgrade onnx-mlir to a build that includes commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4 from GitHub Pull Request #3427.
• Invalidate any existing on-disk caches generated by vulnerable versions of the torch_onnxmlir backend.
• Restrict local access to systems running onnx-mlir compilation services to trusted users only.

Patch Information

The upstream fix is published as commit 72c5187 in the ONNX-MLIR repository. The change updates generate_hash_key in src/Runtime/python/torch_onnxmlir/src/torch_onnxmlir/backend.py to include the tensor dtype in the placeholder key string. Additional context is available in the VulDB advisory for CVE-2026-11329.

Workarounds

• Disable the placeholder node cache when compiling models that mix data types, if the deployment exposes a configuration toggle.
• Manually purge the cache between compilation runs that differ only in tensor dtype.
• Apply the one-line change from commit 72c5187 as a local patch if upgrading the full package is not yet feasible.

# Pull and apply the upstream fix
git clone https://github.com/onnx/onnx-mlir.git
cd onnx-mlir
git cherry-pick 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4
# Rebuild and reinstall the torch_onnxmlir backend
pip install -e src/Runtime/python/torch_onnxmlir