# CVE-2026-11329: onnx onnx-mlir weak hash in Placeholder Node Cache Handler

Source: https://junglewise.ai/threats/cve-2026-11329-onnx-onnx-mlir-weak-hash-in-placeholder-node-cache-handler  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-06-05. Updated: 2026-06-05  
License: CC BY 4.0 with a link back

CVE-2026-11329 · Severity: low · CVSS 3.6 · Published 2026-06-05

A vulnerability in the onnx-mlir compiler infrastructure can cause machine learning models to produce incorrect results without warning. When processing different models that share the same structure but use different data types (such as 32-bit vs 64-bit floats), the system may mistakenly reuse a previously compiled version of a different model. This "cache collision" leads to silent data corruption or incorrect inference results, which could impact the reliability of AI-driven decision-making processes.

Vendors: [ONNX](https://junglewise.ai/threats/vendors/onnx).

## Quick answers

**Is CVE-2026-11329 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-11329 being exploited in the wild.

**How severe is CVE-2026-11329?** Low severity, with a CVSS score of 3.6, published 5 June 2026.

**Which products and versions are affected?** Onnx-Mlir up to 0.5.0.0.

**Is there a fix for CVE-2026-11329?** A patch was published on 2026-03-30: Fix merged into main branch Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-11329 attacked?** It is attacked with local access, in a software library.

**Am I affected by CVE-2026-11329?** Check whether you run Onnx-Mlir at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## Technical details

A vulnerability exists in the `generate_hash_key` function within `src/Runtime/python/torch_onnxmlir/src/torch_onnxmlir/backend.py` of onnx-mlir. When `use_lightweight_hashing` is enabled (the default), the hashing logic for placeholder nodes only incorporates the tensor shape and ignores the data type (dtype). This root cause allows two distinct models with identical shapes but different dtypes (e.g., float32 vs float64) to generate the same cache key. Consequently, the runtime may incorrectly load and execute a previously compiled shared object (.so) file from a different model. An attacker with local access could potentially exploit this to cause integrity failures or denial of service through incorrect computational outputs. The issue is addressed in commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4 by appending the dtype to the placeholder identifier string.

## Affected products

- onnx onnx-mlir up to 0.5.0.0

## Timeline

- 2026-03-25: other: Pull request submitted to fix the issue
- 2026-03-30: patched: Fix merged into main branch
- 2026-06-05: disclosed: CVE published

## References

- [https://github.com/onnx/onnx-mlir/](https://github.com/onnx/onnx-mlir/)
- [https://github.com/onnx/onnx-mlir/commit/72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4](https://github.com/onnx/onnx-mlir/commit/72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4)
- [https://github.com/onnx/onnx-mlir/pull/3427](https://github.com/onnx/onnx-mlir/pull/3427)
- [https://vuldb.com/cve/CVE-2026-11329](https://vuldb.com/cve/CVE-2026-11329)
- [https://vuldb.com/submit/832358](https://vuldb.com/submit/832358)
- [https://vuldb.com/vuln/368865](https://vuldb.com/vuln/368865)
- [https://vuldb.com/vuln/368865/cti](https://vuldb.com/vuln/368865/cti)