CVE-2026-11329
Weak Hash Generation in ONNX MLIR via Placeholder Node Cache Handler
Publication date: 2026-06-05
Last updated on: 2026-06-05
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| onnx | onnx-mlir | to 0.5.0.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-328 | The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack). |
| CWE-327 | The product uses a broken or risky cryptographic algorithm or protocol. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the ONNX-MLIR compiler's placeholder node cache handler. Specifically, the lightweight hashing path used to generate cache keys for placeholder nodes only included the tensor shape but omitted the data type (dtype). This caused models with the same structure and shape but different data types (e.g., float32 vs. float64) to generate identical cache keys.
As a result, when a second model with a different dtype but the same shape was run, it would reuse the compiled shared object (.so) file from the first model, leading to incorrect inference results without any error or warning.
The vulnerability is due to the use of a weak hash key that does not uniquely identify models differing by dtype. The fix involves modifying the cache key generation to include the dtype by appending it to the placeholder node's identifier, ensuring unique cache keys for models with different dtypes.
How can this vulnerability impact me? :
This vulnerability can cause incorrect inference results when running ONNX models through the ONNX-MLIR compiler. If two models have the same shape but different data types, the second model may silently reuse the compiled code of the first model due to identical cache keys.
This silent reuse leads to inaccurate outputs without any error or warning, potentially compromising the reliability and correctness of machine learning model predictions.
The attack requires local access and is considered difficult to exploit due to high complexity.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability is related to the use of a weak hash in the generate_hash_key function of the ONNX-MLIR compiler's placeholder node cache handler. Detection involves verifying if the affected version of onnx-mlir (up to 0.5.0.0) is in use and if the system is locally running models that might reuse compiled shared objects incorrectly due to the weak hash.
Since the issue is local and related to the software version and its behavior, detection can be done by checking the installed ONNX-MLIR version and reviewing if the patch (commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4) has been applied.
Suggested commands to detect the vulnerable version and patch status include:
- Check ONNX-MLIR version: `onnx-mlir --version` or check the installed package version via your package manager.
- Search for the presence of the patch commit in the source code repository if built from source: `git log -p | grep 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4`
- Monitor inference results for inconsistencies when running models with identical shapes but different data types, which may indicate the weak hash issue.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to apply the patch identified by commit 72c5187ff6d13c2c2b3d3789b8f5faf99f08a5b4, which fixes the weak hash by including the data type in the cache key generation.
If you are using a version of ONNX-MLIR up to 0.5.0.0, update to a version that includes this patch or manually apply the patch if building from source.
Since exploitation requires local access and is complex, restricting local access to trusted users and environments can reduce risk.
Additionally, validate inference results especially when running multiple models with similar shapes but different data types to detect any anomalies.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.