ONNX CVE 2025 Path Traversal in External Data (1.17.0)

A critical path‑traversal flaw in ONNX 1.17.0’s external data handler — specifically in onnx.external_data_helper.save_external_data — allows crafted external_data.location values to escape their intended storage directory and overwrite arbitrary files on disk, producing high‑severity integrity and availability consequences for systems that parse untrusted ONNX model artifacts.

Background​

ONNX (Open Neural Network Exchange) is a widely used open format and runtime ecosystem for exchanging and operating ML models across frameworks and runtimes. Many model packaging workflows use the ONNX external_data mechanism to store large tensor blobs separately from the main model file; the save_external_data helper writes those blobs to disk based on metadata supplied in tensor.external_data.location. When that write path is not strictly validated, a classic directory traversal (../) sequence becomes an attack surface. This specific issue has been assigned CVE‑2025‑51480 and has been publicly documented by multiple vulnerability trackers and vendor advisories. Several maintainers and downstream distributions have recorded the vulnerability and its high severity rating (CVSS v3.1 = 8.8 in public trackers), and the ONNX project has accepted fixes to harden path handling in save_external_data.

---

What the vulnerability actually is​

Technical root cause​

• The vulnerability is a path traversal (CWE‑22) originating in save_external_data’s handling of the external_data.location field stored inside tensor metadata.
• When save_external_data constructs output filenames from the provided location value it fails to reliably canonicalize and confine the resolved path to the intended base directory. This permits attacker‑controlled location strings containing "../" or equivalent encodings to escape the destination folder.

Practical effect​

• An attacker who can provide or influence the model file or its external tensors can craft external_data.location entries that cause save_external_data to write blobs to arbitrary filesystem paths that the process can write to.
• That capability can be used to overwrite configuration files, scripts, service files, or other sensitive artifacts. Overwriting such targets may lead to persistent service disruption, privilege escalation (if a system process later executes or loads the modified file), or complete denial of availability of the affected component.

Attack prerequisites and vector​

• The vulnerability is exploitable by supplying an ONNX model (or an ONNX tensor external data entry) that includes a malicious external_data.location value. Because ONNX artifacts are commonly loaded from files, archives, or network sources, the attack surface includes any service or process that accepts and persists untrusted ONNX artifacts.
• Public trackers indicate no privileges required but user interaction is required for many attack scenarios (per CVSS metadata), meaning an attacker typically needs a victim process to open or import the crafted ONNX file. That said, in automated model ingestion pipelines where models are taken from untrusted sources and processed without strict validation, the interaction requirement can be trivial or automated.

---

Scope and impact — who should be worried​

Affected versions​

• The observed reports consistently identify ONNX version 1.17.0 as the vulnerable release for this specific save_external_data path traversal. Distributions and trackers list the CPE mapping accordingly.

Typical high‑risk deployments​

• Multi‑tenant model hosting services that accept models from third parties (model hubs, automated CI pipelines that run user-supplied tests, managed inference platforms).
• Data science workstations and desktop pipelines where users open model files from untrusted archives.
• Container images and build pipelines that consume externally authored ONNX artifacts (build servers, image builders).
• CI/CD agents and automated validation systems that process model packages with limited sandboxing or filesystem separation.

Realistic impact scenarios​

• Overwrite of startup scripts, service unit files, or web application assets leading to service failure or code injection.
• Replacement or corruption of configuration files causing denial of service or misconfiguration.
• Supply‑chain pivot: a compromised model artifact writes into build artifacts or repositories, allowing a later stage to consume the malicious file and introduce a persistent compromise.

---

Verified details and cross‑checks​

To ensure claims and numbers are accurate, the following key facts were cross‑checked against independent sources:

1. The vulnerability description (path traversal in onnx.external_data_helper.save_external_data) is recorded by national and vendor trackers.
2. Public CVSS v3.1 severity is listed at 8.8 (High) in multiple registries that synthesized vendor/third‑party scoring. This aligns with the potential for high confidentiality, integrity, and availability impact when arbitrary file overwrite is possible.
3. The ONNX upstream repository contains code changes that address the insecure path handling in save_external_data; a targeted pull request was merged to harden the logic. Those repository PRs and patch traces are visible in the ONNX GitHub project.

Caveat: at the time of publishing, not every tracker had identical enrichment in the NVD entry; NVD’s page for this CVE references the description but may not have fully enriched CVSS metadata in the same way as distribution trackers. Use vendor and upstream project advisories for authoritative remediation mapping.

---

Why this matters to WindowsForum readers​

• Many Windows‑centric AI development workflows run ONNX toolchains on Windows servers, workstations, and WSL/containers. When ONNX model import or test utilities are invoked on Windows hosts (including CI runners and desktop automation), an attacker able to get a crafted model file into those workflows can trigger the overwrite primitive. The consequences range from broken developer tooling to compromised jump hosts in corporate environments.
• The observed threat model is not limited to Linux; the vulnerability is about path resolution and write semantics that apply on all OSes. File‑system permission models vary — on Windows the target paths and special device name corner cases differ — but the basic traversal primitive is cross‑platform where the process has write access. Administrators must therefore consider both Windows and Linux build/hosting surfaces in their inventories.

---

Exploitation complexity and likelihood​

• Public trackers rate attack complexity as low and no privileges required; however many enumerations include user interaction required in the CVSS vector. That combination commonly describes a scenario where simply persuading a service to load an ONNX artifact triggers the write. In hosted or automated processing pipelines, that "interaction" is often a queued ingestion event, meaning weaponization can be trivial to script.
• Despite the high severity score, exploitation in the wild depends on two operational realities:
  • Whether a target environment ingests untrusted ONNX models or tensors without sandboxing.
  • Whether the ONNX process runs with filesystem privileges sufficient to overwrite sensitive targets.
• In environments that automatically accept model uploads (public model hubs, CI runners), the vulnerability is materially exploitable and therefore high priority.

---

What ONNX maintainers changed (brief technical summary of fixes)​

• The upstream fix adds validation and canonicalization of target paths produced from external_data.location values and rejects or normalizes entries that would resolve outside the intended storage directory.
• Tests were added or updated to reproduce the traversal cases and ensure the new logic prevents "../" and encoded traversal sequences from escaping the output base path. The change was merged as a focused patch against the affected helper, and related PR commentary documents the vulnerable code paths.

---

Concrete mitigation and remediation steps​

Follow this prioritized checklist to reduce risk immediately and sustainably.

Immediate remediation (apply as soon as possible)​

1. Upgrade ONNX to a patched release that includes the merged fix for save_external_data. Consult the ONNX project release notes and your distribution’s package updates. If a vendor‑packaged version is installed, apply the vendor patch.
2. If you cannot upgrade right away, stop processing untrusted ONNX artifacts on hosts that have access to sensitive files, or isolate the model‑processing component behind strict filesystem sandboxing. Prefer ephemeral, constrained containers with minimal volume mounts.

Short‑term compensating controls​

• Enforce least privilege for any process that reads or writes model artifacts: run model importers under an unprivileged service account and mount only a dedicated, non‑privileged workspace directory.
• Validate and sanitize incoming ONNX files as part of ingestion: reject any tensor.external_data entries with absolute paths, parent directory references (../), or suspicious URL encodings before attempting to write external blobs.
• Use file system ACLs and OS‑level hardening to prevent writes to critical system locations from the model processing account. On Windows, ensure the process does not run under an account with broad write rights to C:\Program Files or C:\Windows; on Linux, bind mount a dedicated directory with restrictive permissions.

Medium‑term measures​

• Add pre‑ingest model validation in CI pipelines to inspect tensor metadata for embedded paths and disallow external_data.location fields unless they conform to a safe whitelist naming scheme.
• Bake these checks into ingestion microservices and web upload endpoints, using canonical path resolution and confinement checks before any write is attempted.
• Rebuild and redeploy container images and VM images with updated ONNX wheels; update orchestration manifests to pin to the patched image tags.

---

Detection and hunting guidance​

• Search logs and filesystem activity for unexpected writes originating from your model processing service. Indicators include:
  • File creation events outside the designated model data directory.
  • Writes to configuration files, startup directories, or paths containing “../” segments prior to canonicalization.
• For centralized telemetry:
  • Add alerts for model ingestion events that include external_data.location values with suspicious patterns (%2e%2e, ../, ..\).
  • Monitor integrity checks of critical configuration files and binaries for unexpected changes following model ingestion windows.

---

Attack scenarios and risk analysis​

1. Targeted overwrite: an attacker uploads a model to an automated test runner that runs as a privileged user. The crafted external_data.location points to a startup script or scheduled task, resulting in persistent service disruption or code execution on the next service restart. Impact: high integrity and availability loss.
2. Supply‑chain pivot: a malicious model artifact overwrites a build artifact or repository file in a shared CI workspace, later causing downstream images or packages to include a backdoor. Impact: high — remote persistence and long‑tail compromise.
3. Denial‑of‑service against model serving: overwriting model files or configuration used by an inference service to render it inoperable until manual remediation. Impact: sustained or persistent loss of availability for affected services.

Each scenario reinforces that the real blast radius depends heavily on how model artifacts enter your environment and what filesystem privileges model‑processing components possess.

---

Strengths and weaknesses of the upstream response (critical analysis)​

Notable strengths​

• The ONNX project accepted targeted fixes and added tests to prevent regressions in the vulnerable helper function; this demonstrates responsible upstream maintenance and a practical remediation path.
• Multiple distribution and security trackers quickly indexed the CVE and flagged high severity, which helps defenders prioritize mitigation in automated patching and advisory systems.

Potential weaknesses and operational risks​

• Patch reliance: Many organizations run vendor‑packaged ONNX wheels embedded inside larger images or appliances. Those images may lag official ONNX releases, creating a long remediation tail unless image rebuilds are prioritized.
• Detection gaps: Overwrite attacks can be stealthy if the attacker targets files that aren’t monitored by integrity checks, so organizations that lack file‑integrity monitoring or strict ingestion validation are at greater risk.
• Ambiguity in metadata: Some public registries had slightly different enrichment or timing in publishing CVSS metadata; defenders should rely on upstream CHANGES/PRs and vendor advisories to map exact fixed releases rather than a single third‑party feed.

---

Practical checklist for Windows administrators (quick reference)​

• Immediately identify hosts and containers that run ONNX 1.17.0: run pip show on managed interpreters, inspect Dockerfiles, and query image manifests.
• If found, schedule upgrade to a patched ONNX wheel or rebuild images that contain the vulnerable library.
• Until patched, isolate model ingestion services and run them with a dedicated, low‑privilege account and a single writable workspace directory.
• Add pre‑ingest model metadata checks to block external_data.location values that contain absolute paths, parent directory markers, or URL encodings that decode to traversal sequences.
• Enable file integrity monitoring for critical config and startup paths and alert on unexpected modifications coincident with model ingestion events.

---

Final assessment and recommendation​

CVE‑2025‑51480 represents a classic but high‑impact path traversal vulnerability in a core helper used for ONNX external tensor data storage. The risk is amplified in modern ML operations where models and datasets flow through automated, often multi‑tenant pipelines that process third‑party artifacts without sufficient sanitization. The vulnerability’s practical consequences include arbitrary file overwrite, supply‑chain pivot potential, and sustained or persistent denial of availability for affected components. Remediation is straightforward in principle — upgrade to a patched ONNX release and harden ingestion/sandboxing — but operational execution requires urgent inventory, image rebuilds, CI pipeline updates, and layered mitigations where immediate upgrades are not yet possible. Prioritize hosts and services that process untrusted ONNX inputs or run with broad filesystem privileges. In high‑risk environments (public model hubs, automated CI, or shared inference clusters), treat this CVE as critical for immediate action: patch, isolate, harden, and monitor. Failure to act leaves a simple path — literally through path traversal sequences — for attackers to alter your deployment artifacts, disrupt services, or create persistent footholds.

---

Conclusion: Correct handling of filesystem paths in model tooling is a small coding omission with outsized operational consequences. Remediate the ONNX installation, validate ingestion logic, and enforce least‑privilege sandboxing to prevent model artifacts from becoming a vector for arbitrary file overwrite or denial of availability.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center