CVE-2026-34446: 
Python vulnerability analysis and mitigation

CVE-2026-34446 is an arbitrary file read vulnerability in Open Neural Network Exchange (ONNX) caused by a hardlink bypass in the onnx.load function. The security validator in onnx/checker.cc checks for symlinks to prevent path traversal but fails to detect hardlinks, which appear as regular files on the filesystem. All ONNX versions up to and including 1.20.1 (pip package) are affected; the issue is patched in version 1.21.0. It was published on March 31, 2026, and carries a CVSS v3.1 base score of 4.7 (Moderate) per the GitHub Advisory, with an alternative score of 5.5 (Medium) under a different vector (Github Advisory, ONNX Security Advisory).

The root cause is classified as CWE-22 (Path Traversal) and CWE-61 (UNIX Symbolic Link Following). The validator in onnx/checker.cc calls is_symlink() on external data file paths referenced by ONNX models but never checks the inode number or the st_nlink count, meaning a hardlink to a sensitive file (e.g., /etc/shadow, SSH keys, or environment files) passes all security checks undetected. An attacker crafts a malicious ONNX model whose ExternalData field references a hardlink pointing to an arbitrary file outside the model directory; when a victim loads this model via onnx.load, the hardlink is followed and the sensitive file's contents are read. The fix (commit 4755f80) implements a four-layer defense: canonical path containment via std::filesystem::weakly_canonical(), symlink rejection, O_NOFOLLOW on file open (Python only), and explicit hardlink count checks (st_nlink > 1) in both C++ and Python code paths (ONNX Security Advisory, Patch Commit).

Successful exploitation results in arbitrary file read from the victim's local filesystem, with high confidentiality impact and no integrity or availability impact. An attacker who distributes a malicious ONNX model (e.g., via HuggingFace or other model repositories) can silently exfiltrate secrets such as API keys, SSH private keys, credentials, or other sensitive files from any machine that loads the model. The attack is particularly dangerous in AI supply chain scenarios where users routinely download and load third-party models without scrutiny (Github Advisory, ONNX Security Advisory).

No public proof-of-concept exploit or evidence of in-the-wild exploitation has been reported as of the time of disclosure (Github Advisory). The EPSS score is approximately 0.004% (0th percentile), indicating a very low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires user interaction (the victim must load the malicious model) and local access to create the hardlink, but the attack can be pre-staged by distributing a crafted model through public repositories. The vulnerability was reported by researcher ZeroXJacks (ONNX Security Advisory).

1. Craft a malicious ONNX model: Create an ONNX model file whose ExternalData tensor references a filename (e.g., data.bin) that will be a hardlink to a sensitive file on the target system (e.g., ~/.ssh/id_rsa or /etc/passwd).
2. Create the hardlink: On the attacker-controlled system (or if the attacker has write access to the model directory on the victim's machine), create a hardlink: ln /etc/passwd data.bin. Package this hardlink alongside the ONNX model file.
3. Distribute the model: Upload the malicious model (including the hardlinked data.bin) to a public model repository such as HuggingFace, or deliver it via any other channel where the victim will download and load it.
4. Trigger model loading: The victim downloads the model and loads it using onnx.load('malicious_model.onnx'). The ONNX validator in checker.cc calls is_symlink() on data.bin, which returns false (hardlinks are not symlinks), and the file passes all security checks.
5. Exfiltrate data: The contents of the sensitive file are read into the ONNX model's tensor data. The attacker retrieves the exfiltrated data through the model's tensor contents or via a secondary exfiltration channel embedded in the model's loading logic (ONNX Security Advisory, Patch Commit).

• File System: Presence of files with st_nlink > 1 (multiple hard links) in ONNX model directories, particularly files with names resembling data files (e.g., .bin, .data) that share an inode with sensitive system files; verify with stat <file> or ls -li.
• File System: ONNX model packages downloaded from external sources containing external data files whose inodes match those of sensitive files outside the model directory.
• Logs: Python or application logs showing onnx.load() calls on models from untrusted or external sources, especially models with ExternalData references.
• Process: Unexpected file read activity on sensitive files (e.g., /etc/passwd, ~/.ssh/id_rsa, .env files) by Python processes running ONNX model loading operations, detectable via auditd or inotifywait on Linux.
• Network: Outbound data transfers following ONNX model loading events, potentially indicating exfiltration of read file contents (ONNX Security Advisory).

Upgrade ONNX to version 1.21.0 or later, which implements a four-layer defense including canonical path containment, symlink rejection, O_NOFOLLOW on file open, and explicit hardlink count checks (st_nlink > 1) in both C++ and Python (Patch Commit, Github Advisory). As a workaround prior to patching, avoid loading ONNX models from untrusted or unverified sources, and audit any externally sourced models for suspicious ExternalData references. Additionally, implement file integrity checks on ONNX model directories to detect files with multiple hard links before loading. Note that on Windows, O_NOFOLLOW is unavailable, so the TOCTOU window for symlink attacks remains; the hardlink count check still applies (Patch Commit).

The vulnerability was reported by researcher ZeroXJacks and credited in the GitHub Security Advisory. The ONNX maintainers responded promptly with a comprehensive patch (PR #7717) that introduced a detailed security model document (docs/Security.md) and expanded test coverage for symlink, hardlink, and path traversal scenarios. Microsoft's MSRC also tracked this CVE, reflecting its relevance to the broader AI/ML ecosystem (ONNX Security Advisory, Patch Commit).