CVE-2026-34446: ONNX Path Traversal Vulnerability

CVE-2026-34446 Overview

CVE-2026-34446 is a Path Traversal vulnerability in Open Neural Network Exchange (ONNX), an open standard for machine learning interoperability. Prior to version 1.21.0, the onnx.load function contains a security flaw where path traversal protections check for symbolic links but fail to account for hardlinks. Because hardlinks appear as regular files on the filesystem, attackers can bypass the existing symlink checks to access files outside the intended directory structure.

Critical Impact

Attackers can leverage hardlinks to bypass path traversal protections in onnx.load, potentially accessing sensitive files outside the model directory and exposing confidential data.

Affected Products

• Open Neural Network Exchange (ONNX) versions prior to 1.21.0

Discovery Timeline

• 2026-04-01 - CVE CVE-2026-34446 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-34446

Vulnerability Analysis

This vulnerability affects the external data file handling mechanism in ONNX's model loading functionality. When loading ONNX models that reference external data files, the onnx.load function performs security checks to prevent path traversal attacks. However, the implementation only checks for symbolic links using filesystem APIs like is_symlink(), which only examines the final path component.

The fundamental issue is that hardlinks are indistinguishable from regular files at the filesystem level. Unlike symlinks, which contain a pointer to another path, hardlinks create an additional directory entry pointing directly to the same inode as the original file. This means standard symlink detection methods completely miss hardlink-based path traversal attempts.

An attacker could craft a malicious ONNX model that references external data through a hardlink pointing to sensitive files outside the model directory (such as configuration files, credentials, or other sensitive data), thereby achieving unauthorized file access.

Root Cause

The root cause is an incomplete security check in the external data path validation logic. The code relied solely on is_symlink() checks to prevent path traversal, but this approach only validates the final component of the path and does not detect hardlinks. Hardlinks look exactly like regular files to the filesystem, so they bypass the symlink-only detection entirely.

Additionally, the original implementation did not perform canonical path containment validation to ensure resolved paths remain within the base model directory, leaving the door open for various path traversal techniques.

Attack Vector

The attack requires local access and user interaction (opening a malicious ONNX model file). An attacker would need to:

1. Create a hardlink within a malicious model directory that points to a sensitive file outside the intended model path
2. Reference this hardlink as external tensor data in the ONNX model
3. Convince a victim to load the malicious model using onnx.load

When the victim loads the model, the hardlink bypasses symlink checks, and the application reads the sensitive file as if it were legitimate model data, potentially exposing confidential information.

The security patch addresses this by implementing three security checks:

def _validate_external_data_path(
    base_dir: str,
    data_path: str,
    tensor_name: str,
    *,
    check_exists: bool = True,
) -> str:
    """Validate that an external data path is safe to open.

    Performs three security checks:
    1. Canonical path containment — resolved path must stay within base_dir.
    2. Symlink rejection — final-component symlinks are not allowed.
    3. Hardlink count — files with multiple hard links are rejected.

    Args:
        base_dir: The model base directory that data_path must be contained in.
        data_path: The external data file path to validate.
        tensor_name: Tensor name for error messages.
        check_exists: If True (default), check hardlink count. Set to False
            for save-side paths where the file may not exist yet.

    Returns:
        The validated data_path (unchanged).

    Raises:
        onnx.checker.ValidationError: If any security check fails.
    """

Source: GitHub Commit

The C++ implementation adds canonical path containment validation:

         data_path_str,
         ", but it is a symbolic link.");
   }
+  // Verify the resolved path stays within the base directory to prevent
+  // path traversal via symlinks in parent directory components.
+  // is_symlink() only checks the final component; a path like
+  // "symlink_subdir/real_file.data" would bypass it.
+  if (data_path_str[0] != '#') {
+    std::error_code ec;
+    auto canonical_base = std::filesystem::weakly_canonical(base_dir_path, ec);
+    if (ec) {
+      fail_check(
+          "Data of TensorProto ( tensor name: ",
+          tensor_name,
+          ") references external data at ",
+          data_path_str,
+          ", but the model directory path could not be resolved.");
+    }
+    auto canonical_data = std::filesystem::weakly_canonical(data_path, ec);
+    if (ec) {
+      fail_check(
+          "Data of TensorProto ( tensor name: ",
+          tensor_name,
+          ") references external data at ",
+          data_path_str,
+          ", but the data path could not be resolved.");
+    }
+    auto canonical_base_native = canonical_base.native();
+    auto canonical_data_native = canonical_data.native();
+    if (!canonical_base_native.empty() && canonical_base_native.back() != std::filesystem::path::preferred_separator) {

Source: GitHub Commit

Detection Methods for CVE-2026-34446

Indicators of Compromise

• Presence of files with elevated hardlink counts (greater than 1) in ONNX model directories
• ONNX models with external data references pointing to paths outside expected model directories
• Unexpected file access patterns when loading ONNX models, particularly accessing sensitive system files

Detection Strategies

• Monitor filesystem operations during ONNX model loading for access to files outside the model directory
• Implement file integrity monitoring on sensitive directories that may be targeted via hardlink traversal
• Use application-level logging to track external data file paths resolved by onnx.load
• Deploy endpoint detection rules to identify hardlink creation in directories containing ONNX models

Monitoring Recommendations

• Enable audit logging for file access operations in environments processing untrusted ONNX models
• Monitor for the creation of hardlinks in directories where ONNX models are stored or processed
• Track onnx.load operations and validate that all resolved external data paths remain within expected boundaries
• Implement SentinelOne Singularity platform rules to detect anomalous file access patterns during ML model loading

How to Mitigate CVE-2026-34446

Immediate Actions Required

• Upgrade ONNX to version 1.21.0 or later immediately
• Audit existing ONNX models for external data references that may indicate malicious content
• Restrict loading of ONNX models to trusted sources only
• Implement filesystem-level restrictions to prevent hardlink creation in model directories

Patch Information

The vulnerability has been patched in ONNX version 1.21.0. The fix implements comprehensive path validation including canonical path containment checks, symlink rejection, and hardlink count verification. Organizations should upgrade to the patched version immediately.

For detailed patch information, see the GitHub Security Advisory and the commit that addresses this vulnerability.

Workarounds

• Only load ONNX models from trusted and verified sources
• Run ONNX model processing in sandboxed environments with restricted filesystem access
• Implement pre-loading validation scripts that check for hardlinks in model directories before processing
• Use container isolation to limit the impact of potential path traversal attacks

# Check for hardlinks in ONNX model directories before processing
# Files with link count > 1 may be hardlinks
find /path/to/model/directory -type f -links +1 -ls

# Verify ONNX version is patched
pip show onnx | grep Version
# Should show 1.21.0 or later

# Upgrade ONNX to patched version
pip install --upgrade onnx>=1.21.0